An ALM tool is a framework that glues together the various software configuration management (SCM) tools into something that automates a software development lifecycle, such as the one shown in figure 1. Unless you get your application lifecycle management (ALM) solution out of a box, you’ll need a strategy for implementing one. This article offers some simple guidelines for creating a working roadmap.

Figure 1: Software Development Lifecycle

While there are several free or open source tools that provide the interface between the version control, DIET (defect, issue, and enhancement tracking), and build management tools, a few are not development oriented. Those that truly support the (desirable) paranoia of SCM are—at least so far—commercial, off-the-shelf solutions. It isn’t within the scope of this article to recommend which tools are appropriate for the many situations you may find yourself in. Rather, I will describe an order of implementation that seems to work for most of the organizations I have either worked with directly or had conversations with over the past few years.

Unless management pressures are present, the “best case” order of implementation seems to be:

1. ALM framework tool
2. Version control
3. Defect, issue, and enhancement tracking
4. Build management
5. Workflow/process enforcement
6. Release management
7. Automated test execution
8. Requirements tracking

ALM Framework Tool
Depending on which tool you choose, built-in integrations may be present as a part of the base package or as standard add-ons. If so, consider your existing version control, DIET, and build management tools when selecting which ALM tool to implement. If not, there may be a plug-in or trigger mechanism of some kind that will allow you to integrate what you need.

Version Control
It is likely that you already use one or more version control tools. If not, you will need to pick one (help is available in many CM Journal articles). Regardless, you need to integrate all of your version control tools into the framework. You should never perform a build from anything but controlled source.  

Defect, Issue, and Enhancement Tracking
Again, it is likely that you already use one or more DIET tools. Generally, they will have some integration with version control, but the framework needs its own integration so that you can automate and track build information, change logs, traceability, etc. in the DIET system. In some cases (such as Rally), these tools were never intended to be DIET tools. But, unless you want to install and integrate a bridge DIET tool, the framework needs to be able to integrate with them.

Build Management
An ALM framework may use many build tools and may need to integrate with many of them. Initially, there only needs to be provision for doing on-demand and scheduled builds, but eventually you will need to implement continuous integration builds as well. Some build frameworks provide integrations of version control and build management (and possibly DIET) that the ALM framework may have to replace if you are to create a full ALM solution. Doing this should be an evolutionary process.

Workflow/Process Enforcement
ALM tools in general are an outgrowth of a desire to automate workflows and enforce processes. The framework needs to be able not only to perform sequential processing but also to allow manual interaction or event-driven triggers to block steps from occurring and to allow them to resume at some future time. These could be a simple as requiring an authenticated user to acknowledge a gate event or as complicated as receiving an asynchronous notification from a test system that tests have been performed successfully.

You should already have been creating some basic workflow steps in the implementation to date:

1.     Receive the build request.

2.     Retrieve the appropriate source and build scripts from version control.

3.     Generate change logs for the difference between the last successful build and this one.

4.     Create a build ID.

5.     Perform the build.

6.     If the build is successful:

a.     Update all identified DIET records in the appropriate state to indicate they are present in this build using the build ID.

b.     Send notification to the appropriate parties of the successful build.

c.     Generate and control any additional reports or logs.

d.     Deploy the build artifacts to an SCM-controlled area.

7.     If the build is not successful:

a.     If it is possible to identify the DIET issue causing the build break:

              i.     Update the DIET record.

             ii.     Notify the programmers and testers identified in the DIET record.

b.     If it is not possible to identify the causal DIET record:

           i.     Create a build-break record in the DIET system.

           ii.     Notify all the programmers associated with the changes, their leads, etc. of the build break and include the new DIET record number.

Now, add any needed extra steps and plan for them going forward. These include such things as:

• If the build fails, block any further workflow steps related to the build.
• If the build succeeds:

o   Execute any unit tests and capture resulting reports, logs, etc.

o   Notify testing that a build is available.

o   Block any further workflow steps until testing informs the ALM framework that testing has completed successfully.

Release Management
Release management is where you package one or more builds plus controlled non-build items in a form suitable for distribution. In some development models, this may require using the identical source from the previous build to regenerate the build without testing instrumentation and with optimization or obfuscation. In other models, it requires that the previously generated artifacts be identifiable and selectable for inclusion. In either model, a release ID is generated and the release is tagged with it. This may require the automated physical modification to the pre-release artifacts to embed the release ID, or it may just mean the inclusion of release-generated files or renaming some files.

Additional workflow steps include:

• Generate the release ID.
• Generate change logs for the difference between the last release and this one.
• Perform any updates and packaging needed to create the release.
• Flag the release as a release candidate.
• Notify any stakeholders that a release candidate is available.
• Block any further workflow steps until management informs the ALM framework that it has accepted the release candidate for release.

Automated Test Execution
A testing group normally implements the automated performance of tests—beyond unit tests. The selection of test tools, creation of the testing framework and test suites, and defining the anticipated results is definitely the purview of the quality group; however, either they or the ALM framework can perform the execution. The ability of tools such as ALM frameworks to spawn off specific virtual machines is one of the recent innovative uses of virtual machines. (If physical test servers are used, simply ignore any VM-specific steps in the workflow steps below.)

Additional workflow steps include:

• Spin-up a specific virtual machine.
• Deploy a release and test set to it.
• Trigger/execute the tests.
• Capture the test results.
• Spin down the virtual machine.
• Perform an analysis of the test results.
• Capture all of the results, logs, and reports as artifacts associated with the build.
• If the tests pass:

o   Notify any stakeholders of the passing of the tests.

o   Release the workflow if this is a blocking event.

• If the tests fail:

o   Notify any stakeholders of the failure of the tests.

o   Block any further workflow steps.

Requirements Management
The reason requirements management is the final addition to the ALM framework is twofold: Most requirements management tools are not easy to integrate, and most of them integrate with either DIET or version control tools by choice. The primary reason to include requirements management in ALM is to provide full-circle traceability between requirements, source code, builds, and the tests they appear in. How you integrate requirements management tools varies greatly depending on the tool. With the exception of Rally (integrated via DIET), I have no direct experience with successful implementations. For the most part, what I have seen work is to include a manual step in the workflow for review approval that is required prior to a release candidate’s approval for actual release.

Conclusion
ALM is a worthwhile step forward, allowing for SCM to provide an appropriate level of control of all intermediate artifacts while minimizing the overall changes for “bad” releases. If anyone knows of any free or open source ALM frameworks that support these integrations, please let me know in the comments.
 

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment