| description |
|---|
Huh! These folks must really hate branches! |
Artifacts are a key concept in DX@Scale. Artifacts are traceable, versioned, immutable entities that get generated during the build or promote command. DX@Scale's CI/CD orchestrator generates artifacts that contain source code of the package, metadata information, change log and much more. Artifacts help sfpowerscripts to orchestrate deployment without being tied to the notion of branches.
Artifact registry allows you to split your CI and CD pipelines. We believe that this is essential for a smoother deployment model and allows you to better control what is being deployed to environments if you are using a multi-speed deployment strategy.
{% embed url="https://www.youtube.com/watch?v=Vrjl-ISUaC8" %} Why do you need an artifact registry? {% endembed %}
Let's have a look at the below example, here a CI pipeline creates a bunch of artifacts/packages, then the publish command is used to publish these artifacts into an Artifact Registry. This stage often gets repeated multiple times during a day.
.png)
An important thing to note here is especially when a CI pipeline is enabled with 'diffcheck' functionality, it only builds packages for the particular build run. Unless you are immediately deploying these packages to production, there is no way to deploy an entire set of packages other than going through each of the build runs and immediately pushing them into production. You will need to aggregate packages before you proceed to the next stage.
One approach to solve is to use branches, where a branch per environment is used to stage changes, and new builds are generated from this branch to deploy to the environment. We believe this practice is incorrect as they break the traceability chain and errors could be introduced, moreover it complicates your version control strategy. Our premise is rather to use the same set of artifacts that were built at one stage all the way to production.
This is where an artifact registry comes into play. It stores all the artifacts produced by the build stage into a repository, which allows you to consolidate all versions of your artifacts and then allowing you to decide which all packages/artifacts should be aggregated and released into production.
The CD pipeline (or called as 'Release' pipelines in some CI/CD systems) can be triggered manually or automatically, with artifacts and its version number/tag as the input, such as by using a release definition used by the release command.
Rather than lock everyone into a particular registry provider, sfpowerscripts supports artifact registries which support the following:
- NPM compatible private registry (Almost every artifact registry supports NPM )
- **A registry that supports universal packages (**JFrog Artifactory, Azure Artifacts)
{% hint style="danger" %} Please ensure you are not publishing sfpowerscripts artifacts to npm.js, (the default public npm registry). It is against the terms of service for npm.js, as it only allows JavaScript packages. {% endhint %}
Please refer to your artifact registry provider's documentation on how to set it up. If you are planning to use npm compatible private registry, here are some links to get you started
sfpowerscripts provides with functionality to help you fetch or publish artifacts. Some orchestrator commands like prepare also fetches artifacts from the artifact registry.