Release Process

Introduction

Ensuring high quality of Business dashboard releases, a strict deployment process has to be followed. The basic flow can be seen below:

⁠

⁠

The timeline for this process lasts for a week from the creation of the release branch. For example, if the release branch was made on January 1st, we expect to deploy the updated version of the app on January 8th. This also means that the release branch name should be created with such expectation. If, for one reason or another, the release is postponed, a new release branch must be made based off the latest develop branch.

Flow explanation

Make release branch: creating a release/v20XX.XX.XX branch following year, month, date format.

Deploy release branch preview: deploying the branch made in step 1 with environment set to preview

Passes release checklist: acceptance test of the application, where one or more people go through a checklist, confirming every function of the application to be functional (both happy and sad flow)

Merge release into main branch: if all the checks pass, merge release branch into main

Deploy main to production: deploy the application to production from the main branch

Write bug tickets & fix the bugs: create tickets and prioritize them so the release date can be met

Merge changes into develop & release: when the ticket is completed, there must be two pull requests: one for the target release branch; and one for develop (so the develop is also kept up to date)

The checklist used to confirm the functionality of the application can be found here:

Product testing checklist v1.0⁠

⁠

Branches and bug fixes

Branch names

feature/ used for stories that add functionality to the application. Target branch develop.

bugfix/ used for tasks that fix bugs in existing functionality in the app. Target branch develop.

hotfix/ same as bugfix/ but is used for production bugs of high importance. Target branches: develop, main (aka production), and release/. This branch requires multiple pull requests and issue fixes have to be looked over by senior developer/engineer.

Bug fixes

The standard bug fixes target develop branch and of medium importance. If a bug is seen as mission-critical (e.g., user is not able to view, read, or edit data) then the bug has to be sent into production as well. This means that we first use hotfix/ prefix to show that the branch fixes an issue in production, and during pull requests, we are merging the fix into main and develop. The production then has to be re-deployed by the developer responsible for application releases.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.