Why Continuous Integration and Delivery?
Did you know that Amazon.com is updated every few seconds? Yeah, that’s right. While you were shopping, Amazon.com’s Dev Team probably pushed new software to take add features, capabilities, display products or analyze the activity on the site. Everyday Etsy also deploys multiple times with minor and even major fixes and changes. Both of these companies, along with a growing number, while doing high transaction e-commerce and other important business, follow a continuous delivery process.
The most successful development teams use continuous integration and delivery. This has become a leading practice to build high quality, reliable and well respected software. Your team may not need to deploy everyday or you may not need to update a website every few seconds. But in the end, your team delivers a product or service of some type. Continuous Integration and Delivery is a key element of what makes high expectation software development possible.
Where We’re Going…
Over the next few weeks we’re going to take a look at building out a development environment in CenturyLink Cloud that follows the key principles behind continous integration and move eventually to continuous deployment. Before we start move into the deep technical topics, I’ll cover exactly what these things are and why a team wants to use continuous integration and prospectively work toward continuous deployment.
Continuous Integration is defined on wikipedia as, ”In software engineering, continuous integration (CI) implements continuous processes of applying quality control — small pieces of effort, applied frequently. Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.”
One of the key ways in which development teams implement continuous integration is to setup a build server using one of the many on the market; CruiseControl, Jenkins, Hudson or TeamCity. All have various strengths and weaknesses, but the key for each one is the ability for developers to commit code on a frequent basis and have those changes integrated often, in a timely manner with any errors being detected immediately.
The key technical implementations for continuous deployment are:
- Source Control: This might be subversion, git, or mercurial. These days it is of utmost important to have any and all code assets under source control.
- Automated Build: The build, everytime it is kicked off, needs to be 100% automated. No manual intervention should take place.
- Build Self-Testing: This follows the automated build requirement, to ensure a regression and other various automated tests are run after every commit, change, deployment or other alteration.
- Master ALWAYS Builds: The master trunk of code must always build. If a build is broke for any reason, immediately it must be fixed or the development rythm stops.
- Every Commit Gets Built: Every commit gets built. No commits are skipped, none are excluded. Any and all collateral must be committed and included for each build.
- Fast Building: The build must remain fast. Anything over a minute is getting precarious and anything over 5 minutes is a distinctive issue and should be considered a risk to the project.
- Latest Deliverables Available 24/7: All deliverables, if a web site the site itself, if a stand alone application the installable application must be available at all times. The most recently built copy need to be available.
- Automate Deployment: It is ideal to have the software that is built, deploy to an installer, a web site, or end point that is as similar to the receiving customer (or production) environment as possible.
To learn even more about the ideas and history of continuous integration check out these books and links. A great book to read on the topic is “Continuous Integration: Improving Software Quality and Reducing Risk” by Paul Duvall and Andrew Glover. One of the historical elements of continuous integration is derived from continual improvement, part of the trove of knowledge and material from W. Edwards Deming.
Continuous Deployment (AKA Continuous Delivery) as defined on Wikipedia, “is a Pattern Language in growing use in software development to improve the process of software delivery. Techniques such as automated testing, continuous integration and continuous deployment allow software to be developed to a high standard and easily packaged and deployed to test environments, resulting in the ability to rapidly, reliably and repeatedly push out enhancements and bug fixes to customers at low risk and with minimal manual overhead. The technique was one of the assumptions of Extreme Programming but at an enterprise level has developed into a discipline of its own, with job descriptions for roles such as “Buildmaster” calling for CD skills as mandatory.”
Continuous Delivery basically takes the CI, Continuous Integration concept, and adds that it must be a part of the practice to actually deliver the code on a regular basis. There is some great material on CD available via some of the great companies out there taking this approach everyday. Here’s some of those articles:
- Etsy “How does Etsy manage development and operations?”
- Facebook “What kind of automated testing does Facebook do?”
- Inform IT “Analysis for Continuous Delivery: Five Core Practices”
Overall the two, CI and CD, are often used interchangeably, even though they do have very minor differences. The key idea, regardless of what phrase you use is that delivery is always happening in some way and the end goal is a deliverable product on a rapid frequency. Now that the core tenants are covered, the next article in this this series we’ll dive into:
- Setting up a web project to use for working on within a continuous delivery enabled environment.
- From there we’ll take that web project and set it up using some of the common continuous integration servers.
- Then we’ll script, automate and build whatever else is needed to have the web project deployed to a production server.