Git Branching Workflow (Old)

Also see CloudStation\wiki\old\Source Code Management (old).docx for a in-depth discussion on how Git works and how it can relate to the overall SDLC.

New ticket branches are created from development branch. Once the developer satisfies all the ticket’s requirements, the developer merges the ticket to QA branch. If QA reports issues on that ticket, the developer needs to determine if the issue is actually caused by their ticket, and if so, make the fixes and merge the fixes to QA. This process may repeat multiple times due to QA or changing requirements.

Release. Once the ticket passes QA, the developer may be instructed to merge the ticket to development branch. Other developers may be instructed to do the same around the same time to prepare for a release to production. After everyone has merged their QA-passed tickets, a developer will be instructed to create a release branch from development branch, and it is this release branch that the software will be compiled on and deployed from.

The release branch has the following format release-yyyy-MM-dd. Novus may be deployed to UAT first or be deployed straight to production. If deployed to UAT first, the customer and/or QA must verify if UAT is OK, and then the Novus is deployed to production. If deployed to production straight away, deploy to UAT afterwards. After deploying to production, the release branch is merged to master branch. It is also merged back to development and QA branches just in case there were any changes in the release branch itself.

Hotfix. If there’s an urgent production issue that needs to be fixed, a hotfix branch is created from master branch e.g. hotfix-yyyy-MM-dd. A ticket should be created and be branched off from hotfix branch. Once the ticket solves the production issue, the ticket branch should be merged back into the hotfix branch. The hotfix branch can be deployed to QA and/or UAT to allow QA and/or the customer to verify. Once the hotfix is verified to fix the issue, the developer should deploy the hotfix to production, then merge the hotfix branch to master, development, QA, and UAT.

What happens if release branch is not merged into master? The developer is probably doing this because they may think it’s not important. I guess the “issue” is that since the moment that we do merge our tickets into development is usually close to the same time as the release date, a hotfix can be created on development not master. But the only issue is if a hotfix is required but the release has not been deployed yet, then you can see what was the latest deployed release by running git fetch and then git branch -r, merge that release to master, and then create the hotfix.

10.0.2.5 branch is a special branch that was created on 2022-04-12 to be able to deploy to 10.0.2.5 IIS server. This branch holds code that should work as if you were developing locally and connected to 10.0.2.5 SQL Server database. The reason why this branch exists is because you may have a customer that isn’t in QA database so instead, the QA tester or a manager can test tickets in dev.

Return to Project Setup