The DevOps Quickstart is a fully functional set of pipeline workflows and a starter application stack intended to help Agile DevOps teams hit the ground running. Currently OpenShift is supported with plans for AWS (Amazon Web Services). Pipelines are run using GitHub Actions.
Features:
Runs on pull request submission.
Runs on pull request close or merge.
Runs on merge to main branch.
* excludes database changes
Runs on pull request submission or merge to main.
The starter stack includes a frontend, backend and postgres database. The frontend and backend are buld with NestJS. They currently do very little, but provide placeholders for more functional products. See subfolder for source, including Dockerfiles and OpenShift templates.
Features:
Postgres is default. Switch to PostGIS by copying the appropriate Dockerfile to ./database
:
cp ./database/postgis/Dockerfile ./database
Test and develop locally with Docker Compose:
docker-compose up -d
Example APIs, UIs and Metabase/Oracle Templates
Templates for APIs, UIs and Metabase/Oracle can be used to kickstart or extend projects. Please visit our collaborators' NR Architecture Templates repository for more information.
Initial setup is intended to take four hours or less. This depends greatly on intended complexity, features selected/excluded and outside cooperation.
The following are required:
Create a new repository using this repository as a template.
Secrets are consumed by workflows. There are multiple kinds. Please expect to secrets to change across Environments, like PR/DEV, TEST and PROD. Even Dependabot has its own set.
Repository secrets are available to all workflows, except pull requests triggered by Dependabot.
Click Settings > Secrets > Actions > New repository secret
Environments are groups of secrets that can be gatekept. This includes limting access to certain users or requiring manual approval before a requesting workflow can run.
Click Settings > Environments > Environment Name / New environment > Add secret
Environements provide a number of features, including:
Dependabot secrets are used by Dependabot's pull requests. See .github/dependabot.yml for an example.
Click Settings > Secrets > Dependabot > New repository secret
GITHUB_TOKEN
Default token. Replaced every workflow run, available to all workflows.
{{ secrets.GITHUB_TOKEN }}
OC_SERVER
OpenShift server address.
{{ secrets.OC_SERVER }}
https://api.gold.devops.gov.bc.ca:6443
or https://api.silver.devops.gov.bc.ca:6443
OC_NAMESPACE
OpenShift project/namespace. Provided by your OpenShift platform team.
{{ vars.OC_NAMESPACE }}
abc123-dev | test | prod
OC_TOKEN
OpenShift token, different for every project/namespace. This guide assumes your OpenShift platform team has provisioned a pipeline account.
{{ secrets.OC_TOKEN }}
Locate an OpenShift pipeline token:
pipeline-token-...
or a similarly privileged tokentoken
OC_TOKEN
(see above)Sonar Tokens
If SonarCloud is being used each application will have its own token. Single-application repositories typically use ${{ secrets.SONAR_TOKEN }}
, but monoreposities will have multiple, like ${{ secrets.SONAR_TOKEN_BACKEND }}
and ${{ secrets.SONAR_TOKEN_FRONTEND }}
.
BC Government employees can request SonarCloud projects from bcdevops/devops-requests by creating a SonarCloud request/issue. This template expects a monorepo, so please ask for that and provide component names (e.g. backend, frontend).
Squash merging is recommended for simplified history and ease of rollback. Cleaning up merged branches is recommended for your DevOps Specialist's fragile sanity.
Click Settings > General (selected automatically)
Pull Requests:
[uncheck] Allow merge commits
[check] Allow squash merging
Default to pull request title
[uncheck] Allow rebase merging
[check] Always suggest updating pull request branches
[uncheck] Allow auto-merge
[check] Automatically delete head branches
Packages are available from your repository (link on right). All should have visibility set to public for the workflows to run successfully.
E.g. https://github.com/bcgov/onroutebc/packages
This is required to prevent direct pushes and merges to the default branch. These steps must be run after one full pull request pipeline has been run.
Add Rule
or edit an existing ruleProtect matching branches
specify the following:
main
[check] Require a pull request before merging
[check] Require approvals
(default = 1)[check] Dismiss stale pull request approvals when new commits are pushed
[check] Require review from Code Owners
[check] Require status checks to pass before merging
[check] Require branches to be up to date before merging
Status checks that are required
:
[check] Require conversation resolution before merging
[check] Include administrators
(optional)Don't forget to add your team members!
Add people
or Add teams
Please contribute your ideas! [Issues] and [pull requests] are appreciated.
This Action is provided courtesty of the Forestry Suite of Applications, part of the Government of British Columbia.