Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. Its more than just a new process, its got a new philosophy. Continuous Integration is backed by several important principles and practices.
- Maintain a single source repository
- Automate the build
- Make your build self-testing
- Every commit should build 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
- Developers check out code into their private work-spaces.
- When done, commit the changes to the repository.
- The CI server monitors the repository and checks out changes when they
- The CI server builds the system and runs unit and integration tests.
- The CI server releases deploy-able artifacts for testing.
- The CI server assigns a build label to the version of the code it just built.
- The CI server informs the team of the successful build.
- If the build or tests fail, the CI server alerts the team.
- The team fix the issue at the earliest opportunity.
- Continue to continually integrate and test throughout the project.
- Check in frequently
- Don’t check in broken code
- Don’t check in untested code
- Don’t check in when the build is broken
- Don’t go home after checking in until the system builds
Many teams develop rituals around these policies, meaning the teams effectively manage themselves, removing the need to enforce policies from on high. In Suits, they have a can-opener… whats your ritual for success?
Continuous Deployment is closely related to Continuous Integration and refers to the release into production of software that passes the automated tests. Theory goes that by adopting both Continuous Integration and Continuous Deployment, you not only reduce risks and catch bugs quickly, but also move rapidly to working software. With low-risk releases, you can quickly adapt to business requirements and user needs. This allows for greater collaboration between ops and delivery, fueling real change in your organization, and turning your release process into a business advantage.
My question is who is using Jenkins?
Update Note: Feb 16, 2017
So I’ve been asking and pondering and researching and found out that Keith Manning from my buddies over at Manheim had already covered this topic in their Fullstack Meetup a year before, well back in 2015. (I still think of 2016 as my releap year, slightly drawn out by two months) Sep 14, 2015 they hosted, Continuous Delivery with Jenkins and the Build Pipeline Plugin. Bummer I missed it.