July 1st, 2020 by Adam Sandman
strategy devops software development integration
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.
Recap: Workflows and Code Management
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.
Continuous Integration (CI) Build Enhancements
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:
Visibility of Spira Artifacts in The DevOps Pipeline
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:
- Built as part of its feature branch on a CI server that builds that specific feature branch
- Merged into develop to be part of the next integrated release
- Finally merged into master once development is complete, and it is ready for deployment
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:
Future Plans
Now that we have added this functionality to Spira' source code module, we have the following future plans:
- Adding support for Git Pull Requests natively into Spira
- Creating support for additional CI tools such as CircleCI, TravisCI, etc.
- Integration with additional Git clients to make the commit process more seamless