A Manager’s Guide to DevOps as Code, Part 1: Why Code?

DevOps as Code is an approach that allows teams to define all of the components of their DevOps pipeline in code: environments, infrastructure, deployment packages, release templates, dashboards, and more. With DevOps as Code, the components of the end-to-end software delivery pipeline can be version-controlled, shared across the organization, and audited with ease.

In this series, we’ll take a look at the benefits of defining software delivery components as code, how it works in the XebiaLabs DevOps Platform, and how you can use code to on-board teams to the CI/CD toolchain and migrate applications to the cloud.

Where it all started: Infrastructure as code

Infrastructure as code is a DevOps practice in which teams describe environment and infrastructure information in code and manage it the same way they manage application code: checking it into source control management, applying it as part of their Continuous Integration pipelines, and testing it with automated testing tools. Infrastructure as code has become incredibly popular, for many good reasons.

It’s easy to keep track of changes. It’s in the name—version control systems such as Git and Subversion are designed to track how files change, when they change, and who changes them. Auditability is built in to the commit history.

It’s easy to revert changes. Again, version control systems are designed to make it easy to roll changes back—so if something goes wrong, you can easily restore your infrastructure to a known working version.

It’s easy to collaborate. Whether you call them pull requests or merge requests, most version control systems include a mechanism for teams to request code reviews, which facilitates collaboration on changes.

It’s easy to share. Whether code files are written in YAML, JSON, Groovy, or another language, they’re inherently portable across applications and projects. Teams across the organization can avoid reinventing the wheel and can share best practices for setting up infrastructure.

You can edit files any way you like. Whether you prefer Visual Studio, Eclipse, Xcode, IntelliJ… every team member can edit files using the tools they prefer.

You can do everything in one place. You can maintain everything your application needs in one repository, using one development environment—not just the application code, but the information about what type of environment the application needs to run.

Go code-native with DevOps as Code

XebiaLabs’ DevOps as Code approach goes a step further than infrastructure as code, because it allows teams to define all of the components of their DevOps pipeline in code: infrastructure, environments, deployment packages, release templates, and even dashboards, roles, permissions, and risk profiles.

On-board teams to the CI/CD toolchain

There’s a learning curve to CI/CD practices and tools, and therefore, many organizations struggle to put CI/CD into practice across all of their teams and applications. This has led to the rise of DevOps-as-a-service, where a centralized team of experts set up and run the CI/CD toolchain for application development teams across the organization. DevOps as Code makes it easier for these experts to define everything that teams need to on-board their applications to the toolchain, directly in YAML code.

Standardize security and compliance across teams

DevOps as Code also makes it easier for Development, Operations, Security, and Compliance teams to collaborate on standardized practices that satisfy IT governance requirements. They can work together to define configurations for connecting to code evaluation tools, release pipelines that incorporate manual and automated security and compliance checks, and dashboards that help teams monitor their security and compliance test results at a glance—all in code that’s easy to share across teams and projects.

Share best practices across teams

The CI/CD learning curve isn’t the only thing that modern organizations have to deal with; they also have to face the learning curve of cloud and container technologies. Even the most experienced application developers might not know much about containerizing applications, and even the most experienced system administrators might not know much about running stable, secure software in the cloud.

Many enterprises have one or two teams of “rockstars” that have embraced cloud and container technologies. These are the teams that want to do things like break their applications down into microservices and deploy them on next-gen platforms. DevOps as Code is a way to “scale your rockstars” by spreading their technical knowledge and lessons learned across the organization, without requiring a lot of overhead to educate all other teams.

Use blueprints to adopt new technologies

What about organizations that don’t have rockstars who have figured out everything related to cloud and containers? XebiaLabs’ out-of-the-box blueprints can help teams move to the cloud by giving them examples to work from. A blueprint is similar to a template, but even more lightweight; a developer or system administrator can answer a few questions, apply the generated YAML code, and see how a typical deployment to a platform such as AWS or Google Cloud Platform would work.

Learn more

• A Manager’s Guide to DevOps as Code, Part 2: How it Works
• A Manager’s Guide to DevOps as Code, Part 3: Blueprints
• The IT Manager’s Guide to DevOps