Reading Time: 4 minutes

From  Visual Sourcesafe® to Team Foundation Server®

Here in iSolutions we have been using Team Foundation Server® since version 2010.

We migrated from Visual SourceSafe® several years ago, and this meant moving from a system that only keeps versions of our source code to a full-fledged Application Lifecycle Management system, where version control is “only” an aspect of that lifecycle. So, we started dealing with work items, bug tracking, gated check-ins, automatic builds and so on; this radically changed the way we manage our code.

We installed (and patched :-D) all Team Foundation Server® versions starting from 2010 to version 2018, keeping our ALM system always up to date with the latest features available.

During the years, our ALM infrastructure changed from a single Visual SourceSafe® Server to something like this:

As you can easily guess, TFS has become the “beating heart” of our business, the place where we can safely store and track our precious day-by-day work.

A “beating heart” that, year after year, has become bigger and bigger:

1. Virtual Machine:
   • Overall storage size: 1.2 Tb.
   • vRAM: 48 Gb.
   • vCPU: 8.
2. Database sizes:
   • Configuration database: 5 Gb.
   • Database for Team Project Collection 1: 130 Gb.
   • Database for Team Project Collection 2: 50 Gb.
   • Data Warehouse database: 80 Gb.

From the ITPro standpoint, the Application Tier needs to be always available, constantly backed up and easy to recover in case of disasters (build servers are less critical because they are easy to set up and rebuild from scratch).

Also the system downtime has to be reduced to the bare minimum: we always planned carefully the maintenance windows in order to not stop the developer’s work, and that often meant working during off-office hours and weekends.

Moving to the cloud

Microsoft has been providing a completely managed ALM solution for some years; in the beginning it was called VSOnline (Visual Studio Online), then it was rebranded to VSTS (Visual Studio Team Services) and now Azure DevOps.

The first versions were very limited in features (for example, no analytics and reporting functionalities, no Process Template customizations), but thanks to the strong commitment Microsoft put on the Azure platform , the product first reached the feature parity with his “on-prem brother”, and then surpassed it, becoming the Microsoft’s main solution for ALM/DevOps.

When Microsoft published a supported path for the Team Foundation Server migration to the cloud, we immediately decided to do this big step.

Let’s go

The migration path is made up of several steps:

Microsoft provides a Database Import tool that automatically verifies if your on-prem setup is compliant with Azure DevOps, and suggests all the needed configuration changes in order to have a painless data migration.

The migration guide is very detailed, and I invite you to take a look at it.
The database import process can take up several hours, even days, depending on how much data you have to transfer to the cloud.

Here are some numbers related to our migration:

• Team Project Collection 1 (Database size on-prem: 130 Gb)
  • Database preparation for the import: about 2 hours and 20 minutes.
  • Database upload to Azure Storage Account: about 1 hour and 20 minutes @ 48 Mbps.
  • Actual import duration: about 14 hours.

• Team Project Collection 2 (Database size on-prem: 50 Gb)
  • Database preparation for the import: about 1 hour and 20 minutes.
  • Database upload to Azure Storage Account: about 1 hour @ 48 Mbps.
  • Actual import duration: about 5 hours and 20 minutes.

Every imported team project collection was mapped to a dedicated Azure DevOps account, but both accounts can refer to the same Azure AD Tenant, allowing us to manage user credentials in a centralized way.

Here’s how our ALM infrastructure is set up now:

Since the majority of our code still resides in a TFVC repository, we decided to configure a Team Foundation Server Proxy in order to improve the “Get Latest” experience for all developers; if we allowed developers to get the code directly form Azure DevOps, we would fill up all our available connection bandwidth.

Also build machines can take advantage of the TFS Proxy, speeding up the “Get Latest Code” phase for every requested build.

Conclusions

We got several advantages in having a completely managed ALM system on the cloud:

• Global availability: our code is always available, in a scalable and reliable way.
• Product updates: the system is always up to date with no downtime, giving us access to the product’s latest features.
• No maintenance costs: all maintenance activities are performed by the Azure DevOps team, in the best possible way.
• Services as extensions: you can add features to your Azure DevOps environment simply adding extensions from the Marketplace. For example, if you want the “Code Search” feature in an on-prem setup, you have to manually install and manage a dedicated ElasticSearch server; enabling this feature on Azure DevOps, is a matter of few clicks.

Happy DevOps on the cloud!

Alberto