TFS2018 to AzureDevops 2019 Upgrade -Part 4

Table of Contents:
TFS2018 to AzureDevops 2019 Upgrade Part 1: Approach
TFS2018 to AzureDevops 2019 Upgrade Part 2: Create TFS Sandbox
TFS2018 to AzureDevops 2019 Upgrade Part 3: Upgrade sandbox instance to Azure Devops 2019
TFS2018 to AzureDevops 2019 Upgrade Part 4 Upgrade production instance to Azure Devops 2019 (this article)

Thank you for stopping by. This article is still in progress.
AD-U-Image0Updated as of March 8th 2020
In the last three posts I mentioned about the series of steps that were taken to standup a parallel independent AzureDevops instance for the project teams to try their hands on. The project teams were requested to test out the new UI and familiarize themselves so that once the production instance was updated there was minimal learning curve. In the course of testing the new AzureDevops instances, a few fixes/upgrades were identified in order for the teams to be able to function efficiently. These were then classified into two categories – (i) fixes that can be implemented on current TFS instance that will carry into Azure Devops and (ii) fixes that need to be applied only after the upgrade.
For example changing a build logic could be done prior to upgrade while changing support for certain activities require the new features to be available before they can be applied.
Once all the fixes were in place, it was decided to upgrade to Azure Devops 2019 Update 1 (instead of Azure Devops 2019).
On the day the upgrade was being carried out, all project teams were requested to check-in/shelve their code changes, save their task groups, build definitions, work items, boards views, queries etc. and preferably close visual studio client on their machines.
Closer to the upgrade time, I logged into the database server and queried active connections from the tbl_command table and reminded people to log off and close connection.

Step 1: I then stopped all build agents so that no last minute checkin could trigger a build. This was to ensure that there is as less talking while the tool goes down.
go to this url for that: http://${TFS-URL}/DefaultCollection/ed/_admin/_AgentQueue
Step 2: Triggered TfsServiceControl quiesce
This command was triggered on the application server were TFS was installed. This took approximately 6-7 minutes. I verified that the service was turned off by trying to access the TFS homepage which returned a service not available page.
Step 3: Shutdown application and database server
This step was to prepare for a contingent and is not a mandatory step for Azure Devops upgrade. After the shutdown, a snapshot of both the servers were taken so that, if during the upgrade due to some unforeseen issued we had to bail out, we could just restore the snapshots and revisit the upgrade later. After the snapshots were taken, both the servers were powered back up.
Step 4: Install Azure Devops 2019 update 1
The installation took about 30 mins or so after which I was required to restart the application server.
Step 5: After the server was restarted, when I logged in, I got the below Configuration Center window ready.
Step 6: Click on Start Wizard
Since this was an updated to an existing instance (TFS2018.Update2) I selected the options that I have existing databases. Click Next.
Step 7: Specify Configuration database
This value was picked up from the existing setup.
Step 8: Deployment scenario:
This being a production upgrade, I selected the default option.
Step 9: Provide service account under which Azure Devops will run
Step 10: Verify the application url and SSH Settings
Step 11: Configure search
Step 12: After selected all appropriate configuration values, I got to the review page
Step 13: I reviewed all and it looked good. Clicked Verify which started readiness check.
Step 14: After the readiness check completed a confirmation was requested
Since we had already migrated all our builds, I selected the checkbox (which enabled the Configure button) and proceeded.
It took about 10 mins to configure
Step 15: I clicked on Next and the upgrade was already in progress
The upgrade step took a little less than 18 minutes and when I clicked Next, I got the Success page! Azure Devops upgrade done.
Clicked on Close.
I verified that the product version was correct and then reviewed the other configuration values.
Step 16: I enabled all the build agents (that were disabled prior to the upgrade) and then started my smoke test to ensure that all the features and functionalities are working as expected.

The upgrade process took close to 2 hours which isn’t bad at all considering our 1.7 TB database size. Practicing the upgrade on sandbox instance was a confidence booster. Also having project teams try out the sandbox instance ensured that there was just one issue reported post the upgrade.
The application and database server snapshots were deleted once all project teams were comfortable with the upgrade.
Azure Devops build definitions were working fine with build agents that were configured on TFS 2018

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s