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
masterbranch version is stored in theversionfile on therc-versionbranch of the application repo, and always has thex.y.z-rc.nform - The
productionbranch version is stored on thefinal-versionbranch and has thex.y.zform
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-pipelinesThe 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-appfly --target ci \
destroy-pipeline \
--pipeline forms-app