Once in a while a new process comes along and blows your friggin mind. That's what's been happening with me and my team recently, once our organization finally implemented Continuous Integration (CI) and Continuous Delivery (CD) on a large scale. These two processes have enabled our business to merge changes and push changes to production much more quickly than we could have before.
In short, now that we have CI/CD, I cannot even fathom how we got any work done and delivered without it.
What are CI and CD?
Let's use ThoughtWorks's definition of Continuous Integration:
"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."
By its very nature, CI tends to catch small problems before they become big problems, by forcing the developers to merge their small changes together and making them sort out any issues that arise.
One major reason you would want to use a CI process is to enable the Continuous Delivery (CD) process, which has a great definition over on puppet.com:
"Continuous delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing."
The only way CD works is if you can test changes in a production-like environment, and so CD processes often introduce a "staging" environment in which changes can be tested. Further, because the deployment and testing are automated, you can be assured that once your changes are deployed to production they will just work.
Our Team's Process
Prior to this, we'd been doing what I believe a lot of organizations are still doing: manual releases. That process generally went like this:
- Software developers check in their (hopefully working) code to source control.
- Developers then make a release package, which contains all of the code that they need to deploy to the staging environment.
- Developers contact our server group to make the staging deployment.
- Server group makes the deployment, tells the developers to check.
- Developers check, confirm that it looks good, notify their managers.
- Managers tell the stakeholders (e.g. people that care that this code gets deployed) to check out the system in staging, connected to test data.
- Stakeholders confirm that the system looks good.
- Developers make a second release package, this time for the QA environment.
- Server team moves system to QA.
- QA engineers test the changes, then notify developers and server team if the tests pass.
- Developers make yet another release package, this time for production.
- Developers contact server group, server group schedules a deployment for sometime off-hours (e.g. late at night).
- Once system is deployed, developers and server group confirm that it looks good.
- If anything bad happens, server team rolls back to the previous deployment.
Whew! That's a lot of steps, and at any time during that process something bad could happen and we might end up needing to start the whole thing over again. It clearly wasn't an ideal process.
But Jerry (who pointed out to me that our organization at the time was not agile like we thought, rather it was a lean waterfall process) and his team finally finished developing our company's CI/CD process, and is it ever a joy to use. Now our deployment process looks like this:
- Developers check in their (hopefully working) code.
- Said code gets automatically deployed to a development environment.
- Approvals are needed from the developer and his/her manager to deploy to the QA environment.
- Once deployed to QA, the QA engineers test the system.
- Once the test passes, the exact same code gets approval and is deployed to production.
- Once on production, the stakeholders are notified.
From 14 steps down to 6, and most of the process is automated. That's a huge improvement, and I can't even begin to calculate the total time it has saved me and my team, just from a development standpoint.
Is It More Work?
Yes, but only in the beginning. Let's be clear, there is some extra work involved in setting this up.
First of all, your organization needs some extra physical infrastructure (e.g. build servers) that you should probably have anyway, though not everyone does.
Secondly, somebody (most likely the developers) has to take of things like configuration and transforms (in our particular case, because we do everything in ASP.NET, we developers end up taking care of the web.config transforms), but your developers are probably already doing that work, just not in a unified manner.
Third, depending on how complicated your CI/CD process is, it might take some time to teach your developers and server admins the proper way to implement CI/CD, but that's time well spent and we need more teachers anyway.
Fourth, good, comprehensive testing becomes critically important with these processes. Failing tests cause a stop in delivery, and so writing valuable tests is now a requirement more than an option when using CI/CD.
Those obstacles are temporary, even if they are difficult, and once it is set up Continuous Integration and Continuous Delivery are truly a joy to use. They has saved me more time in the first month of our CI/CD process being operational than I care to admit.
Developers of the world: if you're not already on a CI/CD process, start bugging your bosses and coworkers about setting one up. It's becoming (if it isn't already) an integral part of running a modern software development shop, and it takes what was once a time-consuming manual process (deploying an app to production) and dramatically speeds it up. There will come a time when Continuous Integration and Continuous Delivery are no longer optional, and that time is rapidly approaching.
Are your teams using Continuous Integration or Continuous Delivery? If so, how do you like your versions of those processes? Is there anyone out there who is dissatisfied with how their CI/CD process works? Sound off in the comments!
Happy Coding!
Page image is Baggage Claim Haneda 2nd Terminal, found on Wikimedia and used under license.
