The trend of treating infrastructure as code is growing in popularity and with good reason. Programmable infrastructure lets you take advantage of version control, continuous integration, and automated testing — practices that are proven to work for software development and that are essential for DevOps success.
But treating infrastructure as code brings a challenge: after you provision servers, containers, cloud instances, and other parts of your infrastructure based on the specifications that you’ve defined in code, how do you start using them in an automated way?
To meet this challenge, XebiaLabs has introduced the Environment as Code feature in XL Deploy. Environment as Code allows you to define your infrastructure and environments in code, making it easier for Development and Operations to collaborate on configuration management.
The Environment as Code feature builds on Release as Code, which was introduced earlier this year — expanding XebiaLabs’ support for dual-mode DevOps that accommodates different users’ needs. With dual-mode DevOps, you can involve technical and non-technical teams from across the business, from release managers and project managers, to security, compliance and risk teams, to IT management. Environment as Code gives technical team members more flexibility to use code to manage their software delivery pipelines, while less technical team members benefit from XL Deploy’s simple but powerful visual user interface and automatic capture of compliance data.
For example, one of XL Deploy’s most powerful features is dictionaries, which allow you to use placeholders for environment-specific information throughout your applications and configurations. Traditionally, Operations would be responsible for providing the right placeholder values for each environment; but with Environment as Code, it’s easy for developers to share ownership of this data by creating and managing dictionaries in source control alongside their application code.
So, what does defining an Environment as Code look like? Let’s take a look at two environments, TEST and PROD, both of which use Docker. You configure their properties in a Groovy file, which also defines the scope of the changes that XL Deploy should make.
But Environment as Code isn’t only useful for containers and cloud-based infrastructure. It provides the same benefits for middleware configurations. This example shows the definition of a JBoss Domain, an environment, and two dictionaries. It also illustrates that you don’t have to define everything you need in a single Groovy file; you can refer to configuration items that are defined in other files or that are defined in the XL Deploy repository itself.
With Environment as Code, you can synchronize infrastructure data with XL Deploy automatically based on the triggers that make sense for your DevOps pipeline. For example, you can update XL Deploy every time you commit a change in your Puppet code, or every time you create a new AWS EC2 instance or Azure virtual machine — and immediately deploy applications to the newly updated infrastructure. The XL Deploy REST API and command-line interface both allow you to build automatic synchronization when and where you need it.
Many core DevOps tools, such as Jenkins, Puppet, and Chef, are designed for developers, and they offer code as the primary way to manage releases and deployment infrastructure. But a purely technical design doesn’t meet the needs of large enterprises scaling DevOps across hundreds of teams and thousands of users. Enterprises need a strong DevOps orchestration and automation platform to provide the control, visibility, decision support, reporting, compliance, and security that are often lacking in these developer-oriented DevOps point tools. With XebiaLabs, teams can expand DevOps beyond developers and simple development pipelines, moving to full complex release pipelines that span the enterprise.
Learn more about XebiaLabs’ code-centric release features here.