Build Reproducibility is the ability to build software repeatedly, over time. The better reproducibility you can create, the easier it will be to scale software deployments across your enterprise infrastructure. The goal is to create a system that is easy to reason about and audit after the fact.So how can you work towards build reproducibility and improving the build experience?
In this post I’ll cover three seemingly different trends that all share the ability to enable reproducibility and consistency, including:
- Mono Repos
- Hermetically Sealed Build Environments
- Improving the Build Experience
Mono Repos: A Single, Centralized Code Repository
Monolithic repositories (mono repos) make it look like all the code across your entire organization is located in one giant store.
Mono repos is a trend (some may call it a regression) in response to some of the problems and challenges that enterprises are facing with the widespread adoption of multiple, individual repositories (multi repos). Lately, every application or microservice team checks their code into their own unique bit of source control. Multi repos provide many advantages, including:
- isolates project/team, which simplifies setting up continuous deployment processes on a project by project basis;
- makes it really easy to share the code, which is especially important when working on open source projects, or with contractors.
However, these individual repositories have also created multiple walled gardens within your organization, which decrease efficiency. Teams end up spending a lot of time writing their own tooling for deployment and writing their own continuous integration test harnesses because individual teams don’t have an awareness of what’s happening in other parts of the organization.Enter a mono repo… which centralizes all of an enterprise’s code into a single place. .That means every team, every coder, can gain a complete picture without running a thousand git pull commands.Mono repos allow you to implement one standard, one convention and one set of tools that can be used across your organization. So, for example, a DevOps team can make tools for all your other teams, and create the respective standards and conventions to be used across your organization. So enterprises can take a “write once, read often” approach. Everyone in the organization uses the same tools, gains the same benefits and increases team efficiency across your enterprise.
I really encourage everybody to embrace Mono Repos and not be afraid of them. If you have those edge cases where you need to limit access to code, you may need to implement small, discrete repos. Otherwise, you should be storing your code based on the most typical situation, not the exception.
How do these trends impact build engineering as a whole? Register for our October webinar with DevOps.com as we discuss the evolving role of build engineering in managing open source.
Hermetically Sealed Build Environments: The End of Dependency Hell
Hermetically sealed build environments are a natural consequence of taking a mono repo approach since the repo will contain ALL of your dependencies.The term “hermetically sealed” refers to the fact that at software build time nothing is leaking in from outside your build environment. So you achieve the elusive build reproducibility and consistency goals and eliminate external issues and threats being introduced without your knowledge or oversight. Remember the Javascripts leftpad debacle? One module disappearing from the internet did not impact those who hermetically sealed their dependencies into their revision control.
And it’s not just for external threats. You won’t have a developer throw their hands up in the air and say, “Well, it works on my machine”, only to find that they have different software dependencies or code on their machine compared to what you have in the production environment.Hermetically sealed build environments decrease those times a build fails with “package not found” because the developer pulled down a new module off the Internet between the time they checked in their code and when your continuous integration system ran.
Improving the Developer’s Build Experience
Gaining the ability to build the same thing repeatedly and over time means you can facilitate and scale deployments across your enterprise infrastructure, onboard new hires more quickly and be more confident when dealing with updates and security patching. Why invest thousands of person hours writing unit tests if the thing you’re testing can mutate without your consent?
And if you work towards build reproducibility or improving the build experience then you provide the developer, your engineering teams, your build engineering teams or anyone in the software development lifecycle with more time to spend on high value work.
Creating an exceptional Developer Experience (DevX) enables developers to focus on what matters and enterprises to ship code faster. Learn more about optimizing the developer experience in this blog post.
