Deployment Choice: Code Promotion vs Artifact Promotion

Deployment is an important step in the software development life cycle. Deployments make the code written by the developers available as a usable application/executable to the world. Hence, it is one of the foremost practices that any software engineering team should invest in.

In this post, I would like to discuss a couple of strategies on how teams can manage their deployments and which one is better. This post is not about CI/CD(a lot of content is available on this) but one step further down the topic.

The two strategies which I would like to discuss are

1. Code Promotion
2. Artifact Promotion

Code Promotion

: This strategy is about maintaining a branch per environment and triggering deployments when a checkin is triggered against the branch.

Code Promotion Workflow

1. The workflow in code promotion strategy will be the development team creating features or bug fixes under a feature/bugfix branch
2. Checkin into Dev branch
3. Build is trigged and deployed onto Dev Environment via CI/CD
4. Once the team pushes a good amount of features and bug fixes to the dev environment and if everything is fine on the dev environment, the dev branch is then merged to the stage branch.
5. Build is triggered and deployed onto the stage environment via CI/CD
6. QA team does the verification either via manual tests or automated tests and provides a sign-off for production deployment
7. Stage branch is merged with the prod branch
8. Build is triggered based on code in the prod branch and deployed onto the production environment.

Artifact promotion

: This strategy can also have a different branch per each lower non production environments. In this strategy, the code that is well tested on one of the last lower non-production environment is promoted to production environment rather than again rebuilding the code and generating a new artifact.

The output after building the code which is an executable/binary/build is called Artifact.

Artifact Promotion Workflow

1. The workflow in artifact promotion strategy will be the development team creating features or bug fixes under a feature/bugfix branch
2. Checkin into Dev branch
3. Build is trigged and deployed onto Dev Environment via CI/CD
4. Once the team pushes a good amount of features and bug fixes to Dev and if everything is fine on dev, the dev branch is then merged to the master branch
5. Build is triggered and deployed into Stage environment via CI/CD
6. QA team does the verification either via manual tests or automated tests and provides a sign-off for production deployment.
7. So the artifact that is well tested in the Stage environment is now promoted or deployed to the production environment

Following the 12- factor app principle, the best practice is to have lower environments (eg: stage) & production environments very similar, and the only thing that can vary between both lower environment and production environment should be the config.

Config contains the information about resource handles to the databases, credentials to external services, hostnames. Config should always be maintained outside the code and never as constants inside code.

When deployments are modeled as Config+Artifact and the same artifact is used in all environments including the production environment, then any issues happening in the production environment and not reproducible in the lower environment will be mostly config-related issues that are relatively easy to debug and fix.

This model is attained via Artifact Promotion. Hence, Artifact Promotion strategy ensures that a well-tested Artifact is deployed on Production and any issues that may arise in Production which are not in lower environments can be mostly due to production config which is relatively easy to fix in a short time:

Hence I would like to conclude

A good practice of deployment is to promote a well tested artifact and not the code.

Happy Deployment!!