Continuous Integration and the Release Maturity Model
By: Kendrick Burson
(Interested in Continuous Integration? Check out the recorded webinar!)
The topic that we are discussing for the webinar is CI, continuous Integration, which is a big part of continuous delivery. Continuous Delivery is a situation where a team has sufficient automation tools in place to take a code change commit to a source repository all the way through build ,test ,verify and finally deploy to a production server. The coding practices to maintain this system add some overhead including a requirement on producing good automated tests together with feature code and an attention to the continuous build server (when a build fails the team stops what they are doing to fix the build.)
There are many paths to take into this realm, we can approach from a tool perspective — how to choose the tool that is right for you. There are many open source and commercial tool offerings, each claiming to simplify the development team’s work while increasing confidence in the published artifacts. Project Managers need to weigh in the needs of the company against the various feature sets of these tools. Many commercial tools strive are kitchen sink solutions targeting large scale enterprise development. Often times these solutions create complications and bottlenecks for small projects that do not need to collaborate with 5000 developers and multiple product lines, or multiple versions. On the other hand some companies need greater central control over the build and release process across their enterprise development groups.
Tools for CI include:
* Build Scheduler
– e.g. Jenkins, Team City, Anthill Pro, Go, Bamboo, CruiseControl…
* SCM/RCS (Source Control Management/Revision Control System)
– e.g. SVN, Git, Perforce, Mercurial, TFS…
* Build automation scripts
– e.g. Maven, Ant, Nant, MSBuild, Rake…
* Testing frameworks
– e.g. xUnit (Java, Dot Net, PHP, Ruby), QTest, GTest, TestNG, Selenium/WebDriver, WaTiN, Watir, SoapUI…
* Source Code Analysis (Dependency Analysis, Code Coverage, Rules Compliance)
– e.g. PMD/CPD, FindBugs, CheckStyle, FxCop, JDepend, NDepend, Coberatura, Emma, NCover…
* Publishing
– scripting and plugins to deploy production artifact in either Java web Archive, IIS WebSite, MSI, Ruby Gems…
There are tradeoffs for each tool selection.
One of the first considerations a PM needs to address is the project team’s Release Management Maturity. The various tools fit into levels of maturity for the project teams process.
The first and foremost requirement for enterprise development is a solid SCM/RCS system. Some companies today still do not use a source repository. The project team needs to identify a balance of corporate confidence, control and developer efficiency. The industry favorites in the open source community are Subversion and Git, with dozens of other solutions in use to a lesser degree. On the Commercial side Perforce and TFS have strong followings. What the team needs most from their SCM/RCS is:
-
- Checkout/Update source code from repository
-
- Commit changes to source Repository
-
- Search commit history for changes made, when, why and by whom
-
- Revert/Rollback changes made to any version in history
-
- Merge local changes with those committed by other developers
-
- Branching and Merging for hot fixes and private development sandboxes
-
- Label/Tag revisions for release identification
All teams need some form of build automation whether they use shell scripts or dedicated build scripting frameworks like Maven, Ant, VBScript or MSBuild. These build automation scripts should be run by the developers every time they want to commit their code to the source repository. These build scripts should compile the source code into executable artifacts (exe, jar, war) checking and validating syntax along the way. Some interpreted languages such as PHP do not require a build phase.
As teams mature they will want some form of source code analysis to verify coding standards and rules compliance.
As teams mature they will want to focus on automated testing with Unit, Integration, Functional, Stress/Load and Performance testing. Each of these levels is a hierarchy in the testing pyramid. Most teams new to automated testing focus on Integration Tests when all teams should start at the lowest level with Unit Tests. As teams grow and mature they should work their way up the pyramid of testing levels. Each additional level requires more sophisticated control mechanisms including specialized execution environments (Integration servers).
As the teams mature they will want their compiled, tested and verified artifacts to be archived and deployed to either a final QA server, and/or the production server for access by customers.
To learn more about Continuous Integration, view our recorded webinar: Continuous Integration and the Release Maturity Model
