| **Review** | Those are dynamic and ephemeral environments to deploy your ongoing developments.<br/> It is a strict equivalent of GitLab's [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/) feature. | All **development branches** (non-integration, non-production) |
| **Integration** | A single environment to continuously deploy your integration branch. | The **integration branch** (`develop` by default) |
| **Staging** | A single environment to continuously deploy your production branch.<br/> It is an iso-prod environment, meant for running the automated acceptance tests prior to deploying to the production env. | The **production branch** (`main` or `master` by default) |
| **Production** | _Well.. the prod!_ | The **production branch** (`main` or `master` by default) |
A few remarks:
* All our Acceptance templates support those environments and cooperate gracefully with whichever deployment technology you're using to test the right
server depending on the branch it's running on.
* Transition from **Staging** to **Production** can be either automatic (if you feel confident enough with your automated acceptance tests) or _one-click_ (this is the default). This is configurable.
* If you're working in an organization where development and deployment are managed by separate teams, you may perfectly not declare any **Production**
environment in the development project, but instead trigger a pipeline in the project owned by the deployment team.
*[More info about deployment environments on Wikipedia](https://en.wikipedia.org/wiki/Deployment_environment).
## Generic pipeline stages
Our GitLab templates keep using a coherent set of generic GitLab CI [stages](https://docs.gitlab.com/ee/ci/yaml/#stages),
@@ -137,6 +117,61 @@ Your `.gitlab-ci.yml` file will have to declare **all stages required by include
least one active job is mapped to it. Therefore - for e.g. - if you're not using any packaging template, the
`package-xxx` stages will never show up in your pipelines.
## Publish & Release
Many templates offer the possibility to package the code and **publish** it to an appropriate registry (ex: PyPI for Python, Maven repository for Java, npm for Node.js, Container registry for container images...).
In addition, _to be continuous_ also support triggering a **release**.
A release is the action - from the current development branch - to freeze a stable version of the code, determine
the next version, publish the versioned code packages possibly with additional release specific artifacts (changelog).
As stated above, a **release** should trigger one or several **publish** actions.
But a **publish** is not necessarily related to a **release**. Depending on the related technology, you may also want to publish _unstable_ package versions (ex: _snapshot_ in Maven terminology).
### Release
Functionally, a **release** involves the following steps:
1.`[mandatory]` determine the next release **version** (either manually or automatically),
2.`[optional]`**bump version**
1. update files with the new version (ex: `pom.xml`, `setup.py`, `.bumpversion.cfg`...)
2. update other files related with the release (ex: `README.md`, `CHANGELOG.md` ...)
3. commit the changes
3.`[mandatory]` create a **Git tag** named after the version,
4.`[optional]` create a [GitLab release](https://docs.gitlab.com/ee/user/project/releases/),
5.`[mandatory]`**package** the code (language-dependent format) & **publish** the versioned package to an appropriate repository.
Some _to be continuous_ templates provide their own release job when supported by the build tool (ex: Maven with the [Maven Release Plugin](https://maven.apache.org/maven-release/maven-release-plugin/), Python with [Bumpversion](https://pypi.org/project/bumpversion/) or with the [Poetry Version](https://python-poetry.org/docs/cli/#version) command), but the release action can also be implemented by a separate tool/template such as [semantic-release](https://semantic-release.gitbook.io/semantic-release/) that can gracefully automates the release process (automatically determines the next version number based on Git commit messages, enforces [semantic versioning](https://semver.org/), generates the release notes, creates the tag and the GitLab release).
### Publish
As explained before, publishing a code package is not necessarily related to a release process (as some technologies - such as Maven - allow publishing _unstable_ package versions) but a release should always end by publishing the versioned packages.
As a result, all publish-capable templates are fully compatible with `semantic-release` or any alternative implementing the release process.
That means that - for instance - you may perfectly choose to use `semantic-release` to perform the release of a multi-modude project containing Maven and Docker code:
the publish of released versions will be implemented by each template in the pipeline triggered by the Git tag created during the release process.
## Deployment environments
All our Deploy & Run templates support 4 kinds of environments (each being optional):
| Environment Type | Description | Associated branch(es) |
| **Review** | Those are dynamic and ephemeral environments to deploy your ongoing developments.<br/> It is a strict equivalent of GitLab's [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/) feature. | All **development branches** (non-integration, non-production) |
| **Integration** | A single environment to continuously deploy your integration branch. | The **integration branch** (`develop` by default) |
| **Staging** | A single environment to continuously deploy your production branch.<br/> It is an iso-prod environment, meant for running the automated acceptance tests prior to deploying to the production env. | The **production branch** (`main` or `master` by default) |
| **Production** | _Well.. the prod!_ | The **production branch** (`main` or `master` by default) |
A few remarks:
* All our Acceptance templates support those environments and cooperate gracefully with whichever deployment technology you're using to test the right
server depending on the branch it's running on.
* Transition from **Staging** to **Production** can be either automatic (if you feel confident enough with your automated acceptance tests) or _one-click_ (this is the default). This is configurable.
* If you're working in an organization where development and deployment are managed by separate teams, you may perfectly not declare any **Production**
environment in the development project, but instead trigger a pipeline in the project owned by the deployment team.
*[More info about deployment environments on Wikipedia](https://en.wikipedia.org/wiki/Deployment_environment).
## Development workflow
So far, we've presented a quite _static_ vision of what a CI/CD pipeline should be, but there will be differences
