Development and Release Workflow

Environments

Live

• Production environment
• Deployed from release/live branch with tags

Pre-release

• Regression test environment
• Deployed from prerelease branch

Stage

• Testing environment
• Configuration same as live environment
• Connect to Stage Global Login service
• Deployed from trunk branch

Sandbox

• Playground for developers
• Deployed from develop branch
• Connect to Stage Global Login service
• Global login for CORE disable (so that we don’t need to do MFA)

Branches

release/live branch

• Used to track the latest released code

prerelease branch

• Used for regression test
• Only merge new code to this branch right before a regression test

golive branch

• Temporary branch, used for each hotfix/normal release
• A few golive branches may exist at the same time. e.g. golive/2.2.1.4 golive/2.2.1.5 golive/2.2.2
• Deleted after release
• Naming convention golive/{version}
  • golive/1.3.5

trunk

• Used for normal testing
• Pull Request require checks(SonarClould, code review)

develop

• Playground for developer
• Do not require pull request checks. Developer can push code to develop branch whenever needed, including debug codes

feature/bugfix/hotfix branch

• Temporary branch, used for development
• Auto deleted after pull request get merged
• Naming convention {prefix}/{JIRA story code}/{JIRA story title}
  • feature/CORE-1234/Example-feature-core-story

Development workflow

• Feature development
  • Branch out from golive/* branch
  • Once development finished, merge to trunk branch for testing
  • Once testing passed, merge to golive/* branch
• Bugfix development
  • Branch out from release/live branch (in case we want to hotfix release it)
  • Once development finished, merge to trunk branch for testing
  • Once testing passed, merge to golive/* branch
• Hotfix development
  • Create golive/* branch for this hotfix (branch out from release/live)
  • Create hotfix branch (branch out from the golive/* branch for this hotfix)
  • Once development finished, merge to trunk branch for testing
  • Once testing passed, merge to the golive/* branch for this hotfix

Release workflow

Once all tickets in one release have passed tests and marked as done. It's the time to start the release workflow

1. Define Regression and PVT scope - Risk Assess areas
2. Merge golive/* branch to prerelease branch so that it will deploy to the pre-release environment
3. QA start regression test on pre-release environment
   1. Hotfix on golive/* branch if defects found
4. Merge prerelease to release/live and create a new tag on release/live branch once regression test finished
5. Compare the new tag with the live tag to make sure the code changes in the new tag are correct to be released
6. Announce the scheduled release time in Slack release channel
7. Trigger the release
8. QA do PVT on live
9. Announce the release in Slack to broader team

Release versioning

• We will use the same version across all repos for feature version change e.g. 2.2.1 to 2.2.2
• For each feature and hotfix release (e.g. 2.2.1.4 to 2.2.1.5), we will always release core, graphql, app these 3 repos, even if there are no code changes in one of the repos
• When we do a feature release (e.g. 2.2.1 to 2.2.2), releaes all repos (including chat-api, login-api, login-app, statistics, template-lib-api, messaging-service, webhooks, etc.) even if there are no code changes in any of the repos

Example 1:

• We are doing a feature release 2.2.1 to 2.2.2
• We will create tag version 2.2.2 to all repos
• We will release all repos
• Every repo will be at 2.2.2

Example 2:

• We are doing a hotfix release 2.2.1.4 to 2.2.1.5
• We will create tag version 2.2.1.5 only to core, graphql, app, or if there are code changes from any of the other repo, also create tage verion 2.2.1.5 to it
• We will only release core, graphql, app these 3 repos if there are no code changes from other repos
• core, graphql, app will be at 2.2.1.5
• Other repos stays at the feature version 2.2.1