# CI release

Our release process was relying until recently on a manual action from the dev host:
- bump version
- use `release-it` package to push release on `gitlab`

As the project start we chose to use the gitlab release functionality then we tried to integrate it into the CI: (https://git.clxnetworks.net/myelefant/businessconnectors/sfmc-connector/-/merge_requests/234)

Bertrand:
- What bothers me:
- I don't see any interest:
- at storing previous releases [voir releases faites](https://git.clxnetworks.net/myelefant/businessconnectors/sfmc-connector/-/releases) as it takes space for no specific reason or use
- I am not convinced by the usage of `semver` in `package.json`
- Let the CI mutate the repo and therefore all the release process bothers me:

       generate release:
      stage: Release
      image: registry.gitlab.com/gitlab-org/release-cli:latest
      rules:
        - if: $CI_COMMIT_TAG                  # Run this job when a tag is created manually
      before_script:
        - eval `ssh-agent -s`
        - echo "${SSH_RELEASE_PRIVATE_KEY}" | tr -d '\r' | ssh-add - > /dev/null # add ssh key
        - mkdir -p ~/.ssh
        - chmod 700 ~/.ssh
        - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
        - git checkout $CI_BUILD_REF_NAME
        - git remote set-url origin "[e-mail]:${CI_PROJECT_PATH}.git"
        - git config --global user.name "ci-pipeline"
        - git config --global user.email "[e-mail]"    
        - npm i -g npm@${NPM_VERSION}
        - npm config set -- '//nexus.int.clxnetworks.net/repository/sinch_npm/:_authToken' "${NPM_REGISTRY_AUTH_TOKEN}"
        - npm install release-it

- What I would like:
- To not use gitlab release system:
- no need to store archives
- no need to maintain release notes for a non public project
- release = publish on amazon ECR
- Not depending on a bump version of the `package.json` (manually or automated see mutation point)
- push a simple tag `sfmc-connector-XXXX` by using existing gitlab variables
- use an environment variable to release

Noah:
- We need an effort-less way to share a "current working state" with another person. Ideally, a system like [Vercel](https://vercel.com/)'s could be set up: each branch (or MR, or commit even) receives its own deployment instance with its own public url.
- `git` tags should be enough to handle our versionning - the release command that bumps the version in the `package.json` file should also great a new tag - which should happen on merges into main
- We are serving the frontend bundle just-in-time, upon request from SFMC.

Cédric:
- What do we bring?

## Besoin
- Single Click Deployment
- No mutation from CI
- Readable version to ease client feedback
- Change log for each releases
- All commits
- Reworked for external usage
- StatusPage (??)
- Multi staging environment - Branch/staging

- What about semver:
- We keep track of recent / old

## Investigation
- Tagging does not help:
- Each tag (even light tags) triggers a new pipeline
- Hard to maintain the CI if we want to disable jobs on Tag commit
- Automate release with an environment variable:
- Hard to maintain as:
- it is not possible to have a simple mecansim to maintain the CI project variable up to date with the one set by the user at job level (need to call the gitlab API with specific token, definitely not a best practice)
- the release is launched on version X.X.X, each new deployment will have version Y.Y.Y (which is the value of the CI environment variable and not the one set by the user)

My 2 cents:
The release note should be maintained into the repository (a simple markdown page that will be exposed on the backend as we do for the documentation will be enough)