Deploying Faster: DIY (Deploy It Yourself)

This post explains how Buzzvil made deployments faster.

• Deploying Elegantly: One-Click Deployment
• Deploying Safely: Canary Releases and Rollbacks
• Deploying Faster: DIY (Deploy It Yourself)

The previous posts covered the details of Buzzvil’s deployment pipeline. Here, I’ll explain what matters when enabling engineers to build that pipeline themselves: DIY—Do It Yourself Deploy It Yourself. Most people deploying a service don’t want to understand every detail of the pipeline. They simply want to get their service into customers’ hands quickly. To make that possible, anyone needs to be able to create the pipeline easily.

Making use of templates

In the previous post, “Deploying Safely,” I mentioned that we use Helm to generate Kubernetes manifests. Helm is a mature tool adopted by many companies. But not every engineer knows it. An engineer unfamiliar with Helm has to learn a new tool just to create a deployment pipeline. That learning curve slows down deployments—and, in turn, the organization.

To solve this, Buzzvil maintains a single Helm chart. Our services generally have similar infrastructure requirements, so one chart can cover them. We add conditional logic for edge cases, or would create a separate chart if the main one became too complex. So far, we haven’t needed a separate chart. Engineers therefore don’t have to create a new Helm chart for each pipeline: they simply follow the guide and write a values.yaml file.

The shared chart also comes with optimized defaults. Engineers can deploy resources with those settings by switching the enabled fields in values.yaml on or off.

We took the same approach with Spinnaker, our deployment tool. Spinnaker offers pipeline templates that make pipelines easy to create and customizable through template variables. We prepared templates for different deployment scenarios—rolling updates and canary releases—so engineers could build pipelines from them. Creating a pipeline now takes only a few clicks.

Example pipeline template variables

Removing dependencies between teams

Building a deployment pipeline usually requires some support from an infrastructure team. A team requests help, and the infrastructure team pauses its own work to handle that request. This creates a dependency between teams. As the organization grows, those dependencies increasingly slow it down.

To reduce these dependencies, we first separated the teams’ workspaces. In particular, we placed deployment configuration files in each service’s repository, so engineers could do their work in a single repository. For example, the Helm chart’s values.yaml lives in the release/ directory of each service repository.

Even then, engineers couldn’t do everything on their own. Tasks requiring elevated permissions or broader context still needed help. For example, at Buzzvil, the DevOps team had to create Kubernetes namespaces. We addressed this with a Slack workflow. Before starting work on a deployment pipeline, engineers use the workflow to notify DevOps. DevOps then handles the prerequisites asynchronously while the engineer continues with the next steps.

Slack workflow

We avoided direct requests—such as mentioning the team in Slack—for two reasons. First, the workflow abstracts away the details of the prerequisite work. With a direct request, engineers would have to know exactly what to ask for, introducing an unnecessary learning curve. Second, it prepares us for automation. Slack provides hooks that will let us automate that preparation later.

Wrapping up

A deployment pipeline reflects an organization’s—or a team’s—philosophy and circumstances. Buzzvil’s is no exception. We think carefully about scalability, reuse, and removing dependencies between teams to help the organization move faster, and that thinking is reflected in our implementation. This series has been a chance to share what we’ve learned along the way. I hope it helps other teams facing similar challenges. In future posts, I hope to cover a wider range of topics, including monitoring and security. Thanks for reading.

If you have feedback on this post, please email me. 🙂

Apply to join Buzzvil’s engineering team

Have a coffee chat with a Buzzvil tech recruiter