Notes on taking Production Metadata and releasing as an unlocked Package via GitLab (Part 4)

At a high level the steps are:

• Create a sfdx project
• Pull down metadata from production
• Create scratch org from new metadata
• Create GitLab integration
• Push unocked package to production via UAT sandbox

Part 1 covered the stages up to the GitLab integration, Part 2 got GitLab working and the deployment to a scratch org. Part 3set a deployment to a sandbox (e.g a UAT sandbox) and this final part 4 deploys to production.

There is only one difference when deploying to production and that is the unlocked package needs promoting to be able to be installed in a production environment.

The script provided by Salesforce/GitLab allows for a production deployment that is different to the dev hbub. This is good flexibility but this post assumes the same dev hub as production – therefore there is no need to set PRODUCTION_AUTH_URL see https://gitlab.com/sfdx/sfdx-cicd-template see section on Environment Variables

If you have been following the other sections you will have a PRODUCTION_DISABLED Environment Variable, where if this present (it’s value does not matter) then this will not deploy to production.

So remove this by finding in settings, CI/CD and then settings and the Variables section. Click the remove button at the right of the line PRODUCTION_DISABLED and the ‘Save Variables’. Now make a change :

Now make a change to your source code and push up to GitLab.

Both the staging and production are manual steps and need to be done in order. So you will need to press ‘play’ on the deploy-sandbox and then ‘play’ on the deploy-production. You can click to see the script being run.

The versions that have been setup for the package can be displayed by the command:

sfdx force:package:version:list --packages NameOfPackage

These query the DevHub which manages packages and versions.

Package Name    Namespace  Version Name  Version   Subscriber Package Version Id  Alias  Installation Key  Released  Branch
──────────────  ─────────  ────────────  ────────  ─────────────────────────────  ─────  ────────────────  ────────  ──────
HighwayConcern             Version 1.0   1.0.0.1   04tXXXXX                    false             false
.
.
.
.
HighwayConcern             Version 1.0   1.0.0.11  04tXXXXX                    false             false
HighwayConcern             Version 1.0   1.1.0.1   04tXXXXX                    false             true

There is an important area to be aware of when installing to production and that is that packages need to be promoted before they can be installed in a production org. When the final production script is run the code provided will do the promote (using the package:version:promote command https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_package.htm).

In the table above the final column shows if the package has been released (ie. promoted to be installed).

Package Name    Namespace  Version Name  Version   Subscriber Package Version Id  Alias  Installation Key  Released  Branch
──────────────  ─────────  ────────────  ────────  ─────────────────────────────  ─────  ────────────────  ────────  ──────
HighwayConcern             Version 1.0   1.0.0.1   04tXXXXX                    false             false
.
.
.
HighwayConcern             Version 1.0   1.1.0.1   04tXXXXX                    false             true
HighwayConcern             Version 1.0   1.1.0.2   04tXXXXX                    false             false

As at the date of this post, if a second release to production is made then the script will fail. The pipeline actually shows a success but when looking at the code that has run in the pipeline there is an error:

In fact this error is actually a result of a problem in the promotion release.

The problem is that there is already a promoted package with the major.minor.patch. The first run of the code created a version 1.1.0.1 and released this to production but a second run created a package verison 1.1.0.2 (so the 1.1.0 is common to both) and then tried to promote this.

One work around is to manually change the version of the package in the sfdx-project.json file

The script does not automatically change the version number (or show all the versions in the file – this woudl be updated if the package commands were run manually). If the VersionNumber is changed to “1.1.1.NEXT” then the version promoted will be a different patch version.

After running the pipeline by commiting to GitLab and runnig the manual deploy steps then check the versions by running:

sfdx force:package:version:list --packages NameOfPackage

This will then then show the released versions.

Package Name    Namespace  Version Name  Version   Subscriber Package Version Id  Alias  Installation Key  Released  Branch
──────────────  ─────────  ────────────  ────────  ─────────────────────────────  ─────  ────────────────  ────────  ──────
HighwayConcern             Version 1.0   1.0.0.1   04tXXXXX                    false             false
.
.
.
HighwayConcern             Version 1.0   1.1.0.1   04tXXXXX                    false             true
HighwayConcern             Version 1.0   1.1.0.2   04tXXXXX                    false             false
HighwayConcern             Version 1.0   1.1.1.1   04tXXXXX                    false             true

This manual change of the version in the sfdx-project.json file seems to be required at the moment.