10 Continuous Integration Best Practices
Frequent integrations with automatic build and test leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. Since the first publication of Martin Fowler's article on Continuous Integration the method fastly gained popularity. In the latest version he focusses more on the best practices:
- Maintain a Single Source Repository.
- Automate the Build
- Make Your Build Self-Testing
- Everyone Commits Every Day
- Every Commit Should Build the Mainline on an Integration Machine
- Keep the Build Fast
- Test in a Clone of the Production Environment
- Make it Easy for Anyone to Get the Latest Executable
- Everyone can see what's happening
- Automate Deployment
posted by Ronny De Winter at Wednesday, May 03, 2006
9 Comments:
Your post is helpful and informative
From my experience using cc.net :
From our experience using CC.NET.
Make complete build : A full build from scratch is the only way to be sure the whole build process is ok. Everything should come from version control tool and must be cleaned at end.
Monitor build time : Look frequently to how fast is the build. If you see that your build slowly takt more and more time (because of unit test for exemple), when you will end-up with a delayed failing build notification, or even worse (build that takes 3 days!). Watch out to see the build time trends.
Backup artefacts : The Continuous integration artefact fodler must be part of a backup plan. Statistics, history, metrics, and all these things are very important as it is the project life ! So add it to your backup plan
Monitor CI server's disk free-space : No more free space on CI server can stop continuous integration for days or weeks ! Have a look to this value, or best, add this metrics inside CI dashboard.
CI for each active dev branch : A CI job should be created for each active branch of your project. This does not include very short life branch called 'feature branch'.
Notify everyone in the project : The worst thing was can occurs with CI is : the build failed, but the notification recipients are not here ! So, nobody knows that there is an issue. So notofy everyone in the project, use different notification technics (email, rss, Naztabag)
Secure access to CI configuration : Some CI services provide a configuration panel directly in the dashboard. If so, any modification MUST be denied to guest users. Only authentified admin/moderator can access the configuration.
Failed build report : A failure report (when build fails) must be concise and should point exactly which task is failing (compilation, unit test, deploy)
That's a great practice really.. I want to try it.
Your post only obfuscates the google search results on "best practices of software integration", because it is higher than the original Martin Fowler's article. Congratulations - you rewrite the index table of a popular article, then you copy-paste the link to the original, give a post a catchy name, and you are on the top.
Good post. This is a very nice blog that i will definitively come back to more times this year. Thanks for informative post.
Now you make it easy for me to understand and implement the concept. Thank you for the post really a great efforts. I am really happy to see your blog.
Very thoughtful words, thank you and hope that you will give us more information soon. Thanks for very thoughtful words. Hope to get more soon.
Top 25 Metrics to Measure in a Continuous Testing Process - Click here to Download PDF
Do you know that there are best Windproof pipe lighters throughout the internet? Of course,It is hard to light the tobacco inside the channel with ordinary lighters. Nonetheless, the channel lighters have become the most significant and commendable instrument for lighting pipe.
Post a Comment
Read more about Software Quality at the <<Software Quality Weblog Home