As a best practice, each deployment environment (developent, production, etc.) should map to a Control Plane Org.
The main benefit of having each environment under a separate Org is that definitions of different GVCs and Workloads can be applied to different Orgs without having any objects include an environment name.
For example, in the development Org, you could apply nearly the same YAML manifest files (used by cpln apply) as the production Org with different content for your secrets.
During the promotion process, the image that was built for development can be referred to by other Workloads in the same Org and across Orgs. This is a great time saver for lengthy build processes.
By leveraging the functionality of GitHub Actions, promoting code changes from one environment to another is as easy as committing/pushing your code and opening/merging pull requests.
This example project contains three GitHub Actions that perform the following:
This project contains three GitHub Actions (in the ./.github/workflows
directory) that perform the following:
main
branch, the application is containerized and pushed
to the dev Org's private repository. The GVC and Review Workload
is created/updated by applying the YAML contents of the
files ./cpln/cpln-gvc.yaml
and ./cpln/cpln-workload.yaml
. The name of the Review Workload
will be prefixed by the
name of the branch that created the pull request.main
branch, a dev
Workload is
updated (or created if it doesn't exists) in the dev Org by applying the same files as step 1, except that the Workload
name is prefixed with dev
. This allows the application to be reviewed and tested before being pushed to the production Org.stage
and prod
environment is accomplished by manually executing the Deploy-To-Stage-or-Prod
workflow and selecting the target environment. The target GVC and Workload in the production Org is updated (or created if
it doesn't exists) by applying the YAML contents of the files ./cpln/cpln-gvc-prod.yaml
and ./cpln/cpln-workload.yaml
. The main
difference between the two GVC files is that the prod
version contains the Pull Secret
that is needed the pull the image
from the dev Org. The stage
and prod
Workloads refers to the image that was pushed to the development Org.The above example demonstrates the concept of a Review Workload. This Workload allows for review and testing of the application
before being promoted to upstream Workloads. The deployment of the Review Workload occurs when a pull request from a feature branch to the
main
branch is opened. The application will only be promoted to the dev
Workload if the pull request is closed and merged.
To control which users have the ability to perform sensitive actions, such as merging a pull request, you can utilize the built-in capabilities of GitHub by creating a custom repository role.
Review these instructions on how to create a role.