Overview
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 Phunkwith My Heart." ;-)
The pre-tested commits feature alleviates this issue by making use of Git's lightweight branches. Note: this only works with Git. What this means is that developers and managers are no longer unpleasantly surprised by broken builds. :-)
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 calledintegration . All developers are supposed to check code into this branch. Nobody commits to the controller.
Once code is committed into the integration branch, Jenkins kicks in and builds. The code is merged into the controller only if the build is successful. Other developers check out the code from the controller and use it. Thus, if bad code makes it in, only the integration branch is affected and the controller keeps humming along.
Setting up Git Repositories
A. Administrator sets up integration branch on the remote repository:
>git clone ssh://git@git.cloudbees.com/tutorial/tutorial.git
>cd tutorial;
> git branch integration # create a local integration branch
>git push origin integration # push the branch to remote
>git branch -r # lists all the branches; should show something like
origin/HEAD -> origin/controller
origin/integration
origin/controller
B. Developer sets up a PhunkyFeature branch in the local repository:
>git clone ssh://git@git.cloudbees.com/tutorial/tutorial.git
>git branch PhunkyFeature
Configuring Jenkins
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 controller 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 controller for Branch to push and origin for Target Remote Name .
Development Flow
The developer hacks away at his code in the local branch.
> git checkout PhunkyFeature
> #hack away
> git add files; git commit -m "hacked away and unknowingly introduced a bug, was too lazy to test it"
Developer merges the local branch into the integration repository.
>git checkout integration origin/integration # switch to integration branch
>git merge PhunkyFeature # merge changes
>git push origin integration # commit the integration branch
Jenkins Flow
As soon as the developer checks in the code (depending on your poll/push settings), Jenkins detects that the integration branch has a change. It checks out the integration branch and merges it into the controller branch. It then builds the code and, if the build is successful, pushes the controller to the origin.
Changes are reflected to the controller only on success, thus minimizing the impact of bad checkinsfor the wider development team.
Relevant Documentation
Thanks,
Harpreet Singh
Senior Director, Product Management
CloudBees
cloudbees.com