“As code” software development approaches have transformed how teams design, build, and deploy new solutions. The methodology sees all aspects of a system stored as versioned files in a source repository. Everything from project specs to network routing rules is treated similarly to the actual code.
Moving to “as code” for everything connected to your project helps you maintain consistency, track changes over time, and automate your processes. An effective implementation should let you ship reliable software more efficiently.
In this article, we’ll explore some of the specific ways in which treating non-code as code improves the software development experience. We’ll also cover some of the things to watch out for as you move to an everything as code approach.
1. It Really Covers Everything
Passing through the gateway to “everything as code” means you’re committing to placing all your system’s components into a source control system. For example, you might produce the following assets during your project, each of which benefit from storage as code:
- Project Specification – Storing your initial specification document as code ensures everyone can access it. You can make changes while retaining all previous versions.
- Documentation – Project documentation as code ensures it’s stored and versioned in tandem with the source it pertains to.
- Infrastructure – You can use technologies such as Ansible and Terraform to programmatically define your system’s infrastructure, ensuring resources like VMs and cloud computing instances are reproducible.
- Scaffolding – Your templates for scaffolding new projects can be stored as code so you can clone the repository to begin another system.
The overall aim is to encapsulate everything relevant to your project as centrally stored and versioned files. This model results in a single source of truth for your project, giving everyone a common place to look for information, make changes, and share them with others. It’s more efficient than searching for data across separate tools like file shares, emails, and standalone documentation sites.
2. It’s All About Automation
Storing everything as code should have a tangible impact on your processes. This is manifest through the opportunities for automation that “as code” methodologies create.
When your application’s dependencies, environment, test runners, and deployment steps are all stored as code, they can be consumed by tools that automate the relevant lifecycle stages. This lowers the burden on human operators to remember error-prone manual sequences when a change is ready to move on in the process.
Automation is normally built atop “as code” workflows using continuous integration pipelines. Merging a repository change into your main branch will run the pipeline for you, applying the changes introduced by the new state.
CI pipelines are commonly discussed in the context of code changes: the canonical example is a pipeline that deploys to production each time you change the 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 each time your specification changes.
Storing everything as code maximizes your ability to apply automation throughout your entire process. You can begin to streamline business-level stages, as well as the traditional technical procedures.
3. Declare the Current State
“As code” workflows are best when you use declarative modes of expression. This means your files are written so they describe the currently desired state, instead of the specific steps used to achieve it.
Declarative state management is supported by tools like Kubernetes and Terraform. They consume the files in your repository and diff them against 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 cuts out much of the complexity around workflow management. You’re freed from having to define the precise migration steps for each change you make, eliminating repetitive tasks that quickly burden your teams.
Declarative state isn’t viable without an “as code” mentality. You need to write files that declare your ideal state, then version them so you can review and rollback changes in the future. Moving to everything as code equips you to utilize these new workflow management systems.
4. It Increases Consistency
Storing everything in one place, with one methodology, has obvious benefits for consistency. Inconsistent processes often hinder software projects; teams quickly lose productivity when they’re frequently switching contexts between tools and workflows.
Good consistency is beneficial for security and redundancy too. You’ve got one surface to audit, secure, and backup, that of your source control provider. Staff turnover is less disruptive when you’ve got a fully versioned record of everything created in your organization.
“As code” workflows aid standardization of processes and tools. This helps you respond to external changes such as major dependency updates. You can often script these migrations by replacing references across all the files in your various source repositories. This wouldn’t be possible if information was inconsistently scattered across systems.
5. It Represents a Mindset Shift
Everything as code requires a mindset shift. It works best when everyone in your organization recognizes and understands the potential benefits. You’ll experience diminished returns if usage is patchy.
Unequal adoption between teams can allow things to slip through the cracks, creating gaps where information’s not being properly tracked. It’s important that you document your process and inform everyone how it should be used.
People working in non-technical teams should be offered individual help. They’ll probably be unfamiliar with the concept of source control and the usage of essential tools like Git. Paying attention to the requirements of these users will help them familiarize themselves, making it more likely they’ll stick with the workflow and feel confident using it.
Going all-in on everything as code doesn’t happen overnight. You need to plan how you’ll implement the approach before you establish specific tools and processes. Your implementation should be reviewed periodically so you can spot new opportunities and reincorporate information that falls out of your system.
Conclusion
“As code” development models are more than opaque buzz words. Storing everything as code unlocks automation opportunities and increases efficiency through the entire software lifecycle. It lets you shift from sequential stages that are executed manually to highly parallelized workflows where humans focus on the bespoke aspects of each project.
It’s a curious reflection on the software industry that while the product has matured considerably over the past couple of decades, much of the underlying workflow has remained the same. Although the widespread adoption of CI pipelines and containerization has brought change to individual technical stages, the broader process is often still reliant on manual actions. A project’s routinely introduced to new tools for capturing information as it progresses from specification to design, development, and delivery.
Everything as code offers a holistic model where a common thread runs through the whole process. Centrally stored versioned files keep everyone on the same page and facilitate powerful integration with automated tools. Adopting a declarative mode of expression eliminate manual procedures so you can focus on your application’s end state, freeing up more time to work on new features.
