From IaC to DEaC (Development Environments as Code)

Compare 4 dominant standards for Development Environments as Code

DevOps practices have taught us that describing an infrastructure declaratively has many advantages, such as versioning, automation friendliness, and reproducibility. Few people can ignore these benefits today, and IaC (Infrastructure as Code) and GitOps practices are widely used among software development teams.

In this article, we will learn about the Development Environments as Code (DEaC) concept, which is related to the IaC. We also discuss its importance and relation to CDEs. Finally, I will introduce four dominant standards for defining the Development Environments as Code (DEaC).

4 dominant standards for Development Environments as Code

· The origin of the Dev environment as a code
∘ My first experience with Vagrant and Cloud-init
∘ The emergence and popularity of containers
· The conjunction of CDEs and Development Environments as Code
∘ VM-based vs. Container-based CDEs
· 4 dominant Dev environment as code standards
∘ Dev Containers
∘ Devfile
∘ Nix
∘ Terraform
· Final Thoughts

The origin of the Dev environment as a code

Any script or configuration that made a machine or VM ready to run a complicated application for test or development was the earliest attempt by developers to define a test and development environment as code, which has several benefits:

• Make the process of configuring the development environment easy
• Reproducible
• Versioning
• Building automation on top of it

Developers, systems, and infrastructure engineers invent several tools, such as Terraform, Ansible, or Puppet, to achieve this. These tools provide a standard way to define, provision, and configure infrastructure with all the benefits that I mentioned earlier.

The next stop was to expand the concept of IaC to all deployment environments, such as test, staging, and more, which brings up the concept of Environments as Code (EaaC).