This section contains the various conventions, standards and workflows used in this project
The project is developed using Git flow
All commit messages must start with the Redmine ticket ID on the following form:
[#32608] Implement feature X ...
This allows easy traceability between a given commit and the Redmine issue from which the commit originates.
- Feature and bugfix branches are based on
- Once a feature/bugfix is complete, a Merge Request should be opened on Gitlab
- Be sure to follow the associated MR template!
- Create a ticket in Redmine for the current release (if one doesn’t exist)
- Create a release branch for the release, according to Git flow, e.g.
- Bump the version in
backend/__init__.pyaccording to Semantic Versioning. Conventionally, these two version numbers always match.
NEWS.rstwith new version number and date.
- Once these changes have been made, and the release branch has been pushed to Gitlab, the usual CI checks will be performed and a Docker image will be created with the tag
magentaaps/os2mo:rc- Note that this tag is overwritten whenever a release branch is built, always pointing to the _newest_ release candidate.
- Deploy the release candidate to a testing server.
- Perform manual testing of the release, and verify that it doesn’t contain any breaking bugs or regressions.
- Create a pull request from the release branch to
master. The review should focus primarily on the few changes made during the release process, e.g. bumping the version and finalizing the release notes. All other changes have already gone through review once. Do not delete the release branch yet!
- Create a tag on the merge commit on
masterwith the version number on the form
X.Y.Z, and push it to Gitlab. This will initiate the release process and cause Gitlab CI create a Docker image tagged with the version number, i.e.
- Finally, create a pull request from the release branch to
development. Delete the release branch.
We use Gitlab CI for continuous integration. Whenever a commit is pushed to Gitlab a job is created in the associated CI pipeline.
The pipeline first ensures that the code quality is consistent, and that everything builds without problems.
Once the first phase is passed, the tests are run on the newly built Docker image.
Once the tests pass, we tag and push the Docker image on the following conditions:
- Builds from
developmentare tagged with
- Builds from release branches (
release/X.Y.Z) are tagged with
- Builds of tagged commits, following a merge to
masterare tagged with
To see a full overview of all the various checks in the pipeline, refer to
.gitlab-ci.yml in the root of the repository.