从 TFS 2017 升级到 Azure DevOps - 构建/发布管道

Question

我的公司正在考虑将我们的本地 TFS 2017 更新 3 升级到最新的 Azure DevOps 服务器（尤其是本地版本）。

在讨论这种可能性时，一位主要利益相关者声称，如果您升级，您的所有构建和发布管道都必须从头开始重建。我们在 TFS 2017 中有大量的构建和发布定义。

我已在 Microsoft 文档中寻找关于升级的确切内容的答案，但不幸的是，我无法获得可以证明或反驳上述主张的粒度级别。从表面上看，如果这是真的，这似乎是一个可怕的升级故事。但我也明白，设计和架构的变化和升级并非总是可行的。

有人可以告诉我构建和发布管道能否在升级后或多或少毫发无损地存活下来？在我们做出决定时，了解这一点将是一个有价值的数据点。

提前致谢！

Answer 1

我期望的 vNext 构建定义和发布管道将是相当大的提升和转变。根据您定义的任务，它们可能不再受支持或可能有新版本。用户界面会通知您有新版本可用。

很多新的焦点是为 YAML 构建定义构建功能。如果你想利用这些，你必须做更多的工作来将这些 vNext 任务转换为 YAML。但是转换并不是一个真正的硬性要求。

您提到您没有使用 XAML 构建定义，但如果您碰巧使用它们，我会认为这就是很多返工的地方。在过去这样做过，我可以这么说如果你不得不这样做，那会很痛苦。

Answer 2

您的所有构建和发布管道都必须从头开始重建。

我已经测试过了，升级后不会丢失任何数据。我们应该使用计划备份来确保我们始终有备份，以防出现问题。

我们可以先使用新硬件进行试运行，然后将所有内容擦干净，然后再次使用它进行生产升级。

对于我们的试运行，我们的升级步骤将是：

1. 将最近的数据库备份复制到我们的新 SQL 实例。
2. 在我们的新应用层上安装 TFS 2015。
3. 使用计划备份来恢复数据库备份。
4. 通过升级向导运行，确保使用在我们的生产环境中没有任何权限的服务帐户。有关详细信息，请参阅预生产文档中的在试运行中保护生产。
5. 可选择配置需要更改我们现有项目的新功能。

生产升级步骤将非常相似。步骤如下：

1. 使用TFSServiceControl's quiesce command 使生产服务器脱机。此处的目标是确保我们用于迁移到新硬件的备份是完整的，并且我们不会丢失任何用户数据。
2. 对每个数据库进行新备份。
3. 将备份复制到我们的新 SQL 实例。
4. 在我们的新应用层上安装 TFS 2015。
5. 使用计划备份向导恢复数据库备份。
6. 使用我们所需的生产服务帐户运行升级向导。
7. 可选择配置需要更改我们现有项目的新功能。

您可以参考这个doc了解更多详情。