“As-code” approaches to software development have transformed the way teams design, build and implement new solutions. The methodology sees all aspects of the system stored as versioned files in the source repository. Everything from project specifications to network routing rules is treated much like real code.
Going “as code” for everything related to your project helps you maintain consistency, track changes over time, and automate your processes. Effective implementation should enable you to deliver reliable software more efficiently.
In this article, we’ll explore some of the specific ways that treating some code as code improves the software development experience. We’ll also cover some things to watch out for as you transition to an all-as-code approach.
1. It really covers everything
Going through the gateway to “all as code” means you commit to putting all components of your system under source control. For example, you can produce the following assets during your project, each of which benefits from being stored as code:
- Project specification – Saving your initial specification document as code ensures that everyone can access it. You can make changes while keeping all previous versions.
- Documentation – Project documentation as code ensures that a version is stored in tandem with the source it refers to.
- Infrastructure – You can use technologies like Ansible and Terraform to programmatically define your system infrastructure, ensuring that resources like VMs and cloud computing instances are repeatable.
- Scaffolding – Your templates for setting up new projects can be stored as code, so you can clone the repository to start another system.
The overall goal is to bring everything relevant to your project together as centrally stored and versioned files. This model results in a single source of truth for your project, giving everyone a common place to search for information, make changes, and share it with others. It’s more efficient than searching through separate tools like file sharing, email, and stand-alone documentation pages.
2. It’s about automation
Keeping everything as code should have a tangible impact on your processes. This manifests itself through the automation capabilities created by “as-code” methodologies.
When your application’s dependencies, environment, test drivers, and deployment steps are stored as code, they can be used by tools that automate the relevant phases of the lifecycle. This reduces the burden on human operators to remember error-prone manual sequences when a change is ready to continue in the process.
Automation is typically built on “as-code” workflows using continuous integration pipelines. Merging the repository change into your master branch will run the pipeline for you, applying the changes made by the new state.
CI pipelines are usually discussed in the context of code changes: the canonical example is a pipeline that is deployed to production every time you change code. However, pipelines are really just automated scripts that run when a trigger (usually a merge event) occurs. You could have a pipeline that produces a design document as an artifact every time your specification changes.
Storing everything as code maximizes your ability to apply automation throughout the process. You can begin to simplify business-level stages as well as traditional technical procedures.
3. Post the current state
“As with” workflows are best when you use declarative expressions. This means that your files are written to describe the current desired state, rather than the specific steps used to achieve it.
Declarative state management is supported by tools such as Kubernetes and Terraform. They consume files in your repository and distinguish them from your existing environment. Changes are applied automatically to bring the live instance into parity with the current state of your repository.
Focusing on the end goal removes much of the complexity around managing workflows. You are freed from the need to define precise migration steps for each change you make, eliminating repetitive tasks that quickly burden your teams.
A declarative state is not sustainable without an “as code” mentality. You need to write files that declare your ideal state, and then version them so that you can review and revert changes in the future. Moving to All Like You enables you to use these new workflow management systems.
4. Increases consistency
Keeping everything in one place, with one methodology, has obvious advantages for consistency. Inconsistent processes often hinder software projects; teams quickly lose productivity when they frequently switch context between tools and workflows.
Good consistency is also beneficial for security and redundancy. You have one surface for auditing, assurance, and backup, the surface of your source control provider. Staff turnover is less disruptive when you have a complete record of everything created in your organization.
“As with” workflows help standardize processes and tools. This helps you respond to external changes such as major dependency updates. You can often script these migrations by replacing references in all the files in your various source repositories. This would not be possible if the information was scattered inconsistently across systems.
5. It represents a change in mindset
Everything like code requires a change in mindset. It works best when everyone in your organization recognizes and understands the potential benefits. You will experience diminished returns if usage is uneven.
Unequal adoption between teams can allow things to slip through the cracks, creating gaps where information is not properly tracked. It is important to document your process and inform everyone how to use it.
People working in non-technical teams should be offered individual assistance. They probably won’t be familiar with the concept of source control and using basic tools like Git. Paying attention to the requirements of these users will help them get to know each other, making them more likely to stick with the workflow and feel confident using it.
Going all-in on everything like a code doesn’t happen overnight. You need to plan how you will implement the approach before you establish specific tools and processes. Your implementation should be reviewed periodically so that you can spot new opportunities and re-incorporate information that falls out of your system.
“As code” development models are more than opaque words. Keeping everything as code unlocks automation capabilities and increases efficiency throughout the software lifecycle. It allows you to move from sequential stages performed manually to highly parallelized workflows where people focus on the bespoke aspects of each project.
It’s an interesting thought about the software industry that while the product has matured considerably over the past few decades, much of the basic workflow has remained the same. While the widespread adoption of CI pipelines and containerization has brought changes to individual technical steps, the broader process often still relies on manual actions. The project is routinely introduced to new information gathering tools as it progresses from specification to design, development and delivery.
Everything as Code offers a holistic model where a common thread runs through the entire process. Centrally stored versioned files keep everyone on the same page and facilitate powerful integration with automated tools. Adopting a declarative expression eliminates manual procedures so you can focus on the end state of your application, freeing up more time to work on new features.