Originally posted: Friday, October 28, 2011
Written by Russ Miller, CTO SunView Software
Recently, a CIO I spoke to was lamenting the cost of the ALM (application life cycle management) tools his application team requested to purchase. He asked what we use internally, to his surprise, I mentioned that for a large percent of the process, we rely on ChangeGear itself, and that with some configuration, he could apply his existing install of ChangeGear to cover many of the same application life cycle needs. I went on to talk about our process and how ChangeGear was leveraged internally for ALM. Reflecting back on that conversation it occurred to me that there are likely others out there that might be interested to hear how we use ChangeGear, so I’ve captured the details here, after the break.
Listed below are 10 areas of the ALM where we apply ChangeGear. Of course, while within SunView, we apply a scrum based agile process, the same techniques would apply for conventional SDLC processes as well.
Areas of ALM ChangeGear can be applied to:
Now, taking the list above, I'll provide some details as to how ChangeGear is applied:
1) Issue Management: All customer and quality assurance related issues flow into the Incident module. There they are triaged and when appropriate assigned to a release. When an issue is assigned to a release, it is promoted to the Problem module (see #3 below).
2) Requirements/User story management: New Requirements (specified as user stories) flow into the Change Management module. The Change Management module offers sufficient workflow and other capabilities to support the review and approval of new features destined for a particular release. Once actually committed to a release, a Change module ticket is forked into the Problem module for assignment to a developer.
3) Project Management: Tasking of developers is done within the Problem module. System Views are created for each release to show open issues and those that have been completed. The views help developers and team leader know what is on their plate. The problem workflow has been tailored to the needs of an agile software team. This task focused project management is supplemented by other tools, but for the heads-down coding portion of the release, the Problem module helps the developers know what tasks are currently on their plate, and the teams plate. It is through the Problem module workflow that we also track the testing of each fix or enhancement also. We use a separate test case tracking application, and can associate ticket numbers with test cases to offer traceability of failed test cases to issues.
4) Change Management: In addition to using the change management module for tracking requirements, it is used internally to track changes to the testing lab. A separate scope was carved out using system views for this purpose.
5) Knowledge management: Internally, there is much “tribal” knowledge to capture and share. Knowledge about various aspects of the development and test environment are shared using the Knowledgebase module.
6) Integrated Source code management: We use SVN for source code management. Like most source code version control systems, SVN offers hooks. We leverage these hooks to allow us to link individual code check-ins to the defect or enhancement ticket. Having this link provides bi-directional visibility: from the ticket side we can drill-in to see exactly what code was touched, and from the source code management system, we can drill into ChangeGear to learn which ticket describes the change and audit that it was an authorized change.
7) Configuration management: Using the CMDB, we are able to track the various devices used in the development and test lab, and the changes made to those devices and applications. If you aren’t familiar with ChangeGear and its CMDB, this may need some explaining. The CMDB can catalog devices and applications along with the configuration information. So, for example, early on we experienced issues where suddenly, inexplicably, a build would not pass the “smoke test”. It was perhaps completely non-functional, for example, while testing, the web application would not load at all. Meanwhile, the SVN log showed few changes that could explain the behavior. Ultimately, the source of the problem was tracked down—a change was made to the build box; for example, Windows Updates were applied. After we started to use the ChangeGear CMDB along with RDE (Resource Discovery Expert) to watch for such changes, we were able to quickly troubleshoot such occurrences. Meanwhile, planned changes to the build environment cannot be tracked, and it is easy to view this by opening the CI (configuration item) that represents the build box, and see which RFCs were applied.
8) Workflow: Surprisingly few tweaks are required to the out of the box workflow to leverage ChangeGear in application development, but let me tell you about a few that we have applied.
Each ticket that tracks a defect fix or enhancement request flows through a Code Bounce state, where in it undergoes a peer-level code review.
After passing through the peer-level code review, tickets are placed in a Pending Build state. By way of integration from the automated build process, these tickets are associated to a build record (a CI in the CMDB) and moved to a Pending Validation state. The test team is notified as build and fixes become available. In this way, we know precisely which build a fix was made in.
9) Build/Release Management: Nant is used to automate the build process. Each time a build is produced, the ChangeGear Web Services are used to create a new CI record. A custom CI type was created to accommodate this. This “build” CI serves as an anchor for relating fixes to a particular build, and for tracking the lifecycle of a build through to release. As a result, we can work backward from a released build, to the defect or enhancement request, to the code changes, and even back to the set of original incidents or enhancement request that triggered the change.
10) License management: ChangeGear relies on a number of third party components, as such, there are support contracts that need to be tracked. The CMDB module is used to keep track of those vendors and the associated contracts.
In addition to the above, throughout the cycle we also use other features of ChangeGear such as the reporting, charting, and iCenter to help us stay on top of progress. In the end, the overall automation provided by ChangeGear meets a large percentage of our ALM process needs-all the way from incident/defect tracking throughout the life-cycle to the point of release management. As a final bit of help, please take a look at the following tables which summarize how the modules in ChangeGear can be applied to ALM.
Table 1: Modules in ChangeGear mapped to the ALM activity
Issue management (defect reports, questions, suggestions)
Light project management (defect and enhancement assignments)
Requirement/Enhancement/User story tracking/Release management
Build management, Lab Configuration Management, License management
Knowledge management (within Engineering and to Support/Services)
Communicating change from developers to those that need to know
Team Lead/Development Manager
Incident module, Problem module
Triaging defects, assigning defects and user stories, Integrated source code tracking
Problem module, Announcements
Implementing fixes and enhancements, communicating changes
Confirming fixes, acceptance testing
QA Lab Manager
Configuration management of lab
Change module, Announcements, Knowledgebase
Approving release of a build, owning communication of changes, deployment of internal ChangeGear builds