Although we hate to admit it (they made us do it) big corporations can sometimes get it right, even process-wise. Working within small agile teams we used to laugh about big organizations having way too detailed procedures within their agile environments. And guess what?
At the very peak of our hyper-agile cycle, we found salvation in similar procedures. By implementing Continuous Integration/Continuous Delivery our DevOps team managed to rethink the way we approached to delivering software.
Here’s how we pulled this one off.
CI – Ensuring the quality of code through unit testing
CI stands for Continuous Integration and it is a development practice where developers integrate their code into a shared repository, usually once per day. It involves writing tests and let’s be honest, no one likes writing tests but CI makes it a bit more fun. Seeing your commit pass the tests making it a release candidate makes it worthwhile.
There are a lot of tools that can help you implement CI in your stack (CircleCI, TravisCI, and TeamCity just to name a few).
They certainly do their job (they even have Slack integrations!) and your code runs tests in their cloud, which is fine since you’re only interested in the test results. TravisCI is a part of our stack now, and we’re quite happy with it. We’re currently looking into implementing something similar, but more “in-house” on our dev server, this is where Docker will come in handy since CI/CD are one of the most popular use cases for Docker.
CD – Farewell to painful deployment
The practice of CD further extends CI by making sure that software is always in a state that can be deployed to users and aims to make the actual deployment process painless and very fast. CD can stand for Continuous Deployment or Continuous Delivery and those are two different things!
Continuous Delivery means that the development team ensures every change can be deployed to production at any time. While Continuous Deployment means deploying (duh!) the changes to production automatically. With that in mind, to do continuous deployment one must be doing continuous delivery.
Enter DevOps, a rather new movement within the software world which encourages collaboration between the developer teams and operations. CD is a step in the DevOps direction because it brings developers and operations closer together than ever before!
DOCKER – My new best friend
Docker containers wrap a piece of software in a complete filesystem that contains everything needed to run your app: code, runtime, system tools, system libraries or anything that can be installed on a server. This guarantees that the software will always run the same, regardless of its environment eliminating the all familiar “But it works on my machine” problem. This is great because it ensures that your dev environment is a complete clone of the production environment, so if the tests pass in your dev environment it means that the changes being tested are ready to be pushed to production. In other words, if you’re not using Docker you’ve been living under a rock and you’re missing out!
This is where things get a bit more interesting. Since we wanted to deploy apps to our own server rather than some cloud I took the liberty of writing a NodeJS server that listens for webhooks from Github, Bitbucket, and TravisCI and pulls the code from the repository automatically if the tests pass. After a successful pull, the server runs a script for that specific project, and this script can do anything you want such as running commands like “npm install” to building Docker images and starting the app itself. You can even get creative and have this script run other scripts from your project directory, which is really neat.
From our point of view, CI and CD naturally extends and builds upon the Agile principles. If Agile methodology was forged to help developer teams steer away from the conventional waterfall method and shift towards a continuous development cycle, CI/CD is the procedure all of us have been waiting for.