Skip to content

Release process & versioning

Jump to bottom
vitalis0itu edited this page Jun 20, 2023 · 3 revisions

Application version

Palvelukartta project uses semantic versioning numbers (vx.y.z, for example v2.0.8). Application version is displayed on "Info page" https://palvelukartta.hel.fi/fi/info. Displayed information contains the application version (a.k.a tag) and short commit sha (8 characters). For example it might read (Version: v2.0.8 - d92d244d) Application version is the latest tag counted from "the build commit". Commit sha is the sha of "the build commit".

Tag and commit information is read by custom plugin during webpack build. It defines variables GIT_TAG and GIT_COMMIT.

Branches

Production environment follows master branch. Test environment follows develop branch. New commits, features, fixes, etc are pushed / merged to develop branch.

Release process

  1. Create PR with title Release x.y.z.
  2. Configure PR to be a merge from develop to master.
  3. Draft a Github release with title vx.y.z
  4. Wait for build pipelines to pass, review potential flaky browser tests.
  5. Merge PR
  6. Publish the "Github release", this creates new git tag with title vx.y.z *a
  7. Review Azure devops pipeline twice (there are two checks) https://dev.azure.com/City-of-Helsinki/palvelukartta/_build?definitionId=410
  8. Rebase develop branch to master / hard reset develop branch to newly created tag *b
  9. Push develop branch to origin (remote)

*a Here we have a racing condition. As the tag that is displayed on info page is resolved during webpack build, the tag must exist during that. Azure pipeline is triggered on push to master. This means that if publication of the "release tag" is delayed, then there will be an outdated git tag displayed. The out of date tag is not crucial as the commit sha is up to date but it is still confusing. This problem can be solved by a new pipeline run after the release tag is published. This racing condition could probably be avoided by using hooks / github actions.

*b The reset to newly created tag is not strictly necessary. Assume that we skip this step every time we release a new version. Then we might end up in situation where the latest tag in develop branch is v1.6.4 while v2.0.8 is in production. Info page in test environment will display that Version: v1.6.4 - <sha-x> while in production it is Version: v2.0.8 - <sha-y>. The problem here is that v1.6.4 does not represent the current state (feature wise) of the application. Luckily the sha will always be up-to-date.

Clone this wiki locally