I’ve said before that “DevOps engineer” is a bit of an oxymoron. I want to explore this idea a bit, by looking at what “DevOps engineers” do. When I do a job search for “DevOps engineer” on LinkedIn, here are some of the commonly required skills and experience: CI/CD pipelines Build automation Cloud providers (AWS, Google, Azure) Configuration management (Ansible, Chef, Puppet, etc) Containerization (Docker, Kubernetes) When we plot these skills and activities against the DevOps lifecycle, we see something like this:

A question I hear a lot is “How do I become a DevOps engineer?” I have two answers to this question. The first probably isn’t very satisfying: “DevOps Engineer” is an oxymoron. DevOps, as a philosophy, is the idea that Development and Operations should work together, in cooperation. My second answer addresses what I expect most people mean by the question: How can a developer adopt a more DevOps mindset, and possibly even move into operations?

I frequently encounter people wondering how Scrum and DevOps relate to each other. Or as it was recently put to me: Is DevOps better than Scrum? I like to answer this question with the aid of this popular DevOps worfklow diagram: This shows seven distinct activities in the DevOps lifecycle, and how they relate to two broad roals: Development, and Operations. Plan Create Verify Package Release Configuration Monitor Scrum, in contrast, defines the relationship between the business (personified by the Product Owner), and the development team, and provides 5 key activites:

Any task we can automate can be performed by a human. This is probably pretty obvious, but has some interesting implications.

I’m frequently asked about the ideal team structure for DevOps. A common sentiment suggests that the only “proper” way to do DevOps is by having developers and operations people on the same team. Otherwise, the thinking goes, you have the old dev and ops separation that DevOps is specifically intended to eliminate. While this comes from a good place, it’s not actually the only valid way to do DevOps. Let me offer two models for successful DevOps.

Are you tired of waiting for your colleagues to review your pull requests? Here are some quick tips to help your PRs filter to the top of the proverbial review queue. Short and sweet — Nobody likes reviewing long PRs. It might not be fair, but ten 10-line pull requests will generally get reviewed faster than a single 100-line pull request. Limit scope — One of the surest ways to confuse someone reading your change set is to mix concerns.

Sometimes a build tool requires version numbers. JavaScript tooling generally requires semantic versions. Go modules also require the use of semantic versioning. This is good, for publicly-used packages. But the overhead of managing the different types of changes indicated by semantic version increments isn’t always needed for internal projects—even when cross-project dependencies are in use. One simple strategy you can employ, in place of strict adeherence to semver, is a rolling compatibility window.

Yesterday I talked about three reasons we use versions in our software. Now I’m going to try to convince you that you may not even need version numbers at all! Or more accurately, that you can just use your version control commit ID as a version number. Why would you even want this? Well, simply put: Managing version numbers can be a pain. In the simplest case, a version number usually corresponds to a tag in a git repository.

Practically every software project must answer one question, regardless of the tech stack it uses, regardless of the team’s size, or which version control system it employs: What versioning scheme should we use? What does it really matter? Well, there are different reasons that the version scheme can matter. Let me offer three broad reasons to care about versions: Marketing — When your product is marketed to humans, it can be useful to have a human-friendly version number.

In my dreams, every new feature I develop is amazing. Customers love it, and they receive great value from its use. Yesterday I explained why rolling back is dangerous in these situations. Today I present you with my preferred alternative: Rolling forward The idea is fairly simple. When a critical failure occurs, rather than rolling back to a previously-built version of the software, we revert the broken change in git (or other VCS), then build and deploy a new version of the software.

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.