Broken code is inevitable. Despite our best planning, automated tests, code review, and everything else, sooner or later (probably sooner) you’ll find that you’ve deployed a broken feature into production, and users of the system are complaining. Our natural instinct in such a case is to quickly jump back to the last working version—a process we colloquially call a “rollback”. Today I offer two reasons not to do this. Tomorrow I’ll talk about an alternative.

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.

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.