Files

lebaudantoine b783a8bac6 📝(doc) add an example for the frontend image

I added an example in the documentation to ensure we remember to upgrade the
frontend image during the release process. This will help prevent any issues
related to outdated images when deploying new versions.

(I did this mistake while releasing)

2024-08-05 23:14:06 +02:00

2.8 KiB

Raw Blame History

Releasing a new version

Whenever we are cooking a new release (e.g. 4.18.1) we should follow a standard procedure described below:

Create a new branch named: release/4.18.1.
Bump the release number for backend project, frontend projects, and Helm files:
- for backend, update the version number by hand in pyproject.toml,
- for each frontend projects (src/frontend, src/mail), run npm version 4.18.1 in their directory. This will update both their package.json and package-lock.json for you,
- for Helm, update Docker image tag in files located at src/helm/env.d for both preprod and production environments:
```
image:
  repository: lasuite/meet-backend
  pullPolicy: Always
  tag: "v4.18.1" # Replace with your new version number, without forgetting the "v" prefix

...

frontend:
  image:
    repository: lasuite/meet-frontend
    pullPolicy: Always
    tag: "v4.18.1" # Replace with your new version number, without forgetting the "v" prefix
```
  The new images don't exist yet: they will be created automatically later in the process.
~~Update the project's Changelog following the keepachangelog recommendations~~ we don't keep a changelog yet for now as the project is still in its infancy. Soon™!
Commit your changes with the following format: the 🔖 release emoji, the type of release (patch/minor/patch) and the release version:
```
🔖(minor) bump release to 4.18.0
```
Open a pull request, wait for an approval from your peers and merge it.
Checkout and pull changes from the main branch to ensure you have the latest updates.
Tag and push your commit:
```
git tag v4.18.1 && git push origin --tags
```
Doing this triggers the CI and tells it to build the new Docker image versions that you targeted earlier in the Helm files.
Ensure the new backend and frontend image tags are on Docker Hub.
The release is now done!

Deploying

Tip

The staging platform is deployed automatically with every update of the main branch.

Making a new release doesn't publish it automatically in production.

Deployment is done by ArgoCD. ArgoCD checks for the production tag and automatically deploys the production platform with the targeted commit.

To publish, we mark the commit we want with the production tag. ArgoCD is then notified that the tag has changed. It then deploys the Docker image tags specified in the Helm files of the targeted commit.

To publish the release you just made:

git tag --force production v4.18.1
git push --force origin production

2.8 KiB Raw Blame History

Releasing a new version

Deploying

2.8 KiB

Raw Blame History