In the previous post we saw how you can automate SonarQube test upgrades, but now it is time for production.
As mentioned, my artifacts here will be the TFVC repository, and I am going to have just one environment as target: Production.
There are three phases here, two Deployment Group phases and an Agentless phase. This is also where Tags come into play:
The Release Definition itself is going to be fairly straightforward – after all, I am assuming testing already happened so this automation is just aimed at saving time:
The first phase will prepare the environment for the upgrade itself. It is going to copy the zip file to the location we’d like to use, unblock and extract the ZIP file, copy the plugins in use to the new instance and so on.
I am also using these variables to keep the process reusable, and I am taking the ALM Rangers template as a starting point, so everything will happen into C:\sq\:
The Start SonarQube Interactive launches StartSonar.bat from PowerShell to make sure it is not going to make the task hang and run indefinitely.
The Agentless phase is required because once you launch StartSonar.bat you will have to browse to the /setup URL and start the upgrade process.
I am going to get a notification (it could be anyone else here, even a group) and I am going to start the process. You could automate that, but it is surely better to do so manually IMHO.
Once the upgrade is completed (and you stopped the StartSonar batch job, again I could automate this too but I am happy to have it included in the manual interaction for now) you can resume the pipeline with the second Deployment Group phase, which is going to remove the old service, install the new one and start it using the OOB batch scripts in your SonarQube instance.
This saves time (remember you can schedule this Release Definition too 
It might be unorthodox, but it works quite well IMHO.