Jenkins is used to reduce downtime for development teams by building and testing code often (often on each commit). However for large projects where the build cycle time is large, this delay may already be too late.
For example, a developer may check in broken code, Jenkins will build and, after a while, go red. Developers in the interim may have checked out the broken source code and are now impacted by the downtime. Time to sing along, “No, no, no - don’t break my stable branch,” cued to the Black Eyed Peas song, “Don’t Phunk with My Heart.” ;-)
To accomplish this, you need multiple Git branches. The sample scenario here is as follows:
- A developer works on particular local branch for his feature named PhunkyFeature.
- An administrator has setup a remote branch called integration. All developers are supposed to check code into this branch. Nobody commits to the master.
- Once code is committed into the integration branch, Jenkins kicks in and builds. The code is merged into the master only if the build is successful. Other developers check out the code from the master and use it. Thus, if bad code makes it in, only the integration branch is affected and the master keeps humming along.
Setting up Git Repositories
A. Administrator sets up integration branch on the remote repository:
- Go to your Jenkins job configuration under the Source Code Management Git section of the page.
- Click Advanced and select Merge before build. Enter origin for the Name of the repository and enter master for Branch to merge to.
- Under the Post Build section, enable the Git Publisher checkbox and enable Push Only If Build Succeeds and Merge Results. Under Branches, enter master for Branch to push and origin for Target Remote Name.
Changes are reflected to the master only on success, thus minimizing the impact of bad checkins for the wider development team.