Subversion – Jira – Jenkins Integration Overview
In an Application Lifecycle Management (ALM) ecosystem, the choice of systems and the collaboration between the cross-functional teams play a great role. While the choice of systems impacts the productivity of a team, scross-functional collaboration helps the teams get complete context of the business requirements.
Best-of-breed systems such as Jira, Jenkins, and Subversion bring rich functionalities to the ecosystem. When Subversion is integrated with Jira and Jenkins, all stakeholders have real-time visibility into the commits made by the development team. It is also easier to enforce authentic commits against each work item and access the changes/edits made to the commit files from Jira itself.
How Subversion – Jira – Jenkins integration is beneficial for an enterprise
- Track commit volume, track commit trends and edits/changes to commit files in real time
- Enforce authentic commits to make sure each commit is happening against a scheduled and open workitem
- Eliminate manual effort to close Jira workitem by automating the state transition on Subversion commit
With Subversion + Jira + Jenkins integration, enterprises can:
How OpsHub Integration Manager integrates Subversion, jira, and Jenkins
OpsHub Integration Manager integrates Subversion, Jira, and Jenkins bi-directionally. It ensures that all historical and current data is available to each user, in that user’s preferred system, with full context, in real-time. All the details related to a commit made against a work-item in Jira can be tracked from Jira itself. For example, for each commit that development team makes in Subversion, Subversion synchronizes a ‘commit entity’ linked to the specific requirement id back to Jira. The integration of Jenkins also ensures elimination of developer’s effort to close Jira workitem by automating the state transition on Subversion commit.
Popularly synchronized entities
Use Case: Subversion integration with Jira and Jenkins
Problem statement: No control on backlogs getting committed – therefore, anyone can commit on a defect that is not even present in the active sprint.
Solution: Pre-commit hooks can be configured in Subversion which calls OpsHub web service to check if Jira ID against which commit is happening is valid or not and if it exists in active sprint.
- A developer works on a ‘defect’ D1 in Jira.
- The developer then commits against the ‘defect’ D2 in Subversion.
- As D2 is not there in active sprint, the commit fails, and developer gets instant message that defect is not in active sprint or not assigned to the person who committed.
Benefits of integration for Subversion and Jira users
- Each commit can be traced back to its respective workitem at any given point in time from Subversion itself
- Enforced checkpoints ensure that no mandatory steps/checks are missed while making a commit – this leads to high success rate for commits
- Traceability for business requirements throughout the ALM tool chain
- Direct visibility into customer issues and their priorities
- Visibility into the volume, quality of commits, and commit trends in real-time