I'm a little confused over the latest released versions of Azure DevOps Server 2020 on 17th May.
What is the difference between 2020.0.2 and 2020.1.2 and why are two versions of 2020 being maintained?
Currently running 2020.0.1 and looking to move to latest version.
The main difference should between Server Version RC and RTW. The data migration tool doesn't support imports from Azure DevOps Server release candidates (RC). If you're planning on importing your collection database to Azure DevOps Services using this service, it's important that you don't upgrade your production database to an RC release. If you do upgrade, then you will need to wait and upgrade to the release to web (RTW) version when it's available or restore a backup copy of your database from a previous Azure DevOps Server version to import.
From the Release on May 17, 2022, along with several fixes, the Data Migration tool will be available for both Sever 2020.0.2 and 2020.1.2
Before preparing for upgrade, check this official doc: Upgrade your deployment - Azure DevOps Server & TFS | Microsoft Docs
Related
I am trying to find path to migrate TFS 2018 (OS Win 2016, SQL Server 2017) to a new machine with OS Win 2019 and SQL Server 2019.
On new machine I am planning to install Azure Devops 2020, but I am not sure about migrations steps.
Will I first do migration of TFS databases from TFS 2018 (migration db and objects)?
After that I will install Azure Devops 2020 with point to migrated/restored DB from TFS2018.
I am confused, about documentation, because I found that I need to do whole process of upgrade on old TFS2018 machine (OS->2019, DB->2019, TFS ->Azure Devops), and after that migrate to new machine.
But I hope that I can do migrate/restore DB on new SQL Server 2019, and after that during Azure Devops 2020, choose restored DB and etc...
Please any info would be appreciated
Thank you for your time,
Keli
Using the TFS Admin Console backup your existing TFS databases.
Copy the backup files to the new SQL server and restore them
Install Azure DevOps Server on the new target server but don't configure it
On the new Azure DevOps Server use Scheduled Backups - Restore Databases
I believe this will work if the source server was 2017 or later.
Thanks Rob, for response.
I succeeded, but my path was a little different because I had TFS server with SQL Enterprise Edition, and I needed to do migration of databases to 2019 Standard Edition:
Install new virtual machine (VMNew) with: Windows 2019, SQL Server 2019 (Standard Edition).
On this machine I install Azure Devops 2020, but I didn't configure it.
On my TFS server (Windows 2016, SQL 2017 Enterprise Edition) I did
backup all databases with TFS administration console
On new VMNew server, with Azure Devops Console, I did restore databases, but only
ConfigurationDB and CollectionDB.
Restore of ReportingServicesDB and WarehouseDB wasn't possible, because
my old TFS server was SQL Enterprise Edition.
After successfully restored ConfigurationDB and CollectionDB on VMNew, I
configured Azure Devops feature through Console. And site is started successfully.
ReportingServices and Warehouse I configured after step 4. also, through
Azure Devops Console.
Hope that this info will help someone.
Kind regards,
Keli
I am working on the TFS migration to Azure DevOps service and I am using DataMigrationTool_AzureDevOps2020.0.1RTW_18.170.14715315 tool for migration on Azure DevOps 2020(18.170.30910.2) version. I have completed validate and prepare step. I am getting the below error on the Import step.
VS403265: The collection’s Azure DevOps Server milestone is not supported by the data migration tool: Azure DevOps Server 2020.0.1 (Dev18.M170.8). Please upgrade your Azure DevOps Server to one of the supported versions. The data migration guide has the latest supported versions: https://aka.ms/AzureDevOpsImport.
As per the documentation below are the latest versions
DataMigrationTool_AzureDevOps2020.0.1RTW_18.170.14715315.zip
DataMigrationTool_AzureDevOps2020.1RTW_18.181.15696196.zip
DataMigrationTool_AzureDevOps2020RTW_18.170.14735089.zip
Thanks
Sachin
This got resolved after using the Azure Dev Ops 2020.1 server and the same version migration tool.
We have recently upgraded to Azure DevOps 2020 on our testing environment, previously we had TFS 2017 and then upgraded Azure DevOps 2019 and now to Azure DevOps 2020.
I am facing issue regarding the agents I had configured in the earlier version. They don't see to update when I click on the update agent link.
I have one agent i.e. POC_2017Agent installed and created with TFS 2017 agent and the last two agents were created and installed with Azure DevOps 2019.
After we upgraded to 2020 all 3 of them are shown as Offline, even when their services on the servers are running\restarted.
How can I upgrade the agents manually, if they are not getting upgraded automatically after clicking on the update Agent link?
I don't want to remove them and reconfigure again.
Beginning with Azure DevOps Server 2019, you can configure your server to look for the agent package files on a local disk. This configuration will override the default version that came with the server at the time of its release.
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops-2019&tabs=browser#can-i-update-my-v2-agents-that-are-part-of-an-azure-devops-server-pool
We recently upgraded to Azure Devops Server 2019 but i don't see Environments under the Pipeline menu.
Is the Environment feature present in Azure Devops Server 2019?
I am afraid that the Environment feature is currently not supported in Azure Devops Server 2019. To use the Environment feature, you need to upgrade to Server 2020. For details,please refer to this release note.
In addition, you could add your request for supporting this feature on server 2019 on our UserVoice site , which is our main forum for product suggestions. The product team would provide the updates if they view it. Thank you for helping us build a better Azure DevOps.
Azure DevOps Service has a version number, which we can see by browsing to https://dev.azure.com/my_organization/_home/about (see below).
My question is how is this version determined?
I guess that (in this example) 164 is the sprint number, and .1 is a build in the sprint.
However it's not clear what the "Dev18" stands for? How is it determined and when does it change?
I understand this question doesn't make much sense for SaaS, but in our case (regulated environment) it does.
As I know the Dev18 doesn't make much sense. Only the M164 matters in most cases, because sometimes we may need that to determine if you're in one region with the latest update.
And I just got some help from engineers who are more experienced in this topic and we can make the confirmation about the relationship:
Dev18<=>TFS 2020
Dev17<=>TFS 2019
Dev16<=>TFS 2018
Dev15<=>TFS 2017
Dev14<=>TFS 2015
So DavaShaw's guess is correct. It's the major version of TFS, so it won't be changed frequently. I think it will change only when a new TFS version is released. Hope it helps.
I'd guess the Dev18 is the major version of Azure DevOps Server that it is from.
Although, I can't be certain, some deduction leads me to believe it is...
VS and TFS Versions used to be in Sync:
TFS and VS 2015 - were 14.X
TFS and VS 2017 - were 15.X
But the cadence broke:
VS 2019 is now 16.X
Azure DevOps Server 2018 - would be also 16.X
Azure DevOps Server 2019 - would be 17.X
Azure DevOps is always ahead of what is in the Azure DevOps Server installations, so it seems reasonable to assume that the next release of Azure DevOps Server will be 18.X - probably called Server 2020.
All that said...
For Azure DevOps you should only be concerned with the Sprint Milestone that you are on
.