what are the steps involved in moving from TestTrack to JIRA?
I've done a few migrations from TestTrack to JIRA over the last 5 years. It's always more work than I expect (weeks not days). The migrations I did used a custom migration application that read the data from the TestTrack database (not the simplest of schemas) and then imported it into JIRA using a custom SOAP API. Nowadays I think I might go with a more focused approach and use a single customized script to create CSV suitable for the JIRA CSV importer. This will get you the issue fields, comments and attachments. Links are separate thing, but no issue history.
The JIRA CSV importer works, though the flattening of the data restricts what it can do significantly. The hardest thing is usually mapping of values from one system to another - are the userids really identical in both systems?
If you want to investigate doing the migration commercially, please contact info#customware.net (my employer)
Related
I'm trying to pull data from JIRA that would be valuable to a QA manager. Specifically, I'm looking for a way to see how many times an issue was tested, and sent back for development due to failing testing. I've browsed a bunch of plug-ins but I don't think I've come across one that can pull such specific data from JIRA and create a report. The other option I've come across is using the API's com.atlassian.jira.issue.changehistory methods to pull the data and then filter it using conditional statements in Java. However, I'd prefer a ready-made plug-in that can support such querying of JIRA data if one is available.
My organization is moving away from JIRA and I've been given the task to archive or get all our JIRA tickets out ASAP. How can I do migration into any file/doc? any idea please as I can't find useful resource from the internet
Well you can perform an JIRA Backup that will generate you a backup which can be used to later restore but doesn't make it that useful in terms of viewing.
Or you can perform an issue search and from the results perform some sort of export:
Really depends on the number if issues you have, how custom your JIRA is and what useful data you wish to retain.
I am trying to implement a 'time machine' feature in my grails application. The feature would allow user to select a date in past and would display the interface of the application that was on the selected date. How do I implement this feature? I was thinking of adding a 'dateCreated' field for all domains, so that in the time machine feature, I could query all the results with created date before the selected date. I think this would work but as the data would grow, the size of database would grow and at that time the application would be heavy. Is there any other way to do this ?
Thanks
You could maybe draw some inspiration from this related question:
How to manage object revisions in Grails?
You should look at the http://grails.org/plugin/audit-logging plugin since it will allow you to keep all versions of domain class instances. But implementing this feature will be pretty tricky since object don't exist in isolation - you'll need to not only display the data as of the previous date, but its related data (e.g. the author's books collection) as of that date too. It will make the queries quite complicated.
I am looking for a fancy way the print individual work items in TFS.
OK ... maybe not the work item directly but I need to produce printable forms based on data on a work item. And by fancy I mean: header, footer, formatting, tables maybe ... stuff like that.
No, I am not trying to print a list of work items, read carefully, I need an output based on a single work item.
For those who are wondering "Why on earth do you need that?" I should say:
We are keeping everything on TFS around here. (For now only software development stuff, but I am thinking bigger...) Sometimes somethings need to be on hard copy, to be signed for instance, and that is why I need printable forms.
I came up with a solution a little interesting from my point of view.
I used the "mail merge" function of MS Word to print work items. I prepared an SQL query that reads whatever fields are needed from TFS database and set the query as a datasource for mail marge.
Now I can design a word document of any kind and use TFS fields in the document. I just select the appropriate record by work item number and voila!! my printable work item is ready.
It is a little slow when selecting a work item if you use a query that returns all work items, but who is perfect? Right ?
Though I agree that Reporting Services is probably the best way to accomplish this, you could alternatively write a web application that queries TFS and formats the data into a nice, printable HTML page. If you really wanted to, you could even look at some of the PDF libraries that are out there and just form-fill a PDF.
Here is an other free tool which can print tfs workitems:
http://blog.bbv.ch/2013/10/31/tfs-print/
You can use the Reporting services to create nice reports.
Access to the reporting services.
http://[tfsservername]/reports
Use the report designer with the standard cube's.
Here a link to get you started
ALM Rangers recently posted a tool on CodePlex which is actually an add-in for MS Word. What it does is connect to a query on TFS and create a word documents based on a print template.
http://vsarword4tfs.codeplex.com/
I'm looking for some ideas about saving a snapshot of some (different) records at the time of an event, for example user getting a document from my application, so that this document can be regenerated later. What strategies do you reccomend? Should I use the same table as the table with current values or use a historical table? Do you know of any plugins that could help me with the task? Please share your thoughts and solutions.
There are several plugins for this.
Acts_audited
acts as audited creates a single table for all of the auditable objects and requires no changes to your existing tables. You get on entry per change with the changes stored as a hash in a memo field, the type of change (CRUD). It is very easy to setup with just a single statement in the application controller specifying which models you want audited.
Rolling back is up to you but the information is there. Because the information stored is just the changes building the whole object may be difficult due to subsequent changes.
Acts_as_versioned
A bit more complicated to setup- you need a separate table for each object you want to version and you have to add a version id to your existing table. Rollback is a very easy. There are forks on github that provide a hash of changes since last version so you can easily highlight the differences (it's what I use). My guess is that this is the most popular solution.
Ones I have no experience with: acts_as_revisable. I'll probably give this one a go next time I need versioning as it looks much more sophisticated.
I did this once awhile back. We created a new table that had a very similar structure to the table we wanted to log and whenever we needed to log something, we did something similar to this:
attr = object_to_log.attributes
# Remove things like created_at, updated_at, other unneeded columns
log = MyLogger.new(attrs)
log.save
There's a very good chance there are plugins/gems to do stuff like this, though.
I have used acts_as_versioned for stuff like this.
The OP is a year old but thought I'd add vestal_versions to the mix. It uses a single table to track serialized hashes of each version. By traversing the record of changes, the models can be reverted to any point in time.
Seems to be the community favorite as of this post...