Previously, we have discussed the concept of having “reproducible builds” which ensure that if our code works on our machines when we write it, it should also work as expected on any other machine.
This also helps us fix problems when our builds turn out to not be as reproducible as we thought, because we can at least isolate the parts of our environments that differ.
In other words, the more reproducible our builds are, the less likely we are to have unexpected failures and the more easily we will be able to figure them out when we do have them.
What tools have we discussed so far that help us obtain this goal?
What’s missing, though?
We could be using different:
Pushing the envelope of reproducibility has led to the growth of what is referred to as “devops” (the hybrid of “development” and “operations”).
I.e., developers are expected to be more integrated in the deployment process which was typically the realm of your “operations” team.
So, now, developers can not simply say “it works on my machine” and throw it over the wall to another team.
Instead, developers must provide support for how the artifacts they develop are actually used.