Continuous Deployment: How It Fits in Your Delivery

How Should Your Team Approach DevOps?

Before we dive in, a quick word for those who might not be as far along in their DevOps journey. DevOps is a system whereby software teams integrate their developers and the operations staff. They focus on continually improving team processes and the software they deliver, as well as constantly speeding up their delivery and feedback loops. A major focus of DevOps is the concept of continuous improvement, where a team focuses on constantly getting better.

Teams that have adopted DevOps find that it provides significant value for their development teams as well as their customers. DevOps can be a pretty big topic, and the goals of this post are a little more advanced. If you’re still exploring DevOps and whether it’s correct for your team, some of the concepts can feel quite daunting. Plutora has a wealth of excellent resources on building your team’s DevOps fluency. If you’re finding this post and some of it feels a little bit over your head, I highly recommend doing more reading to understand how DevOps can work for your team.

What Are the Goals of Continuous Deployment?

One of the cornerstones of the DevOps movement is continuous deployment. The heart of continuous deployment is right in the name: a team should be deploying new features and fixes all the time. As soon as some code is ready to go out, it should go out. This is one of the ways that DevOps provides real value for customers. Code doesn’t stall out waiting for a milestone release before it gets to customers.

The goal of continuous deployment is to get code into the hands of customers as fast as absolutely possible.

How Does Continuous Deployment Work in Traditional Organizations?

Continuous deployment runs into a lot of friction with traditional business project management. Most businesses have grown accustomed to organizing their projects with several hand-offs between departments and teams. These hand-offs mean that experts are able to work closely on any new bit of work that comes through. That’s good! It also slows down the deployment process, because every project hand-off is extra work that needs to happen.

These hand-offs are the antithesis of continuous deployment. Code isn’t getting to customers as quickly as possible. Instead, a developer finishes coding, then hands that off to a security engineer. That engineer might look at the code the same day, or they might look at it two weeks later. Once they’re done, they hand the code off to a compliance officer. The cycle repeats. This is no good for anyone. Questions about old code frustrate developers. Security engineers and compliance officers experience frustration because they feel like they’re constantly rushed. No one feels like they’re doing their best work.

How Can DevOps Better Fit in a Traditional Delivery Pipeline?

The truth is that you’re always going to have some friction trying to combine DevOps and a traditional delivery pipeline. Eventually, one of those two things has to give. Either the delivery pipeline will evolve to fit the needs of continuous delivery, or the continuous delivery philosophy will change to suit the needs of the existing delivery pipeline.

Here’s a small secret: the true solution for your organization will almost certainly be a little bit of both. The most mature DevOps organizations are flexible at all levels of the organization. They try new things, and find what works, then adapt those strategies across the organization.

How Can You Make Hand-Offs More Effective?

Ideally, you can avoid hand-offs completely. We’ll talk more about how to make that happen in later sections.

If your team is stuck doing hand-offs, there are ways that you can make them more efficient. One of the biggest time sucks with hand-offs to security or compliance teams is having a new feature just sitting around waiting. Sometimes, this is because the work is sitting, waiting for anyone to come work on it. Sometimes, it’s because an expert needs to evaluate the work. That expert likely has a long queue of work waiting for their attention, and it takes them time to work through each thing that needs their attention.

One way that you can circumvent these long waits is to make a developer who worked on a feature available to work with the security or compliance engineer. Instead of handing off new work to see it disappear in a black hole, be proactive about getting attention for your code. When you perform a hand-off with a different team, schedule a time for a developer to sit and work directly with the person who’ll evaluate that feature for fitness.

Benefits of This Approach

This approach conveys multiple advantages. First, you’re forcing your team’s changes to stay at the top of the priority queue. People are much less likely to procrastinate work when they have a specific calendar invite to work on it, and someone sitting beside them to help them with the tricky bits. Sure, you’re going to run into some times when a single person is a blocker, and they’re unavailable for weeks. Security engineers need vacations, too.

That leads to the second advantage: you’ll have a much better sense of how long it’ll take to turn around a feature. If the soonest you can schedule time with an architect to evaluate a new feature is two weeks after coding is finished, you know the feature won’t pass approval before then. That’ll reduce stress levels for developers and leadership, and makes it easier to communicate with other business leaders about the timeline for a project. Likewise, knowing when a feature will undergo evaluation means that you can more effectively plan when the next hand-off will occur.

A third advantage is reducing the overall context switching necessary for developers. Developers working on a feature which is going through a long-running process constantly have to change what they’re thinking about. Some days, that’s new code on another in-progress feature. Some days, it’s remembering details about code they wrote months ago. These context switches, especially when they happen without warning, can be a serious cognitive overhead for a developer.

The final advantage is the building of relationships. By creating opportunities for security or compliance employees to work closely with developers, both teams integrate better. Just like integrating your development team with operations lead to better efficiencies, the same is true for teams like your security team.

