If you are building your artifacts per environment, you are doing it wrong

I have heard several times developer telling me how they build their artifacts before deploying to each of their environment. Yes, they build a jar for dev and instead of promoting the same jar to their acceptance testing environment, they rebuild the jar specifically for their UAT environment.

Here is why one of the teams was taking such an approach. There are a set of XML files containing the configuration information. However, their application did not have a way of accepting an environment as an argument during startup and picking the configuration xmls for the corresponding environment(They didn't realise the need for it). Instead, their build script was accepting environment as an argument and copying the corresponding config files from the version control.

Now let's understand why rebuilding your artifacts is a bad idea. The primary goal of continuous delivery is to make software deployments painless, low-risk events. While repeatability is achieved by automating everything, rebuilding the artifacts increases the risk of deploying something not tested in a lower environment into a higher environment. Hence building the artifacts only once is the recommended practice in building a deployment pipeline.

Fortunately, the mainstream frameworks (for example Spring, Micronaut, Grails) of today come with an out of the box support for environment specific configurations - typically known as profiles. While such support was not available in the earlier days, only those teams that understood the risk of environment specific build attempted to come up with the relevant techniques. Today many teams use these features because it is available and advertised by the framework providers, without understanding the problem they solve.

In my experience, most of those custom solutions to achieve environment specific configuration that I have seen are over-engineered and leads to bugs due to the lack of understanding of the complex configurations. That way these out of the box framework provided solutions have helped in preventing 'reinventing the wheel' and improved developer productivity.