What Is Continuous Integration?

A few weeks ago, I came across a post on our community site that motivated me. Somehow, a developer stumbled upon CircleCI and decided to give it a try without actually knowing what CircleCI was used for. As someone who works for a CI company and obviously wants to spread the good news about the promise of Continuous Integration and Continuous Deployment, I love talking to other developers who may not necessarily be familiar with these concepts and watch their eyes open wide when they realize the scope of problems that they are able to solve with CircleCI. This particular user motivated me because it takes a lot of courage to show up in a public forum and admit that you don’t know something. I wish more people, including a younger version of myself, did this more often because it's one of the best ways to learn and grow.

Many years ago, when I first started using Linux, I had no idea what I was doing. Hidden in the archives of various forums from 2004, you may be able to find silly questions from a 14-year-old geek. I kept going because instead of rolling their eyes and ignoring me, someone took the time to explain to me that "cd" means change directory. I was grateful for the opportunity to pay some of those people back by whipping up a brief overview of what Continuous Integration and Continuous Deployment are and how CircleCI fits into the picture. With that in mind, here’s an explanation of what CI and CD are and how CircleCI fits into the process.

Continuous Integration

Basically, Continuous Integration refers to multiple developers pushing small, frequent changes to a shared repository or "master." They are integrating changes continuously rather than periodically, and thus (ta da!) Continuous Integration. There’s a lot out there on CI best practices you can adhere to, but I’d say one of the most important is to test all changes that you are making to your code base. You can accomplish this with unit tests, integration tests, and functional tests (also known as end-to-end tests).

Software testing, in general, is a huge topic with tons of concepts. The way that you write tests varies depending on what language and framework you are using.

Continuous Deployment

If your tests pass, then you can deploy your code to development, staging, production, etc., automatically. The specific way that you do this depends on what type of infrastructure you are deploying to. I think that Heroku is easiest to understand, and CircleCI’s default integration is pretty simple to set up.

If you don’t like the idea of continuous deployment, you can choose to deploy with a manual gate or trigger instead (AKA Continuous Delivery). However, you need to walk before you run, so I’d work on making sure you’re doing CI before you move onto CD.

CircleCI integrates with a VCS and automatically runs a series of steps every time that it detects a change to your repository.

A CircleCI build consists of a series of steps. Generally, they’re dependencies, testing, and deployment. We have some inference that can detect these automatically if you are using best practices for standard projects. You can also configure each of these phases manually.

Thank you to everyone who has ever helped a completely confused newbie in a forum and thank you to every completely confused newbie who is not afraid to ask questions! I hope this brief overview helps other developers who are new to these concepts. It’s definitely something I wish I had when I was first starting out.