July 1st, 2020 by inflectra
One of the focus areas in the upcoming release v6.5.2 of SpiraTeam and SpiraPlan is to streamline and improve the process for managing code within Spira, and providing better traceability between source code revisions, CI builds, DevOps pipelines, and Spira artifacts such as requirements, user stories, tasks, defects and change requests. In this article we describe some of the enhancements coming in the next version.
For those who attended InflectraCon 2019, you will remember that we had a session on code management and developer workflows:
The new enhancements in this release, build upon the functionality in the Spira platform that we discussed at InflectraCon.
SpiraTeam and SpiraPlan have long had the ability to integrate with a wide variety of Continuous Integration (CI) / Continuous Deployment (CD) tools and DevOps pipeline engines, including Jenkins, TeamCity, Azure DevOps Pipelines, and Bamboo.
In this latest update, we have extended the Build pages to be able to show the revisions from multiple Git branches in a single page. Previously if you had teams working in multiple feature branches, when they were merged into the main branch, you would need to toggle between the branches for the revisions to be displayed. Now we can show all of the revisions in a CI build pipeline event in a single page:
When you use the special [XX:123] artifact tokens as part of your Git commit message, it will then display the list of associated artifacts that were fixed, implemented or updated in that build:
One common need is the ability to see where a specific user story, requirement, task, defect, or other artifact is in terms of the CI pipeline. For example, has the feature been built in a feature branch, has it been merged into the main branch, has it been deployed into staging, or into production.
We have now added the build information as a new type of association on every artifact in Spira. In this example (taken from our internal SpiraPlan product), you can see that this particular feature has been developed and built as part of the 'develop' branch as well as being associated with a specific Git revision.
The benefit is that when a tester or QA team member has to test that specific feature, they will know which environment it has built on, and where it has been deployed.
For example, if you use the popular GitFlow branch and merging strategy for Git (which we use):
Then when you create and commit a new feature, it will typically flow through the following stages:
In the example below, you can see the same feature in our internal Spira has now been deployed into production, having been part of the feature > develop > master GitFlow-based pipeline:
Now that we have added this functionality to Spira' source code module, we have the following future plans: