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.
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:
mainbranch, the application is containerized and pushed to the dev Org's private repository. The GVC and
Review Workloadis created/updated by applying the YAML contents of the files
./cpln/cpln-workload.yaml. The name of the
Review Workloadwill be prefixed by the name of the branch that created the pull request.
devWorkload 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.
prodenvironment is accomplished by manually executing the
Deploy-To-Stage-or-Prodworkflow 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-workload.yaml. The main difference between the two GVC files is that the
prodversion contains the
Pull Secretthat is needed the pull the image from the dev Org. The
prodWorkloads 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.