Martin Fowler’s widely-accepted definition of Continuous Integration says: usually each person integrates at least daily The ambiguity around “usually” and “at least” leaves this somewhat open to interpretation, and the common question: Is my team really doing CI? Rather than dwelling on a specific definition of CI, I think it can be useful to focus on the reasons we care about CI. There are many benefits you might gain from CI, but let’s look at one of the big ones.

GitFlow is an error-prone waterfall process. It makes continuous integration and continuous deployment impossible. Just avoid it.

Until recently, I was using the wrong definition of Continuous Integration. You probably are, too. This is a bit of an embarassing mistake, at least for me, because I’ve heard the proper definition many times. And I talk about, and advocate for, CI, all the time. If you had asked me, I probably would have said something like “Automatically test your code, before it’s merged.” Interestingly, the simplest definition of continuous integration says nothing about testing—automatic or otherwise.

Not long ago, the idea of a one-button software build was novel. Now it seems blasé and continuous deployment takes that concept to the next level.

Conventional wisdom tells us that an automated test pipeline is the necessary first piece to Continuous Deployment. I challenge that thinking.

There is a lot of variety when it comes to Continuous Integration and Continuous Deployment (CI/CD) configurations. But I am constantly amazed by how many projects fail to even implement the absolute minimum CI configuration. In this article, I outline what I believe to be the absolute, bare minimum automated continuous integration tests that should exist on practically every project. These are table stakes. You ought to be embarrassed if your project doesn’t do these things.

How often do you find some code like this in your production code base? form.submit(function(event) { console.log("Submit hit"); var formData = { It’s obvious case of stray debugging code that never got cleaned up during code review. Or have you ever seen something like this, perhaps in your CI config? script: # - npm install # - npm test - ./script/test.sh This one is especially dangerous. It appears that someone commented out the core functionality of the automated test stage of CI!

Watch my video on this topic, too! In response to my previous article, Solo DevOps, a reader asked me to recommend a Continuous Integration (CI) tool to use with GitHub-hosted repositories. My choice is GitLab-CI, which integrates nicely with GitHub, even if you don’t want to switch to GitLab entirely. In this post, I walk through configuring GitLab-CI for a GitHub-hosted repository. I have chosen one of my real repositories, github.

I’ve been thinking a lot lately about how DevOps scales. DevOps, and related practices, get a lot of attention when it comes to scaling up at large organizations like Google and Netflix. But what about the other extreme of very small teams? This is a list of DevOps practices I use on the tiny scale: Solo projects. While most of these practices offer an immediate benefit, even for a single-person team, in most cases, the benefit grows as the team grows.