Read the official introduction to the GitLab Flow workflow: https://about.gitlab.com/2014/09/29/gitlab-flow/
- Application deployed onto a Kubernetes cluster as a Helm release
- Two branches:
master
(released to a staging environment) andproduction
(released to a production environment) - Automated semantic versioning and tagging
- Ability to include unit and integration tests
- Ability to manually bump application version: patch, minor, major
Example parameters can be found in params/gitlab-flow-semver.example.yml
You can also use Kubernetes Secrets as the credential manager for the pipeline: params/kubernetes.example
Read more about how Concourse sources values from Kubernetes Secrets: https://github.com/kubernetes/charts/tree/master/stable/concourse#kubernetes-secrets
Add the gitlab-flow-init
script to your $PATH
and run the script in every new application repository to initialize the branching model.
- The
master
branch version is stored in theversion
file on therc-version
branch of the application repo, and always has thex.y.z-rc.n
form - The
production
branch version is stored on thefinal-version
branch and has thex.y.z
form
The easiest way to create all of your pipelines is to have a pipeline that will set and update all other pipelines:
fly --target ci \
set-pipeline \
--config pipelines/concourse-pipelines.yml \
--pipeline apps-pipelines
The pipeline will read the Kubernetes Secret that we would create beforehand (example) and create all the pipelines listed in the pipeline manifest file for us.
fly --target ci \
set-pipeline \
--config pipelines/gitlab-flow-semver.yml \
--pipeline forms-app
fly --target ci \
destroy-pipeline \
--pipeline forms-app