| description |
|---|
Published on 23 April 2021 by Caitlyn Mills |
Today we are going to discuss how we streamline the deployment (or installation if you prefer) of a package into an org. Specifically, we will focus on how we ‘build’ a package to get it ready for deployment. I will also refer to a package as an 'artifact'. A package is an artifact that is generated by your CI pipeline, but all artifacts are not necessarily salesforce packages as there can be many different types of artifacts, such as output logs or test coverage results which you want to analyse it later.
To build a package means to bundle up all your code in a neat little virtual box (with a shiny red bow, if you please), ready to be used and 'unpacked' into environments as needed. When you build a package, you can then use and deploy this artifact as many times and into as many environments as needed. This is why one should utilize a package-based development model with all its quirks, repeatability, traceability and above all your org is maintained, no hanging metadata components that you forgot to delete and need to spend one heck of time trying to figure out why was this there in the first place (I am looking at you, delta or diff deployments)
sfpowerscripts provides two specific commands that can help use here. These commands are quickbuild and build.
Let’s first discuss quickbuild! This command creates your package version and bundles it into an artifact. It does so without validating any dependencies or test coverage.
.png)
This command is recommended when wanting to deploy to a ‘developer’ or ST sandbox to validate code before attempting a full build. It has no required flags but must be triggered from within the project directory (if you are using unlocked packages, dev hub becomes mandatory)
Now let’s move on to the build command!
This command, like quickbuild, also creates your package version and bundles it into an artifact. This time however, the command analyses your sfdx-project.json file to resolve the order of dependencies correctly and validates apex tests and code coverage (of course the command asks salesforce to do it)
The order of dependencies is resolved in both, the order of the packages listed and by reading the dependencies properties of each package. You can also enable the --diffcheck flag which will not build packages which have not been changed, if like us you fancy using a mono repository with all packages that form your org.
The result of the build command is a fully validated package which can be deployed to production, after being promoted using the orchestrator’s promote command.
So why do we think orchestrator has the advantage when it comes to building packages?
The answer is pretty simple, we have enabled packages to be built in parallel even when there are dependencies! The command looks into the dependency tree and examines the best way to build in parallel. What does this mean? It means we are saving time by building multiple packages at once. This, combined with the fact that this one-line command reads and understands your project dependencies makes it a pretty remarkable and time saving command.
More information on the Orchestrator Build commands can be found here with source code here.