Let's talk about continuous integration. And, yes, I do mean "continuous integration" -- not "continuous delivery."
Continuous integration -- the Agile technique of checking in code in small increments and testing it against the larger code base -- is a longstanding development practice. But as software pros set their sights on continuous delivery, continuous integration gets short shrift.
Instead of seeking to perfect the practice, software pros take continuous integration for granted. They have been doing it for so long, they no longer question whether they're doing it right. In a recent conversation, software development consultant Jeffery Payne, CEO of Coveros, in Fairfax Va., told me this approach is wrong.
Continuous integration: Not just the build
Payne said that when software pros talk about continuous integration, most are referring to the automated build process. "Build is their definition of done." But build is only half the battle. A successful build tells you that, syntactically, the code holds together, he explained. "But it doesn't say a thing about how the code works." The practice of continuous integration should also include automatic deployment of the code to the platform on which it will reside, Payne said. "You're making sure it is configured properly and that all of the integration issues are addressed."
Making sure continuous integration also includes automated deployment -- rather than outlining a broad strategy for continuous delivery -- is a practical approach because, done right, the former naturally leads to the latter, Payne said. "When you start with continuous integration, you set the stage for continuous delivery. When your continuous integration [practice] is good and strong, continuous delivery is the next logical step."
In our conversation Payne also discussed how he sees continuous integration, continuous delivery and automated testing as part of the larger DevOps environment. In the process, he shared highlights of his keynote address, "Why DevOps Changes Everything," which he will deliver at the Agile Development Conference West, in Las Vegas in June 2015.
Everything is code
When continuous integration takes the deployment environment into account, a software team has essentially created a situation Payne refers to as "everything is code." In other words, the infrastructure on which the code will be deployed, not just the application itself, is expressed as code.
The DevOps approach allows for early detection of problems that previously could only be detected downstream. "You can see how code integrates into its platform," Payne said. What's more, DevOps leads to greater efficiencies for QA and test. "If you set up a virtualized test environment in the cloud, test pros are no longer dependent on operations people to set up a staging environment," he said. "You are controlling everything" about the configuration. That's a major change from the traditional approach where the only control was source code, Payne said. "You had to roll back and figure what had changed."
So, let us know what you think. Does your continuous integration practice encompass DevOps? Or are you narrowly focused on automating the build? Are you doing continuous delivery? If so, how well does your integration process work?
Read how senior quality engineer Jeff Porter successfully mixed Agile and continuous delivery techniques
Discover the link between continuous delivery and continuous improvement
Check out this handbook about the importance of continuous integration in continuous delivery
Learn more about the automation side of continuous delivery