In every application delivery process, there is a step that translates raw source code into something that is deployable into an application environment. Sometimes this is a Java JAR, sometimes it is a Docker container, sometimes it may be a Python package, or something else. All of these deployable objects are known as build artifacts, and they act as the bridge between Continuous Integration (CI) and Continuous Deployment (CD).
Usually, the final step of the CI pipeline creates of one or more build artifacts and stores them in an artifact repository, and tags them with a date or version number. This enables the philosophy of build once, deploy many -- once the artifact has been built once and been stored in the artifact repository, it can be deployed to any of the environments (dev, QA, staging, production) through a CD pipeline.
CTC has two approved artifact repositories: Artifactory is the preferred repository, while Azure Artifacts is available in certain cases where Artifactory may not be appropriate.
Artifactory repositories could include libraries, executable binaries, packaged zip files, Docker images, or other things. Storing these items in Artifactory allows artifacts:
To be promoted to higher environments (for example, QA -> pre-production -> production)
To be redeployed on-demand to a specific environment
To be shared between teams
Any artifacts which are destined for a higher environment -- that is, they have been deployed to a lower environment such as dev and passed all applicable tests -- should be stored in Artifactory as one of the final steps of the CI process.
