We all have at some point of time heard the statement: "This code works perfectly fine on my machine but does not work in test or qa or pre-prod or prod or other environments." And almost every time after spending hours or days of debugging we figure out that the developer machine has slightly different versions of binaries or some tweaks in configurations than other environments. And it does not only happen when promoting code from dev machine to X environment, it can also happen when promoting code from QA to pre-prod environment or pre-prod to production environment.

These situations could be frustrating but can be avoided by following some principles or using some concepts. So questions comes to the minds are: How to make sure that code can be deployed in a repeatable fashion? How to make sure that we can have consistent results when deploying the same code in different environments? What is the best way to package my code? How do I promote my code or application from one environment to another? What is the best or good way to deploy an application?

We will learn in this course and address some of the problems mentioned above. We will learn these concepts in general but you may need to do some tweaks to suit your production environment.

First of all, let's understand the term "Artifact". In the DevOps world, an artifact is a collection of Source code, dependencies, configuration files, binaries, et cetera, which can be built using different processes. Artifacts can be in form of JAR file, TAR file, or Docker Images.

Let's say I have an application and I build the artifacts during deployment by fetching some dependencies from the Internet. In this scenario, there are chances that we won't get the same artifacts in all the environments and this could be for a variety of reasons. For example, one environment is pointing to a different version of a repository and thus gets different versions of dependencies or somehow new code has been added to the repository during the deployment.

One good example could be fetching the JDK, an environment may get OpenJDK, others can get Oracle JDK, et cetera. In such a situation the resulting artifacts may not be the same or may not behave in the same manner. This problem can be solved using the concept or principle called Immutable Artifacts. Let's break this term and understand the terms "Immutable" and "Artifacts".

We have already learned about the Artifacts. Now, What does "Immutable" mean? Immutable means an object which cannot change or cannot be changed over time. Or, an Object which cannot be modified once produced. So, an Immutable Artifact is a principle where we produce artifacts once and then should not be modified ever. This solves a lot of problems which comes due to the fact that different artifacts get deployed in different environments.

Now with the Immutable Artifacts, we build an artifact, test it and get a good confidence that this artifact can be deployed to any environment including production and will produce the same results or behave in the same way. Thus, Immutable Artifacts can be deployed in a repeatable fashion with consistent results.

In the Google Cloud Platform world and for this course, when we talk about Immutable Artifacts, we generally refer to the Docker Images. So we will use Docker Image and Immutable Artifact interchangeably. For containerized applications, we build a Docker Image and store it in some repository which could be public or private depending on the use-cases. And whenever there is a change in code or dependency, we build the new image and store it in the repository.