ALM: User Guide

Many teams have already come to trust, and have verified, the effectiveness of continuous integration, a mechanism that makes it possible to deliver a quality product to the user at any moment. Instead of long releases, the product can be delivered as often as the process allows. This means the user does not have to wait three months for a product improvement in the next release, because a feature for another user is being developed in it and everything is broken or taken apart.

The goal of continuous integration is to build and check the product as early as possible and to tell the team about its quality. To implement continuous integration you can use, for example, Jenkins, which builds the product, runs unit and functional automated tests, tells ALM that a build is available, imports testing reports into ALM, and also reports which enhancements were implemented and which errors were fixed.

The development team focuses on quality builds, develops automated tests, and tries not to allow a long absence of quality builds.

Testers use continuous integration as a way to obtain quality product builds for manual testing and for making the final decision on whether a build is ready for delivery. Testers do not spend time checking broken builds, and can start testing as soon as a quality build appears in the list.

The ALM platform does not build or deploy applications. Special tools called build servers (builders), for example Jenkins and TeamCity, exist for that. These tools are configured for a continuous cycle of releasing builds and perform all the actions required for it.

ALM makes it possible to visualize builds and their status: build in progress, the build broke, successfully deployed, and so on. The "Builds" module describes the command used to integrate the build server with the platform. In addition to information about the build status, you can report the build location and an excerpt from its build log (or a link to the build log).

When updating build information, specify the commit (version or number). The system automatically links to this build the tasks and requirements that went into that commit. The system can also show the list of commits included in each build. This makes it much easier to locate the changes that caused the build or the automated tests to break.

If you build several applications within a single project, use the "Application" field, in which its name can be stored.

The "Builds" module shows all added builds, their status, and information about tests, implemented requirements, and defects found. This is the main information radiator of the readiness of the product (or of its builds) to be handed over for review by testers, analysts, customer representatives, or end users.

When many builds have accumulated, use the "Outdated" flag to mark outdated builds. Drop-down lists on forms show only current (not outdated) builds.