Application lifecycle management (ALM) tools have made a lot of progress in recent years. Many companies have assembled...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
an ALM system piecemeal, picking version control here and a project management tool there. Historically, full-stack ALM suites from vendors like Microsoft, Atlassian or IBM have been difficult for companies to adopt. Each vendor promotes its own tools, and they may not be compatible with existing project management tools, version control, IDE or other software.
Let's look at how to build your own full-stack ALM system out of existing, best-of-breed components, starting with what your team is using now.
The components of ALM
Project management -- These tools break the work into manageable chunks and make the progress visible. Traditional project management tools focus on the plan, the deviation from the plan and how to address it -- based on a Gantt chart. Modern tools tend to look at actual progress and predict what will happen if the trend continues. That allows management to re-plan, instead of applying hope or pressure to meet the original goal. To do that, the tools slice the work into chunks of meaningful value to a customer; the standard increment is the story.
Portfolio management -- Although project management tools are useful for teams and even teams of teams, they don't necessarily support viewing an entire organization's efforts. Portfolio management tools visualize the team effort. They help directors predict the availability of important teams and resources. Ideally, portfolio management tools zoom out from project management tools and are based on projects rather than plans. Some integrated suites offer this for free; some have plug-ins for this functionality. In some cases, you can export your data from the project management tool and import it into a portfolio tool, with a nightly refresh.
Version control -- In an ALM system context, version control is about more than the code. It tracks what code ties to what task in project management, and sometimes what tests to run on a specific branch or set of features. The challenge with building an ALM system by hand is not in getting version control (most modern programmers will do that), but in getting the version control visible in the project management tool. Many modern version control systems like Git, SVN, and CVS, can store either a commit number that you can reference or a URL. The simplest way to tie project management tools to version control is to store the commit number as an update, or note, next to the task or piece of work.
Deployment control and tracking -- It's easy enough to configure a build system like Jenkins, Ant, or TFS; but the challenge is integration and being able to identify exactly which features are in each deploy. Typically, modern Agile project management tools have an idea of a sprint, and it may be possible to tag, branch or "mark" builds with a specific sprint number, which creates traceability.
Integrated ALM suites tend to tie the build to the features automatically. That isn't necessary, but it does prevent duplicate entry and human errors, which tend to happen otherwise. Then again, if your team doesn't have trouble tracking features to deployments, adding the traceability may be more trouble than it is worth.
In addition to production environments, deployment controls also cover building and configuring test environments, including operating system, third-party controls and Web server configuration.
Tracing from requirements to code to tests to production push -- When it comes to debugging, being able to trace the path of a particular feature can be extremely helpful. What automated checks did this functionality go through? When did the feature go live (in what build, on what day)? Debuggers will need the answers to these questions and questions like them.
Production monitoring -- Putting the application in the hands of users is not the end; it is where the real action happens. Knowing what users are doing -- and what is going wrong -- can allow a team to find and fix problems before they escalate to the entire user base.
For example, how long is the Web server taking to serve up requests? How many 404 and 500 errors are appearing? How many exceptions are being thrown, and on what pages? This is a part of managing the life of the application, and an area where ALM tools have room to improve. Open source performance management tools like Graphite can provide easy ways to visualize these sorts of statistics; the trick is getting the system to know when something has gone wrong automatically.
Incident management -- Some ALM tools take over where production monitoring ends, automatically creating a ticket when server response slows or error rates increase. The ticket represents work, which will appear on the team's card wall as a support task. Tracking how often incidents occur and how long they take to handle can allow the project and portfolio tools to improve their predictions -- if they know about the work. Teams doing incident tracking separately may want to combine tools, or at least make sure the incidents appear in the project management tool. Otherwise there will be a hidden, untracked amount of work, slowing the project down and invisible to management.
IDE integration -- Most programmers work heads-down in an integrated development environment (IDE). The ability to right-click and push code to version control within an IDE is powerful; it allows a programmer to stay in the zone while periodically saving work. An integrated ALM system can allow developers to resolve stories, move features to test, or even move code to production (after passing automated tests) without having to shift out of the IDE in which they work.
The alternative to this sort of integration makes the programmer leave the IDE, open up a command-line shell, run a commit and a push, then open up a Web browser, log into the project management tool, search for the story, move it from development to test, then find a tester to do the work, or perhaps check email, and so on.
The hard part: Putting it all together
It is possible to build an ALM system by picking one of each of the items above. But some elements might not be relevant; it might be fine to have programmers commit in version control. For example, some programmers split a text screen and can shift from version control to code with shift-tab.
The hard work is the glue work -- integration -- designing an ALM system where the tools know about each other and work together. Once they work together, programmers save time coding, operations saves time deploying, support saves analysis and debugging time, project management becomes more visual, and executive management gets visibility and planning help.
The old decision was between buying a full ALM suite, in which case you likely had to convert everything to Microsoft or IBM tools, or cobbling something together, which required complicated custom integration and configuration setups. Luckily, that decision is getting easier.
Switching out for a full-stack tool
The "walled garden" forced by full-stack tools seems to be changing. Visual Studio, for example, which is Microsoft's programming environment, can support many types of version control systems through VSSCC, and even has native hooks to support Git, and a plug-in to support code stored in Github. Although Team Foundation Server (TFS) is designed to manage code, projects and build, it does not have to. Teams can choose to use TFS for just one or two of those pieces, or just Visual Studio without TFS. Atlassian has moved its most popular product from just on-premises, which requires a server, to availability through the Web, and has recently made it easier to obtain individual pieces of its software: just JIRA for issue tracking, Fisheye for code review, Stash or Stash Data Center as a Git server, Confluence as a wiki, and so on.
This article covers eight pieces of an ALM system. The next step is to examine the current ALM system. Ask if each piece covers everything sufficiently. If not, there is a gap. The next question is if the gap is worth the investment and time to add that particular piece.
If there are a large number of gaps, you might consider one of the larger, full-stack ALM suites, especially if your organization uses Java, .NET, Ruby or another technology the full-featured suite was created for. In that case, you may want to keep the pieces you already have in place. That may be fine, because the full-featured suites continue to respond to customer demand, allowing the team to keep SVN, or Git, or Jenkins, or TeamCity, and still use TFS or Atlassian products.
Take a look at the evolution of ALM tools
Listen to Matt Heusser's advice on starting to make Agile changes
Evaluate cloud-based ALM security
Read up on the intersection of Agile and ALM
Take a critical look at ALM tools