SpiraPlan provides the ability to integrate with continuous integration build servers such as Hudson and CruiseControl so that the status of builds can be recorded in SpiraPlan and linked to source code revisions and incidents. This provides traceability for each build, so that you can see what was changed in each build, what was tested and what was fixed.
With the move to continuous integration and continuous delivery, build management has become an important part of the software development and testing lifecycle. Build management is the process of collecting all of the assets to be included in a software release, performing all the automated tasks to compile, build and test the system and then deploy onto the development and testing environments in preparation for staging.
When you connect your continuous integration build server to SpiraPlan, you can add the “Recent Builds” widget to your project dashboard. This allows you to quickly see the status of the most recent builds to see if any corrective action is necessary.
SpiraPlan lets you associate the recorded builds with releases and iterations so that you can see the build history for each release and/or iteration in a project.
When the continuous integration server reports the status of a new build to SpiraPlan, it can include the list of source code revisions that were included in the build. This allows you to track which revisions (and consequently files) were included in the build and locate the files and users that may have caused the build failure.
When you execute either manual or automated tests in SpiraPlan, you have the option of linking the test runs to a specific build. This lets you review which tests were included in each build and whether there were any test failures.
In addition, you can associate incidents with the build that they were resolved in, enabling you to see all the items addressed in each build.
SpiraPlan will automatically scan the source code revisions included in the build for special artifact tokens that indicate which items in SpiraPlan were changed in the build. These items are then displayed in the ‘Associations’ tab associated with each build for robust traceability to the code level.
In addition, by assigning a test set to the same release or sprint that the build is reporting against, you can have the test set ‘auto-scheduled’ to run every time the pipeline completes and the build is successful:
This means that you can have smoke tests or fast regression test suites run every time the CI build is successful without needing to maintain a separate schedule inside of SpiraPlan.