How Can You Eliminate Hand-Offs Completely?

Like we mentioned above, the truth of this is that some teams simply can’t eliminate hand-offs completely. They’re working in organizations where existing processes are simply too well-ingrained.

If you’re not in one of those organizations, I’d still recommend re-reading the previous section. Regularly scheduling times for engineers to work closely with people like security or compliance engineers is the core of building those teams into a continuous delivery pipeline. In fact, for most organizations, I would recommend taking the above steps first and building on them.

So, instead of scheduling a hand-off where a new feature is handed off to the security team, schedule the one-on-one communication with a security engineer before coding completes.

What’s more, you don’t need to solve all your delivery pipeline problems at the same time. Some teams will naturally be easier to integrate into your continuous delivery system than others. It can be beneficial to take a look at some of these teams and outline some specific strategies for building a coherent delivery pipeline alongside them.

Coordinating With Security Teams

Effectively coordinating with a security team will likely involve two face-to-face meetings. Developers and security engineers plan security into the feature from the very first step. Building security into a continuous delivery pipeline means working directly with security people before someone even opens a coding editor. This is usually a pretty easy sell for your security teams, too. They don’t like having to be the team that holds up a new feature because it wasn’t securely designed. Those sorts of changes are usually difficult fights and expensive in terms of time and political capital.

From there, it’s easy for developers to integrate with the security team briefly to make sure a feature is still developing securely. Instead of trying to get new code in front of an engineer after the developer has completed it, they can take a few moments of that engineer’s time to verify that what they’re building still conforms to the spec. If your first step was having developers work directly with engineers for feature review like suggested above, developers will already have relationships with security team members. It’ll be easy to start a conversation and spend five minutes talking about what’s changed.

When the time comes to hand a feature off to the security team, it’s likely that you won’t even need to. This style of feature management has become so popular within the DevOps community that it has a specific name: DevSecOps.

Coordinating With Compliance Teams

Oftentimes, the necessary coordination with compliance teams is going to come very early in the process. Many compliance teams worry that adopting DevOps will lead to serious compliance issues, but that doesn’t have to be true. The key for eliminating hand-offs with compliance teams is to understand the ways that compliance seeks to protect your company.

Most compliance operations are focused on who accesses what data, how, and why. Effective DevOps teams are able to build systems into their software that identifies sensitive data and protects it from unauthorized access. It’s likely that when you’re building these controls, your team will need to work very closely with the compliance team. Once those systems are deployed, though, keeping them operating smoothly is much simpler.

Much like with the security team, it’s possible for your developers to leverage established relationships to virtually eliminate the need to check in with compliance. When your developers check in with compliance teams regularly, the compliance officers are not surprised by new features. They understand the consequences of a new feature, and what risks it exposes. Instead of a long wait while the compliance team verifies a new feature, it’s a quick check to make sure there’s nothing they haven’t seen before. Hand-offs aren’t necessary because the work has already been done.

Coordinating With QA/QC Teams

Unless security or compliance teams have the final say, QA teams will always need some say at the end of the process. It’s their job to assure that the code meets the desired quality of the organization.

It is possible, however, to move some of their work forward in the process, though. This can be a very challenging process for many organizations because the necessary work sometimes requires educating QA personnel in new ways of working. In most organizations, QA personnel are analysts. Their job is to analyze the work done by developers, and either approve it or catalog shortcomings.

In a DevOps team, QA personnel work more like engineers. Their job is to find places where QA work can be automated. Most of these QA engineers will spend time writing code to create automated tests which verify the validity of a system. These automated tests take a significant amount of work off both QA analysts and engineers in terms of manually testing a system. This automation removes work the QA team needs to do after code is finished.

The ideal situation for this is for new QA automation to develop in sync with new feature development. New code is automatically accompanied by QA code which verifies the fitness of the feature.

Continuous Deployment Requires Continuous Improvement

Building a mature continuous deployment pipeline means everyone needs to work at getting better all the time. It’ll require adjustments not just from teams who work with the DevOps team, but from the engineers themselves. They need to work more closely with people who aren’t more directly technical, in order to ensure that the code they write does what it needs to.

The key to remember is that this isn’t something you’ll accomplish overnight. Teams that haven’t adopted DevOps, or can’t, won’t be keen on upending their workflows to suit your team. You need to show them the relative value of working with more collaboration before they’re going to make major changes. Usually, this happens incrementally or not at all. So, instead of trying to implement sweeping changes, get your engineers close to the people who hold up continuous deployment. Build those relationships, and help your engineers understand how to build code that’ll pass muster the first time. Build on it bit by bit.

Before you know it, you’ll wonder why you ever did hand-off meetings. Your team will wonder how they ever worked without regular input from other parts of the business. Your security and compliance teams will experience lower stress and feel great that the software you ship is better than ever. And the best part is that your customers will still be overjoyed.