concourse-gitlab-flow
This repository has two concourse pipeline examples supporting two Gitlab flow model below:
Production branch with GitLab flow
Production branch with Gitlab flow assumes two major branches.
main
branch: This branch is for tracking production 'grade' code, it can be seen as release candidates. Not as github flow, master branch is not for tracking production codes.- features branch: as standard git flow and github flow, this is for developing each feature and will be merged to master.
production
branch: This is the branch for tracking production code. Every commit on the branch will be shipped to the production environment.
Concourse pipeline to support "Production branch with Gitlab flow"
2-envs.yml supports that:
- Semantic versioning by semver-resource
- Continuous Integration(CI) for pull requests.
- Continuous Deployment(CD) of
master
branch- deployment to
staging
environment bumps release candidate version (stored inrc-version
resource)- release candidate version will be of the form
x.y.z-rc.n
- release candidate version will be of the form
- deployment to
- CI/CD of
production
branchmerge-master-to-production
job is the trigger to start deployment to production.- Succeeding jobs performs CI/CD
version-production
job always computes final version fromrc-version
resource and stores it tofinal-version
resource.- If release candidate version was
x.y.z-rc.n
, final version will bex.y.z
start-next-rc
is executed aftertag-production
. This stores next release candidate version torc-version
resource.- If
x.y.z
will be tagged,start-next-rc
bumped patch version. i.e. in this case, next release candidate version will bex.y.(z+1)-dev.1
- Team can manually bump minor/major version when big changes happened on master branch.
- If
- tagging commits and actual shipment jobs are separated. This enables you to ship the latest commit on production branch to production environment without bumping versions. This would be useful for deployment failure or network issues.
Please note that this pipeline does NOT support hotfix-ing on production
branch. This means you need to commits those fixes to master branch and start over release process. See 2-envs.yml for implementation details.
Environment branches with GitLab flow
In Environment branches with GitLab flow, it assumes three environment. They are staging
, pre-production
, production
environments. It also assumes git repository have three major branches whose are corresponding to environments. Please note that master
branch is the only branch whose name is different from environment name.
main
branch: This branch is for tracking codes which are deployed continuously tostaging
environment.- features branch: as standard git flow and github flow, this is for developing each feature and will be merged to master.
pre-production
branch: This branch if for tracking codes which are deployed topre-production
environment. Every commit on the branch will be shipped to the pre-production environment. These shipment can be seen as release candidates.prodution
branch: This is the branch for tracking production code. Every commit on the branch will be shipped to the production environment.
Concourse pipeline to support "Environment branches with Gitlab flow"
3-envs.yml supports that:
- Semantic versioning by semver-resource
- Continuous Integration(CI) for pull requests.
- Continuous Deployment(CD) to
staging
environment of master branch.- deployment to
staging
environment bumps development version (dev-version
resource)- development version will be of the form
x.y.z-dev.n
- development version will be of the form
- deployment to
- CI/CD of
pre-production
branchmerge-master-to-pre-production
job is the trigger to start deployment topre-production
environment.- Succeeding jobs performs CI/CD to
pre-production
environment. version-pre-production
job always computes release candidate version fromdev-version
resource and stores it torc-version
resource.- If development version was
x.y.z-dev.n
, release candidate version will bex.y.z-rc.1
start-next-dev
is executed aftertag-pre-production
. This stores next development version todev-version
resource.- If
x.y.z-rc.1
will be tagged,start-next-dev
bumped patch version. Next dev version will bex.y.(z+1)-dev.1
- This means release candidate version will never be bumped to
rc.2
. Team needs to fix commits on mater branch and start over CI/CD flow frommerge-master-to-pre-production
- Team can manually bump patch/minor/master branch when big changes happened on master branch.
- If
e2e-test-on-pre-production
performs end-to-end test onpre-production
environment. This would work as the final gate to promote pre-production branch to production branch.
- CI/CD of
production
branch- When
e2e-test-on-pre-production
passed, CI/CD process of production branch will be triggered automatically.merge-pre-production-to-production
will be kicked. - Succeeding jobs performs CI/CD to
production
environment. version-production
job always computes final version fromrc-version
resource and stores it tofinal-version
resource.- If release candidate version was
x.y.z-rc.1
, final version will bex.y.z
- When
- tagging and actual shipment jobs are separated. This enables you to ship the latest commit on production branch to production environment without bumping versions. This would be useful for deployment failure or network issues.
Please note that this pipeline does NOT support hotfix-ing on pre-production
and production
branch. This means you need to commits those fixes to master branch and start over release process. See 3-envs.yml for detailed.