Your Agile DevOps Partner
Reading time: 6 minutes
Co-written with Darren McElligott.
What is DevOps?
DevOps is what happens when developers work hand-in-hand with the system administrators and other IT staff who are responsible for getting software into users’ hands and keeping it running. Discussion about it frequently centers on tools, but its core is a set of practices that are best understood as answers to a handful of key questions.
Does everyone understand what needs the project is meant to satisfy?
Modern organizations don’t have time for endless consultation, and can’t afford to have staff working at cross purposes. The single most important thing is for them to understand what the overall goal of the project is, so that they can pull in the same direction when they need to make on-the-spot decisions. For DevOps, this frequently comes down to knowing why this project takes priority over others, why an off-the-shelf solution wasn’t used, how the organization will judge the project’s success, and who gets to decide what corners to cut if things don’t go according to plan.
What constraints aren’t negotiable?
Not all corners can be cut, so in order to make the right DevOps decisions, project members must know what factors they simply have to live with. Does the software have to run in IE9? Does it have to be hosted on the company’s own machines, or is cloud-based deployment an option? Do they have to stick to a particular language because there isn’t budget to retrain the QA team in a new one? Inexperienced teams may scorn these as compromises, but mature teams will recognize and accept them as natural consequences of taking a holistic view of the entire business problem.
Is everything created by human beings in source control?
Source control is the beating heart of every successful modern software project. In order for every other aspect of DevOps to succeed, everything created directly by a human being must be committed to source control. This includes everything from exploratory design documents to application code and the runtime configuration for all of the environments and tools being used in development, testing, and deployment. This isn’t just the substrate for automating every other aspect of the development process: it is also insurance against the unavailability or departure of key team members.
Can everyone in the project set up a working environment with a single command?
No one wants to have to follow an incomplete or out-of-date guide to setting up a new machine for development, manual testing, automated testing, or production, so the steps to do this should be recorded in a script or installer. The more important reason for creating such a script, though, is that having it ensures that the organization actually knows how to do these things: requiring everything to be in a re-runnable form ensures that it’s part of the organization’s collective memory, and that crucial steps can be replicated at three in the morning, three countries away, by someone who’s never done them before.
Have you set up continuous integration workflow to check the health of the project?
Continuous Integration (CI) is the practice of automatically rebuilding, re-deploying, and re-testing software every time a change is made. Its benefits are well documented: as projects grow in size and complexity, CI ensures a bird’s-eye view of its overall state, so that fixes or changes in one part don’t cause problems in another. Today’s CI systems make it easy and cheap to integrate the build process, unit tests, integration tests, code quality checks, code coverage checks, and (if containerization is used) checks that the software can be deployed and is performant on a range of platforms.
Is anyone paying attention to the CI reports?
Hard data is is hard to come by, but more than one organization has set up CI without tasking someone to keep an eye on the reports and make sure that problems are acted on. Other organizations have made the subtler mistake of assigning responsibility to too many people, each of whom then either assumes that someone else is keeping an eye on things, or only looks at a small part of the overall picture. Having the project lead or scrum master give a “state of the dashboard” report at every status meeting is a common and effective solution.
Was "hello world" delivered to production using a repeatable production-quality process?
It’s tempting to deploy the first “hello world” version of a project by hand in order to show progress as early as possible. It’s equally tempting to deploy the second and third versions the same way, particularly since the project member or members responsible for doing so will quickly build up “muscle memory” for doing so. Instead, the team should put production-quality deployment in place first, in order to uncover and resolve dos and don’ts that might otherwise crop up at less opportune times.
Is knowledge of how to build, test, deploy, and monitor the project shared among team members?
The management of the software delivery process and tools is as important to the project as its source code, and, like source code, should be owned collectively. This doesn’t mean that everyone has to know how to do everything, but it does mean that at least two people must be able to do every step (even if doing it is as simple as knowing which script to run when, how to tell if it worked, and what to do if it didn’t).
How quickly can a new feature or change be delivered to production?
Today’s high-performing businesses are able to react quickly to the changing demands of their market. In practice, this often means being able to deliver new content and features to production in a predictable time, with a high probability of success, so that marketing, sales, and analytics can execute their plans, conduct experiments, and act on feedback without interruption or hesitation. This is often thought of as reducing cycle time, but in practice, the real goal of DevOps is to make cycles more predictable, since both planning and optimization are much easier once a machine does the same thing every time.
Can you measure the value you are delivering?
The definition of value varies from person to person and from project to project. While software developers are often tempted to measure value by the success of the technical implementation, DevOps as a whole can only be optimized by tracking the impact of changes on overall business value. This is often where DevOps interfaces with marketing, sales, and analytics most fruitfully: as just one example, if everyone involved in deploying software understands how analytics is measuring customer satisfaction, they can ensure that they don’t push changes that will make this quarter’s data incomparable with last quarter’s.
How often are improvements to the DevOps process being made?
Entropy guarantees that if we are not actively improving the process, it is getting worse. It is therefore crucial for continuous improvement to be as much a part of DevOps as it is to the software being built or the marketing practices being used to raise awareness of its existence. This is one of the key principles in Toyota’s Lean practices, where it is called the improvement kata, and without it, progress is usually short-lived.
How will this impact your business?
“We can build it, but we can’t get it out the door” is hard to distinguish from “we can’t build it,” and these days, “we can’t build it” is often the same as “the world is passing us by”. Implementing good DevOps practices will enable your business to get new ideas to market faster, and to try new experiments with less risk and fewer regrets. It can also make your organization less brittle by making it less reliant on a handful of key people. And while hard data is once again hard to come by, we at Rangle have seen that once technical staff start to think of optimizing operations holistically, they are more likely to collaborate meaningfully with their colleagues in sales, marketing, and analytics.
How Rangle’s expertise can put you on the right path
Deciding to start is the first and most important step. Once you have done that, we’re here to help. We have been an agile company from day one, and have made good DevOps practices core to our internal projects, our onboarding process, and the work we have done for dozens of clients in many different market sectors. From automated builds to repeatable tests and containerization, we have in-house expertise with leading technologies. We also know which superficially plausible approaches have hidden pitfalls, and can help your team spin up the right combination of tools and practices for your situation.