How to make a hotfix/release for RapidScan and/or Studio.Backend
The intention of this guide is to explain how to make a release for RapidScan (also known as the Assessment Wizard) and/or Studio.Backend.
Summary: Hotfixes, Releases, and the MergeRelease Mechanism
If you already understand these terms, you can skip this section. You might want to check the Important Notes section: it is very short and it could help you to avoid critical mistakes.
Hotfixes and Releases
Both repositories Studio.Backend and Studio.AssessmentWizard (better known as RapidScan) use Gitflow. For the purpose of introducing a change into the master branch there are two options:
Release: A new branch is created from develop. The name of the branch should be release/release-X.Y.Z, where X is the major number, Y is the minor number, and Z is the patch number. For instance: a name could be release/release-9.7.0. This branch is merged into master and develop using the MergeRelease mechanism (this is not a standard practice that happens in any repo that uses GitFlow). Release is the preferred method of updating master with the changes that have been applied to develop.
Hotfix: A new branch is created from master. The name of the branch should be hotfix/hotfix-X.Y.Z, where X is the major number, Y is the minor number, and Z is the patch number. For instance: a name could be hotfix/hotfix-9.7.0. This branch is merged into master and develop using the MergeRelease mechanism (this is not a standard practice that happens in any repo that uses GitFlow). Hotfixes are normally used to attack a bug that is very concise/to the point.
When we talk about major, minor, and patches, we are talking about Semantic Versioning
MergeRelease
The MergeRelease mechanism is a Release in which a branch (which should be a release or hotfix branc) is specified and the contents of that branch will be merged into master and develop. After that, the branch will be removed.
The branch that is selected for MergeRelease will be erased. Never use merge release on master or develop.
Also, there might be conflicts when trying to apply a MergeRelease from a hotfix. In some cases, master will be OK but the changes will not be able to be merged into develop. Please make sure that both branches can accept the changes before making a MergeRelease. (you can use a mock Pull Request).
Important Notes
Never use the MergeRelease on master or develop: It will erase the branch you used
There might be conflicts in master or develop after applying the MergeRelease: it is better to confirm it won't happen before making the MergeRelease
If the installer for RapidScan is not generated, this might be a problem related to the Mobilize.RapidScan build. There is a step in which the installer is created and it has caused trouble before.
Remember to test in staging everything before moving onto production.
Making a release for RapidScan
Prepare a release or hotfix branch for the Studio.AssessmentWizard repo (hotfix should branch from master and release should branch from develop). This branch should be able to merge with both master and develop.
In the TFS, go to the Pipelines > Build tab.
Search for the Mobilize.RapidScan.MergeRelease build. (At the moment in which I am writing this, it can be found on the folder Infrastructure/Studio/RapidScan/Mobilize.RapidScan.MergeRelease).
Make sure you are on the Mobilize.RapidScan.MergeRelease.
Click the Queue button.
Select the branch you created at the beginning (the release or hotfix branch). Do not select a develop or master branch, and Queue the build.
When the MergeRelease build is over, make sure the master and develop branches did accept the changes from the MergeRelease.
Search for the Mobilize.RapidScan build. (At the moment in which I am writing this, it can be found on the folder Infrastructure/Studio/RapidScan/Mobilize.RapidScan).
Check if there is a build running for master (it might have been triggered by the MergeRelease mechanism). If there is one, wait for it to finish.
When the Mobilize.RapidScan build is over, go to the Pipelines > Release tab (from TFS).
Search for the Product.RapidScan release (At the moment in which I am writing this, it can be found on the folder Infrastructure/RapidScan/Product.RapidScan).
Check if there is release currently being deployed (it might have been triggered by the Mobiize.RapidScan build). If there isn't one, you can click on the Create Release button.
Make sure the version of the AssessmentWizard matches the version from the Mobilize.RapidScan build.
Click on Create.
Check that the new release is being deployed (if there is another release being deployed, it will block this deployment. You can abandon an older release if it was never released). It is necessary to give three approvals (don't do it yet):
Pre-deployment approval for Staging phase: If you approve this, it means you are OK with deploying (to Staging) the AssessmentWizard/RapidScan version you selected (when creating the Release).
Post-deployment approval for Staging phase: If you approve this, it means you tested in Staging the deployment of the AssessmentWizard/RapidScan version you selected (when creating the Release), and you are satisfied with the results.
Pre-deployment approval for Production phase: If you approve this, it means you are OK with deploying (to Release) the AssessmentWizard/RapidScan version you selected (when creating the Release). This one is the most important.
Give the pre-deployment approval for Staging if you are OK with the implications
Wait for the deployment to Staging.
Test what you need to test in Staging. The installer for the RapidScan version that is deployed in Staging can be found here: http://onlineux2-staging.azurewebsites.net/Assessment/DownloadOfflineAssessmentWizard
Give the post-deployment approval for Staging if you are OK with the implications
Give the pre-deployment approval for Production if you are OK with the implications
The release is ready
Making a release for Studio.Backend
Prepare a release or hotfix branch for the Studio.Backend repo (hotfix should branch from master and release should branch from develop). This branch should be able to merge with both master and develop.
In the TFS, go to the Pipelines > Build tab.
Search for the Mobilize.Studio.Backend.MergeRelease build. (At the moment in which I am writing this, it can be found on the folder Continuous_Delivery/Studio/Mobilize.Studio.Backend.MergeRelease).
Make sure you are on the Mobilize.Studio.Backend.MergeRelease
Click the Queue button.
Select the branch you created at the beginning (the release or hotfix branch). Do not select a develop or master branch, and Queue the build.
When the MergeRelease build is over, make sure the master and develop branches did accept the changes from the MergeRelease.
Search for the Studio.Backend build. (At the moment in which I am writing this, it can be found on the folder Studio/Studio.Backend/Studio.Backend).
Check if there is a build running for master (it might have been triggered by the MergeRelease mechanism). If there is one, wait for it to finish.
When the Studio.Backend build is over, go to the Pipelines > Release tab (from TFS).
Search for the Studio.StudioBackend release (At the moment in which I am writing this, it can be found on the folder Infrastructure/Studio/Studio.StudioBackend).
Check if there is release currently being deployed (it might have been triggered by the Studio.Backend build). If there isn't one, you can click on the Create Release button.
Make sure the version of the StudioBackend matches the version from the Studio.Backend build.
Click on Create.
Check that the new release is being deployed (if there is another release being deployed, it will block this deployment. You can abandon an older release if it was never released). It is necessary to give three approvals (don't do it yet):
Post-deployment approval for Staging phase: If you approve this, it means you tested in Staging the deployment of the Studio.Backend version you selected (when creating the Release), and you are satisfied with the results. The version that was deployed in Staging will be deployed in Production after this.
Post-deployment approval for Production phase: If you approve this, it means you are OK with the deployment to Production.
Wait for the deployment to Staging
Test what you need to test in Staging. The Staging endpoint is http://sandboxwebservice.eastus.cloudapp.azure.com:83 (make sure the port number is correct). For instance, you could access the AssessmentService (used by RapidScan) from the following endpoint: http://sandboxwebservice.eastus.cloudapp.azure.com:83/AssessmentService.svc
Give the post-deployment approval for Staging if you are OK with the implications (the version running in Staging will be deployed to Production).
Wait for the deployment to Production
If you want to confirm that everything is alright in Production you can use this endpoint: http://studiowebservices.eastus.cloudapp.azure.com . For instance, you could access the Assessment Service (used by RapidScan) from the following endpoint: http://studiowebservices.eastus.cloudapp.azure.com/AssessmentService.svc
Give the post-deployment approval for Production if you are OK with the implications
The release is ready
Last updated