What is Continuous Integration and why use it?

Most CI servers are now able to do Continuous Deployment too. What is Continuous Deployment? It's the final touch to move even faster. You can set your CI server to deploy your software after each green build, usually of the master branch (with Git). It could mean push the code/build to all your servers, backup the database, run database migrations and then restart whatever that needs to be restarted, without any human interaction.

First of all, what does CI stand for? It means Continuous Integration. Continuous Integration is at its root a practice where you merge the work of all your developers several times a day. Each integration is verified by your automated tests and built (when it needs to be, for compiled languages mostly).

These days however, 'CI' generally refers to the server part of the process, where you run your tests and build your application.

At Rainforest, like at many startups, we need to move fast. We write tested software and push many times per day to production. CI is the crucial step in our workflow that enables us to ship up to 20 times daily. CI also fits perfectly with our branching strategy and environment strategy.

Pull requests

What happens on a daily basis - many times per day in fact - is we write code for a feature or a bug fix. We do so in a feature branch. When it's done, we push our branch to GitHub and create a pull request. Every pull request triggers a build at Circle CI. After code review by one or more engineer, once we have a green build, we know it's safe to merge. If the build is failing, it should not be merged before fixing it.

Once it's merged to the develop branch, the fully automated QA and deploy process can start.

Deploying

The QA and deploy process starts with another pull request to master, from the develop branch. This release PR is important as this is where we trigger our Rainforest tests. Basically, Circle CI will receive the usual hook, but for this branch, after the build is green for our unit tests, we deploy to our staging and QA environments and then, a Rainforest run is triggered. By the way, we explained how to do that integration in a previous post. Once our Rainforest run is done and green, we know it is safe to be deployed.

As the last step, merging this pull request to our master branch will trigger the deploy process at Circle CI, pushing this to production.

CI is really important to move fast, or just to move with the confidence you are not breaking anything. It is easy to break software when you write untested code, and I think it is almost as easy to do with tests, but without CI. Your CI server will make sure your new code will not have unexpected side effects by running all the tests for your app whenever anyone on your team makes a change.

This means that we know, commit by commit, whether anything got broken. Rather than focus on a regular 'release cycle', we can have everyone on our team release their code whenever it's ready. We'll cover the ins and outs of continuous deployment in great detail in later posts, but essentially we (and many others) believe that being able to ship early and often is a key competitive advantage in today's technology industry.

A CI server will usually tell you if it all is ok (a "green" build) or if you broke something (a "red" build). You don't want to break the build, but if you do, you need to fix it.

GitHub now provides a nice integration with CI. Here are examples of red and green builds:

As you can see, there was very little human interaction to ensure quality (unit tests + QA over multiple browsers) or deployment. This whole process enables us to move fast and be confident in what we ship, be it on the unit level or for any Rainforest test we have, testing with multiple browsers.

CI is the glue making the process work efficiently. We think it's the perfect workflow. I encourage you to setup a CI server and start shipping faster, with peace of mind.

I hope that'll help you get your deployment process as friction-less as possible. For more tips from experts on implementing CI and CD more effectively, download our free ebook Getting to Continuous Deployment.

Hosted:

• Circle CI: it's crazy fast as they run your tests in parallel! (Rainforest uses Circle CI)
• Github Actions: built directly into where you'd probably be hosting your code
• Gitlab CI: hosted, or not
• Travis CI: they are free for Open Source projects
• Codeship: excellent support and really good community and documentation
• For a longer list, checkout this repo

Self-hosted:

• Drone: open source, it was extracted from Drone.io. It is really easy to get up and running. I actually wrote a tutorial on my personal blog a few months ago: "From zero to fully working CI server in less than 10 minutes with Drone & Docker".
• Jenkins: one of the most popular CI servers, if not the most popular
• Gitlab CI: hosted, or not

‍