Contents Scope2 The Scope of the Document2 Overview3 Feature List Comparison4 Pricing and Costing5 Migration Methodologies:5 1. 1. 1. Importing Data From CSV6 2. 1 Migration from TeamTrack 6. 6. 1 to SBM 2009 R219 Database Changes on upgrade19 Licensing Considerations for Upgraded Systems19 Prerequisites For upgrade20 Benefits on upgrading to SBM21 Scope The Scope of the document is Migration of Team Track 6. 6. 1 to Other Tool. The Current System needs to be migrated to other Tool because of License Expiry.
Serena Business Mashup 2009 R2 (SBM) is updated and enhanced version of Team Track 6. 6. 1. SBM is readily available substitute for Team Track, but the System has lots of Extra features which may not be used in Intuit. Since SBM is also product of Serena, therefore Data Migration is very safe and simple and easy. The proposal of the document is to define the Scope and Case Study. Other Alternative Tool which incorporates all the current features of Team Track 6. 6. 1 is JIRA 4. 2. JIRA has all the features which are currently in practice at Intuit. Overview 1. TeamTrack 6. 6. Serena TeamTrack is a web-architected, secure and highly configurable process and issue management system. It creates a clear process throughout the application lifecycle—from initial request to post-delivery customer support activities. 2. JIRA 4. 2 JIRA provides issue tracking and project tracking for software development teams to improve code quality and the speed of development. Combining a clean, fast interface for capturing and organizing issues with customizable workflows, Open Social dashboards and a pluggable integration framework, JIRA is the perfect fit at the centre of your development team. 3.
SBM 2009 R2 Serena Business Mashups, the next generation of TeamTrack, allows business developers to build and combine applications (commonly known as Mashup) to drive the coordination of business activities. For years TeamTrack administrators have been using TeamTrack to automate processes across their organizations. This release offers a revolutionary capability that allows business developers to build solutions faster and deploy them more easily. Feature List Comparison S. NO| Team Track Features| JIRA| SBM| 1. | States| Yes| Yes| 2. | Transitions| Yes| Yes| 3. | Fields| Yes| Yes| . | Workflows| Yes| Yes| 5. | Projects| Yes| Yes| 6. | Attachments| Yes| Yes| 7. | Mailing| Yes| Yes| 8. | Notifications| Yes| Yes| 9. | Searching of Items| Yes| Yes| 10. | Reporting| Yes| Yes| 11. | Workflow branches| Yes| Yes| 12. | Inheritance| | Yes| 13. | Dependency Settings on fields| | Yes| 14. | Default value setting to a field. | Yes| Yes| 15. | Making Field Mandatory/Non mandatory| Yes| Yes| 16. | User access & Groups| Yes| Yes| 17. | Standard Browser & OS| Yes| Yes| 18. | Data Export| Yes| Yes| 19. | Scripts| Yes| Yes| 20. | Tables| Yes| Yes| 21. | Journal, memo Text fields| Yes| Yes| 2. | Restriction of transitions view| Yes| Yes| 23. | Other Tools/ Integrated Tools. | Yes| Yes| 24. | Web-Services| Yes| Yes| Pricing and Costing No of concurrent Users| JIRA| SBM| 10 Users| $10| Still to Evaluate| 25 Users| $1,200| | 50 Users| $2,200| | 100 Users| $4,000| | Unlimited Users| $8,000| | Academic pricing is available for qualifying organisations such as: public or private schools, libraries and museums. JIRA is free for use by official non-profit organisations, charities and open source projects. Migration Methodologies: 1. JIRA 2. SBM JIRA has following methodologies for Migration of data: 1. CSV Importer JIRA ships with built-in importers for Bugzilla, Mantis and FogBugz. You are recommended to use the relevant built-in importer, if you are migrating from one of these issue tracking systems. * Bugzilla * Mantis * FogBugz 1. 2 Built-in importers If you are migrating from a system which JIRA does not provide a built-in importer for, you may be able to import your data into JIRA via CSV format instead. Your system must be able to export your data into a CSV (comma-separated value) file. You can then import the CSV file into JIRA using JIRA’s CSV importer. There is also a workaround for importing comments. . 3 Third-party scripts A number of third-party scripts are available that support the importing of data into JIRA. 1. 4 Jelly script Another approach is to write a Jelly script that will import your data. JIRA ships with some Jelly tags that make operations like creating issues in JIRA easy. 1. 5 RPC services JIRA ships with an RPC plug-in which enables limited remote access to JIRA. It is available through SOAP and XML-RPC interfaces. SOAP interface is more complete. The JIRA RPC Services page provides a starting point for all remote procedure call needs. JIRA’s database schema is described in XML format in:
WEB-INF/classes/entitydefs/entitymodel. xml file under the JIRA web application. 1. 1. 1. Importing Data From CSV The CSV importer provides a powerful and flexible way to import data from a comma-separated file, which is a format supported by most applications (e. g. Microsoft Excel). There are currently two ways to import CSV data into JIRA: I. Using the new and updated JIRA Importers Plugin. II. Using the existing built-in importer. JIRA Importers Plug-in The JIRA Importers Plug-in can import your old data in CSV format. The web based configuration helps you migrate and map data.
The import process consists of: * Preparing your CSV file. * Running the Import Wizard. You can choose to map individual fields and field values during the import process. During the import process, the following data is copied from your CSV file into JIRA: JIRA Field | Import Notes | Project | CSV data is imported on a per-project basis. You can either specify an existing JIRA project(s) as the target, or the importer will automatically create a new project(s) for you at time of import. | Component(s) | You can import issues with multiple components by entering each component in a separate column. Affects Version(s) | You can import issues with multiple ‘Affects Versions’ by entering each version in a separate column. | Fix Version(s) | You can import issues with multiple ‘Fix Versions’ by entering each version in a separate column. | Comment Body | You can import issues with multiple comments by entering each comment in a separate column. | Date Created | Use the date format specified in your JIRA system | Date Modified | Use the date format specified in your JIRA system | Issue Type | If not specified in your CSV file, imported issues will be given the default (i. e. irst) Issue Type as specified in your JIRA system. You can also create new JIRA values on-the-fly during the import process. | Labels | You can import issues with multiple labels by entering each label in a separate column. | Priority | If not specified in your CSV file, imported issues will be given the default (i. e. first) Priority as specified in your JIRA system.. | Resolution | If not specified in your CSV file, imported issues will be given the default (i. e. first) Resolution as specified in your JIRA system.. | Due Date | Use the date format specified in your JIRA system. Status | If not specified in your CSV file, imported issues will be given the default (i. e. first) Status as specified in your JIRA system. | Summary | This field is required. | Time Spent | The value of this field needs to be specified as number of seconds. | Users | You can choose to have the importer automatically create JIRA users for any values of the Assignee or Reporter field. * Users will be created as active accounts in JIRA. Users will need to get their passwords emailed to them the first time they log into JIRA. Users with no real name will get the portion of their email address (login name) before the “@” character as their Full Name in JIRA. * If you are using External User Management, the import process will not be able to create JIRA users; instead, the importer will give you a list of any new users that need to be created. You will need to create the users in your external user repository before commencing the import. * If you have a user-limited license (e. g. personal license), and the number of required users is larger than the limit, then the import will be stopped.
A page will be displayed showing a list of users that can’t be created. | Other fields | If your wish to import any other fields, you can choose to map them to specific JIRA custom field(s). If your custom fields don’t yet exist in JIRA, the importer can automatically create them for you. | | * CSV file format The CSV importer assumes a Microsoft Excel styled CSV file. Fields are separated by commas, and enclosed in quotes if they contain commas or quotes. Embedded quotes are doubled. There are two requirements of the CSV, in addition to being well-formed in general: * The CSV file must contain a heading row.
The CSV configuration wizard uses the CSV header row extensively. The header values should not have any punctuation (beyond the commas separating records) such as apostrophes or the importer may not work correctly. * As a minimum, the CSV file must contain a column for Summary data. JIRA will read the CSV file using the system encoding, which can be seen in Administration -> System Info. Make sure that you either save the CSV file with this encoding, or set -Dfile. encoding on startup to force the system encoding to be what you’re using (utf8 is best). * Import from CSV . In JIRA’s default permission scheme (associated with newly created projects), ensure that the ‘Browse’, ‘Create’ and ‘Comment’ permissions are granted to the group ‘jira-users’ (or a group with the ‘JIRA Users’ global permission). 2. Log in to JIRA as a user with the ‘JIRA System Administrators’ global permission. 3. Bring up the administration page by clicking either the ‘Administration’ link on the top bar or the title of the Administration box on the dashboard. 4. On the panel on the left, under the title ‘Import & Export’, click External System Import – Beta!.
Then select ‘Comma-separated values (CSV)’. 5. The ‘CSV Import Wizard: Setup’ page will be displayed: Screenshot 1: the ‘CSV Import Wizard: Setup’ page * Select your CSV file, then click the ‘Start Import Wizard’ button at the bottom of the page (leave the ‘Existing Confiuration File’ field blank if you don’t yet have a configuration file, or if you want to create a new file or update the one you have). * Project Configuration: You can either import all your issues into one JIRA project (new or existing); or import into multiple projects by including the project data in your CSV file. Import issues into an existing JIRA project — type a project key (or project name) that already exists in JIRA. * Import issues into a new JIRA project — type a new ‘Project Name’, ‘Project Key’ and select which user will be the ‘Project Administrator’. The importer will create your new JIRA project automatically. * Project information contained in CSV file — ensures that every issue in your CSV file includes data for the project name/key. The JIRA ‘Project key’ will be the prefix for the IDs of all issues in the given project.
There is no warning or error message if you select an existing key (or existing project name with a different key). The importer will import issues to the project specified by the key (or project name). * Field Mappings: * ‘Summary’ field is required. All other fields are optional. * Field Value Mappings: * Leave a field blank if you wish to import the value as-is. If you want to clear a field, enter the keyword <<blank>>. * You can create missing Priority, Resolution and Issue type values in JIRA on-the-fly by clicking the icon next to the appropriate field. Usernames — If you don’t specify mapping, the importer will automatically map imported usernames to JIRA usernames (lowercase). Regardless of whether you specify mapping, JIRA will automatically create usernames for missing users unless you un-check the ‘Create new users’ option on the final ‘Import Data’ screen (see Screenshot 2 below). 6. When you have finished specifying your field mappings, the ‘Import Wizard: Settings’ page will be displayed: Screenshot 2: the ‘Import Wizard: Settings’ page * Create new users — It is generally recommended that you leave this set to ON.
Only select OFF if you do not want JIRA to automatically create new usernames for imported users who do not already exist in JIRA. * Create new versions — It is generally recommended that you leave this set to ON. Only select ‘OFF’ if you do not want JIRA to automatically create new versions for imported versions which do not already exist in JIRA. * Create new components — It is generally recommended that you leave this set to ON. Only select OFF if you do not want JIRA to automatically create new components for imported components which do not already exist in JIRA. Create new custom fields — It is generally recommended that you leave this set to ON. Only select OFF if you do not want JIRA to automatically create custom fields for imported fields which do not have a corresponding field in JIRA. * Maximum issues and failures — If you wish, specify a maximum number of failed issues after which the importer will stop. If you want the import to continue regardless of any failures, leave this field blank. If your old issue-tracker has a large number of issues, it’s generally a good idea to run first the importer on a limited number of issues (e. g. 00), then manually inspect the imported issues to confirm whether your configuration file was specified correctly. When the results are satisfactory, you can run the import with no limit. 7. The importer will display updates as the import progresses, then a success message when the import is complete. 1. 2. 1 Using JIRA’s Built-in Importer Importing from a CSV file is a three step process. First, you need to prepare and verify your CSV file. Next, create a mapping file by running the CSV import wizard. The mapping file is a plain text properties file that you can also manually edit.
It will map your CSV fields to fields in JIRA. Finally, to perform the import, simply enter the location of your import file and your configuration file. * Preparing your CSV file The first thing you need to do is to ensure that your CSV is a valid CSV format. A good way to check is to import your file into a spreadsheet (e. g. Microsoft Excel) and see if the data is as expected. The CSV importer assumes a Microsoft Excel styled CSV file. Fields are separated by commas, and enclosed in quotes if they contain commas or quotes. Embedded quotes are doubled.
If you have values that signify a blank value (e. g. <blank> or None), it’s best if you simply remove them in this step. If a row contains more columns than there are header columns, then the excess columns will be added as comments. There are two requirements of the CSV, in addition to being well-formed in general: * The CSV file must contain a heading row. The CSV configuration wizard uses the CSV header row extensively. The header values should not have any punctuation (beyond the commas separating records) such as apostrophes or the importer may not work correctly. As a minimum, the CSV file must contain a column for Summary data. JIRA will read the CSV file using the system encoding, which can be seen in Administration -> System Info. Make sure that you either save the CSV file with this encoding, or set -Dfile. encoding on startup to force the system encoding to be what you’re using (utf8 is best). . * Running the CSV Import Configuration Wizard The next step of the import process is to run the import configuration wizard to determine how the CSV data can be mapped to JIRA fields. 1. Log in as a user with the ‘JIRA System Administrators’ global permission. 2.
Bring up the administration page by clicking either the ‘Administration’ link on the top bar or the title of the Administration box on the dashboard. 3. On the panel on the left, under the title ‘Import & Export’, click ‘External System Import. ‘ 4. The ‘Import Data’ page will be displayed. Select ‘Comma-separated values (CSV)’. 5. The ‘Import issues from CSV file’ page will be displayed. Click the ‘CSV Import Wizard’ link. 6. The ‘CSV Import Wizard: Setup’ page will be displayed: You can optionally specify the delimiter your CSV file used. Leave the field blank if you wish to use the (default) comma delimiter. Please
Note: Delimiter can only be one character long. 7. Click the link ‘Start Import Wizard. * Project Configuration The first step is to choose which project the issues will be imported into. You can import into a new project or an existing project. If certain project details (e. g. name and key) match an existing project, then the issues will be imported into an existing project. Note that if you are creating a new project, no validations are performed at this time – invalid data will result in a failure later, at import time. If you want to import into multiple projects, you must map project information from the CSV file itself.
That means that all rows must have the project information in them. The recommended import method is a single project per CSV file, imported into an existing project. * Issue Field Mappings The second step is to decide which CSV fields you want to import. The screen shows all the columns that are found in your CSV file, and a sample data row. On this screen you can map each column of your CSV file to system fields in JIRA, or leave as None to not import. You can optionally create new custom fields on the fly or import into an existing custom field. System Fields
You can select multiple fields to be combined into Version and Component fields. For example, you can import from ‘Raised Version’ and ‘Found in Version’ into the ‘Affects Versions’ field. For Versions and Components, the importer will detect if the version exists in JIRA for the project. If it doesn’t exist, then it will automatically created. User fields (Assignee and Reporter) are assumed to be in a ‘FirstName LastName’ format. New users will be created with the username as ‘FirstNameLastName’; spaces, apostrophes and brackets are stripped out. If the name only has one word, that one word will be used as the username.
In most cases when importing system fields values like Priority, >Issue Type, Status and Resolution, you will need to JIRADOC:map the field values. The mapping needs to be done even if the imported CSV file has the values set to ‘valid’ names, e. g. Issue Type set to ‘Bug’ or ‘New Feature’. The only alternative to mapping the values is to change the CSV file such that it contains the exact IDs of JIRA’s priorities, issue types, statuses and resolutions instead of their names. This requires you to determine the correct IDs and then update the whole CSV file, so it is easier to map the values during the import.
Custom Fields and the importer You can also map a column to an existing custom field or create a new custom field on the fly. Currently you can only create certain custom fields on the fly. All custom fields created this way will be globally scoped. Moreover, if the name matches an existing custom field, that existing custom field will be used instead. If you map to a select list custom field, all unique values will be created as options at import time. If you map to a multiple select field, its values should be separated by a comma. If the field values have commas in them, the commas should be escaped with a backslash.
Map Field Values You may wish to map certain values in your CSV file to a different value. For example, you might map the field ‘Severity’ to JIRA’s ‘Priority’ field. JIRA expects the ID of priorities that exist in JIRA. Thus for this field, you’ll need to check the Map field value check-box. Value Mappings Value mappings determine how values from your CSV importer will be ‘translated’ to match the values expected by JIRA. This is usually required for fields such as ‘Issue Type’, ‘Resolution’, ‘Priority’ and ‘Status’, but can also apply to other fields.
On this screen, all unique values for each field you selected to be mapped have been displayed. You can now map any of these values to their values in JIRA. Leave the field blank if you wish to import the value as-is. If you want to clear a field, enter the keyword <<blank>>. On the ‘Field Mappings’ screen, each field has a checkbox under the heading ‘Map values’. If you check these boxes you will be able to map the values of these fields when you progress to the next page. For fields mapping to Resolution, Priority and Issue Type, you will get a select list with the available values in JIRA.
In addition, you can quickly create values that do not exist in JIRA by clicking the green plus symbols. For fields mapping to Status, you will get the select list with JIRA’s available values, but no plus symbol for creating new status values. For these four fields, there are two special options in the select list in addition to JIRA’s available values: * ‘Import as blank’ — this causes the JIRA value to be blank for that field. Note that, if you are importing Unresolved issues, you should create a field mapping for the Resolution field and set the value ‘Unresolved’ to ‘Import as blank’. ‘No mapping’ — this attempts to import the value in the CSV file as-is. Note that using ‘No mapping’ for a field value will result in a failed import if the value is not valid for that JIRA field. For fields mapping to Status and Issue Type, default values are used when the ‘Import as blank’ option is selected. You will be asked to enter some extra information on this screen, such as: 1. The domain name of the users that will be created in the system. 2. If you are importing date fields, you will also be asked to supply the date format that is used in your CSV file.
Note that this could be different from the date format that is used in JIRA. All date fields will be interpreted using the format you supply. * Saving the Configuration File The final step of the Wizard allows you to save the configuration file on your server. Saving the configuration file enables you to import more CSV files later without going through the Configuration Wizard again. Please ensure you enter a valid path. Alternatively, you can choose to continue on with the import without saving the configuration in a file. You can also see a preview of the mapping file that will be saved. Importing the CSV file Once you have your configuration file, you can then import the CSV file into JIRA. 1. Log in as a user with the ‘JIRA System Administrators’ global permission. 2. Bring up the administration page by clicking either the ‘Administration’ link on the top bar or the title of the Administration box on the dashboard. 3. On the panel on the left, under the title ‘Import & Export’, click ‘External System Import. ‘ 4. The ‘Import Data’ page will be displayed. Select ‘Comma-separated values (CSV)’. 5. The ‘Import issues from CSV file’ page will be displayed. . Type the location of your CSV file and your configuration file, and click the ‘Import’ button. The ‘Settings’ page gives you precise control over what will be imported on each import run. Once the import has begun you will be able to follow the progress of the import, with the screen refreshing around every 10 seconds. You can change this rate by updating the field at the bottom of the page. The importer also give you statistics about what objects have been imported and time elapsed so you can have an idea as approximately how long the import will take.
You can also choose to ‘Abort’ the import, which will cease importing after the current issue is done. 1. 4. 1 Jelly script * Enabling Jelly JIRA’s Jelly support is disabled by default, as it is a potential security hazard. If one need to use Jelly, you should enable it immediately prior to use and disable it immediately afterwards. To enable Jelly, set the jira. jelly. on system property when starting your application server. System properties are set with parameters to the java command, e. g. java -Djira. jelly. on=true …. (You can set this parameter in the setenv. h file in your /bin folder) How to set this property depends on your application server. For example, with Tomcat (JIRA standalone distribution), set the environment variable JAVA_OPTS=-Djira. jelly. on=true, or when running JIRA Standalone as a service, set the service JVM parameter. * Running a Jelly script To run a Jelly script once: 1. Log in as a user with the ‘JIRA System Administrators’ global permission. 2. Bring up the administration page by clicking either the ‘Administration’ link on the top bar or the title of the Administration box on the dashboard. 3.
Under the ‘Options & Settings’ sub-menu in the left-hand navigation column, click the ‘Jelly Runner’ link. 4. Paste your Jelly script into the text area. To run a Jelly script periodically: Configure a service with the following class: com. atlassian. jira. jelly. service. JellyService. * Writing a Jelly script Scripts are generally of the form: <JiraJelly xmlns:jira=”jelly:com. atlassian. jira. jelly. JiraTagLib”> | <! — | Add your own Jelly XML here | –> | </JiraJelly>| | 2. 1 Migration from TeamTrack 6. 6. 1 to SBM 2009 R2 While migrating from TeamTrack 6. 6. to SBM, there will be some changes in terminologies, database changes and licensing, which have a minor impact. End users| No Impact. There is only look and feel changes and they can use directly without any training. | Support Team| There are some terminologies, implementation process changes. But these are not major changes; Support team can easily get trained on these changes. | Technologies| Database changes as below| Database Changes on upgrade During the upgrade the database is upgraded, the upgrade changes data in your database to make it compatible with the new release. The database changes include: Projects that contain transition overrides (enabled/disabled) are promoted to workflows. * Default values for User, Group and Relational fields set at the workflow are moved to the project level. * The data for date and time fields will be updated to support an extended format. * Data stored in the database will be changed to Unicode. This change will occur only when the database data is currently not in Unicode. * Administrator privileges will be changed to include all new deployment permissions. * The database will increase in size due to the changes, especially the Unicode upgrade.
Expect the database to increase in size up to a 100%, and the transaction logs to grow significantly. * Each of the existing solutions will be converted into an application and placed into a Mashup. * Custom auxiliary tables that are related to an existing solution will be added to the new application created for that solution. You will edit the new application in Mashup Composer to alter these custom auxiliary table(s). * The system auxiliary tables will be added to a Global Application mashup. You will edit this Global Application in Mashup Composer to alter the auxiliary tables.
Licensing Considerations for Upgraded Systems Serena License Manager is used to manage Business Mashups licenses and access to each environment in your system. The following information applies to upgrading customers in regards to licensing: * Users who connect to Mashup Manager, Mashup Composer, Mashup Administrator, or the Web interface consume a user license. * Users consume only one license if they are connected to multiple interfaces within a single environment. Note that licenses are consumed only for Mashup Composer when it is connected to the Mashup Repository. You do not need to change your current license set up in order to upgrade to Business Mashups. There is no need to change anything in Serena License Manager prior to upgrading your system. * Seat licenses, which determine the number of users that can be active in a Business Mashups system, are now available for user, managed administrator, and external (requestor) product access types. Seat licenses ease administration because you do not need to assign a license to each individual user, as you must with named licenses. You can migrate to seat licenses at any time after upgrading. Prerequisites For upgrade Hardware Requirements Recommended Requirements| Minimum Requirements| 2GHz or Higher Multi processor| 800MHz or higher Single Processor| 4 GB Memory| 2GB Memory| 10 GB Operational Space| 2. 5 GB Operational Space| * Ghost Image of the server * Database backup * Notification templates and other Templates backup * Microsoft . net Framework 3. 5 * Perl * Ample Free disk space on the Database machine. * Plan ample time to perform the upgrade. For example, the step to upgrade only the database may take 2? hours to upgrade a 1 GB database. * In a multi-environment upgrade, install Mashup Manager on a separate server.
In a multiple-environment upgrade, there will be multiple Application Engine Web Servers running on different servers while there is only one Mashup Manager. * Create two separate database partitions to host your Business Mashups data. All the Mashup databases can share a single database space; however, creating at least two databases that separate the runtime data (Application Engine and Orchestration Engine) and the repository data provides the following benefits: * The data entered by Web interface users is kept separate from the data used to build and describe Mashups and other design artifacts. Storing data in separate databases allows more resources to be dedicated to each database or schema. * This is the most manageable configuration for systems that use Mashup Manager to promote Mashups between development, test, and production servers. Benefits on upgrading to SBM * Can use the same Database. There will only be a database upgrade. * No training is required for the end user as there is no change in the functionalities with TeamTrack and SBM. * All the External application will be supported in SBM. The only change will be the SBM Web Service link. * Easy Rollback of Changes. Change control management or change Management * Web Service Orchestrations – Without Coding * New Customized Work-Week Calendars * New Reports – Better Reporting * Performance Improvement * All the Existing functionalities in TeamTrack will be migrated to SBM. There will be minimum effort. * No Change has to be done in the Report Database as the there is no change in the Table names after the upgrade. Migration Methodology Serena Bussiness Mashup(SBM) is an upgraded version of Team Track. The Migration of the same is easy and simple, however we are still working on the Approach.