How does promotion actually work?

The kubernetes resources being deployed are defined as YAML files in the source code of your application in charts/myapp/templates/*.yaml . If you don’t specify anything then Jenkins X creates default resources (a Service + Deployment ) but you are free to add any k8s resources as YAML into that folder ( PVCs, ConfigMaps, Services , etc).

Then the Jenkins X release pipeline automatically tars up the YAML files into an immutable versioned tarball (using the same version number as the docker image, git tag and release notes) and deploys it into a chart repository of your choice (defaults to chartmuseum but you can easily switch that to cloud storage/nexus/whatever) so that the immutable release can be easily used by any promotion.

Promotion in Jenkins X is completely separate to Release & we support promoting any releases if packaged as a helm chart. Promotion via jx promote CLI generates a Pull Request in the git repository for an environment (Staging, Canary, Production or whatever). This is GitOps basically - specifying which versions and configurations of which apps are in each environment using a git repository and configuration as code.

The PR triggers a CI pipeline to verify the changes are valid (e.g. the helm chart exists and can be downloaded, the docker images exist etc). Whenever the PR gets merged (could be automatically or may require additional reviews/+1s/JIRA/ServiceNow tickets or whatever) - then another pipeline is triggered to apply the helm charts from the master branch to the destination k8s cluster and namespace.

Jenkins X automates all of the above but given both these pipelines are defined in the environments git repository in a Jenkinsfile you are free to customise to add your own pre/post steps if you wish. e.g. you could analyse the YAML to pre-provision PVs for any PVCs using some custom disk snapshot tool you may have. Or you can do that in a pre or post-install helm hook job. Though we’d prefer these tools to be created as part of the Jenkins X extension model to avoid custom pipeline hacking which could break in future Jenkins X releases - though its not a huge biggie.