Home 
CM Journal Articles CM Tool Chains & Their Management
CM Journal Articles CM Tool Chains & Their Management
|
First, the good news - more and more current generation
tools are being supplied with APIs that allow reasonable integration times
between different classes of tools. Version Control tools are allowing pre- and
post-op triggers that can tie to process, workflow, DIET (Defect, Issue,
Enhancement Tracking) or ALM (Application Lifecycle Management) tools. These allow
check-ins, etc. to be blocked when inappropriate and status information to be
passed on to other applications. These tools are in turn able to know what has
changed from a versioning perspective for each defect, issue, enhancement,
change package/set, task, etc. Traceability to the source change level is
improving. There is light at the end of the tunnel.
 Now for the bad news - the light at the end of the tunnel may well be a fire breathing dragon! Just because there are more tools available with APIs and even to some level "vendor" supplied integrations, this does not mean we can use them! We have finally arrived at the same sticking point as other niches in the software industry - tool chain maintenance. Real World Example Let's just take a simple case in point from this year. The first table is what was in place just a few short months ago at the beginning of the year. It is not a complete list, but it is sufficient for the purpose of this article. January 1, 2007:
It is now October and my CM world has changed somewhat. The following table shows the changes to the tools listed above as well as new tools. October 1, 2007:
We have an internally created DIET system that, for the purposes of this article, I am calling xxx. It runs on its own server and has a web services interface on a different server. Both are maintained by development teams outside of both CM and QA. I started adding Bugzilla to the mix and, while I didn't use the entire cvszilla package, I did use a similar approach to tracking file changes associated with each bug/issue. By that, I mean I created a separate database table to track the changes with a primary non-unique key of the bug_id. The interface triggers and daemon included in the cvs_UpdateDIET package were updated to be able to selectively update either xxx or Bugzilla and a script was added to the package to use archived logs to "back-fill" legacy Bugzilla records when the xxx to Bugzilla conversion was completed. The first problem was that during the Bugzilla implementation period a major release (v3.0) occurred that contained features that were deemed necessary. Only a minor change to the cvs_UpdateDIET package was required, but IT felt it was necessary to deploy it on a new server. A server running the latest approved Linux distribution - SLES 10.1. The backup server was still running SLES 9.2. The difference in installed tools was acceptable with the exception of MySQL. It seems that tables created under v5.0.2 cause problems when attempted to be used from a v4.x server. Other applications required the v4.1.7 version of MySQL, so we had two choices - run two instances of MySQL or find a different backup server. The latter solution was chosen, but the "new" backup server is running Red Hat Enterprise Linux 4 which comes with an even older release of MySQL by default. A custom (non-distribution based) version of MySQL will need to be installed. Just prior to going live on Bugzilla, it was determined that refactoring and code rollbacks on different branches was causing problems and that there was no easy solution if cvs remained as the Version Control system. After research, AccuRev was picked as the tool to try. It comes with a bridge to Bugzilla and an Eclipse plug-in that allows renames and moves within the Version Control system instead of just using removes and adds. From a version control standpoint it appears to do what we need. Unfortunately, their method of updating Bugzilla is incompatible with the one we are already using and a full switch is not practical since the conversion from cvs to AccuRev is planned to be one project at a time and only if they need the additional features. Even worse is that the bridge works with the Bugzilla v2.22 series and not the newly released v3.0 and there are enough changes in Bugzilla that an updated bridge will be required. Yes, there are APIs in both tools and yes, we can craft our own bridge. Even though they are more than willing to work with us, the final solution may be up to us. Developers are running a various release levels of Eclipse, though the official release level they should be using is v3.3. Each time a newer release of Eclipse becomes available, developers want to try it to see if it is faster, more stable, works with a different set of plug-ins, or just has better eye candy. Coordinating the various "required" plug-ins with each update is something that has to be coordinated between Development, IT and CM. Once AccuRev is layered in, it becomes even more important to test each Eclipse upgrade before allowing it into general use. So what will we do for the rest of the year? Bugzilla v3.02 will go live this month. The backup Bugzilla server will be brought into working compliance with the primary server, regardless of the operating systems in use. Cvs will continue to be used for now while AccuRev issues are resolved. File associations will not be a part of the initial Bugzilla roll out, but the archived cvs_UpdateDIET logs will be kept for they can be back-filled when a final technical solution is determined. Work with AccuRev on their Bugzilla bridge will continue in parallel with the addition of a new AccuRev post-op trigger as a part of the cvs_UpdateDIET package, which will most likely be renamed to either cm_UpdateDIET or vc_UpdateDIET. Conclusion I am not pointing out that it is impossible to manage the interrelationships between the various CM tools and the other system level tools that support them. What I am pointing out is that it means taking time to plan for and test upgrades. In other words, this is a Configuration Management activity that must be performed and coordination with Development, QA and IT are essential. Just because a feature in one tool is something everyone has been waiting for, it does not mean that it can be rolled out quickly. It also doesn't mean that the single vendor solution will avoid this problem. In the past, I have used several single vendor solutions that are tied to specific distributions or release levels of an operating system, or to specific release levels of other third party components. Some were even tied to specific CPU signatures. The tool chain management issues were the same. Ben Weatherall is currently based in Fort Worth, Texas where he practices Practical CM on a daily basis using a combination of CVS and custom tools to support a modified Agile-SCRUM development methodology. He is a member of IEEE, ASEE (Association of Software Engineering Excellence – The SEI’s Dallas based SPIN Affiliate), NTLUG (North Texas Linux Users Group), and PLUG (Phoenix Linux Users Group).
Set as favorite
Bookmark
Email this
Hits: 4859 Trackback(0)Comments (2)
|
TrackBack URI for this entry
Subscribe to this comment's feed |
... RHEL5 has been out since April, and includes MySQL 5.0.22 (and is a free upgrade from RHEL4 if you already have RHEL4 RHN subscriptions). Just pointing it out since you wound up replacing the MySQL on RHEL4 because it was too old. |
mkanat
said:
|
... SCMBug is a standard API between version-control systems and Bugzilla. (It also supports other bug trackers.) I don't think it supports AccuRev, but at least starting from a base of SCMBug would be better than having to hack together your own bridge. (It does support CVS.) -Max |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
