首先，我们将工件从Artifactory服务器转移到具有高可用性的新Artifactory。我们需要更新TeamCity中的构建配置。我们为什么要这么做?首先，旧的Artifactory服务器版本很旧，多年来由多个团队共享，多年来由多个团队共享一个单点故障。
同时，在新的Artifactory服务器中，它在Kubernetes集群中被配置为高可用性。那么，我们如何让这些事情发生，让这些改变发生?首先，我们需要更新TeamCity服务器和代理设置。在源代码中，我们需要更新对Artifactory服务器的硬代码引用。在用户站点上，更新了Mavern, Gradie, Scala和Python的所有本地设置。
该图表示新旧Artifactory服务器的高级描述。正如您在左侧所看到的，它是一个单节点Artifactory，右侧表示具有三个节点HA的新Artifactory服务器。这里有一些关于这个故事的背景知识，以及迁移存储库的动机。正如我之前提到的，旧的Artifactory运行的是一个旧版本，多年来它一直是不同组织之间的共享服务器，在过去它没有得到很好的支持。因此，由于技术和发布需求的各种差异，对该服务器进行维护或升级变得更具挑战性。事实上，这是一个大的单点失败。
与此同时，在新的Artifactory服务器上，它已经启动并运行。这个新服务器运行在具有高可用性特性和自动备份的Kubernetes集群中。那么我们需要做些什么来完成迁移呢?下面是如何在一个较高的水平。
首先，我们需要确定所需的所有更改。这些更改包括TeamCity服务器、构建模板和自定义构建配置。这些配置模板，其中许多都包含对Artifactory的引用。在TeamCity、代理中，所有引用Artifactory的本地设置也需要更改。TeamCity服务器和代理。
在源代码中，我们还需要查找对Artifactory的所有引用，即更新中的那些引用。在用户端，他们的[听不清]，台式机或笔记本电脑，他们必须改变他们的设置指向新的Artifactory。因此，在确定所需的所有更改之后，我们需要在一个孤立的构建中测试更改。
这意味着，我们将在不影响正在进行的构建和发布的情况下，针对新的Artifactory测试这个构建。我们相信我们可以继续前进，然后我们可以执行迁移的其余部分，这意味着我们迁移或构建配置到新的Artifactory。然后让我们深入了解一下需要做哪些更改。
TeamCity服务器，Artifactory集成，我们需要为新Artifactory更新这些配置，其中包括一个新的服务帐户，新的连接从TeamCity到Artifactory服务器，我们需要为构建配置设置新的用户设置。这些新用户设置主要用于构建TeamCity与Artifactory互动。
在构建模板中，我们有许多Maven构建或Gradle。它们都派生自构建模板，因此，构建模板所引用的所有新用户设置必须针对新的Artifactory服务器进行更新。因此，在更新TeamCity设置之后，我们需要查看源代码。
例如，在一些源代码存储库中，存在对服务器URL的包引用。所有这些变化都需要更新。在TeamCity，代理实例中，这里所有的本地设置都需要更新，包括Maven设置Gradle, sbts, Scala和Python。在用户端，必须应用服务器密钥更改。
首先，所有用户都需要登录到新的Artifactory服务器并生成新的API密钥。这些API键将在其本地设置中使用。当然，你可以使用密码。但是使用API key有一个优势。例如，用户可以使用API键执行REST API调用。没有需要担心密码过期。即使密码更改，API密钥仍然有效，直到它被撤销。当然，一旦这个API密钥被撤销，您就必须生成一个新的API密钥并相应地更新本地设置。那么为什么这是一个很大的优势呢?在许多组织中，密码需要轮换使用。对于我们来说，这些构件真正地与LDAP集成，并且我们有LDAP密码轮换更新需求。所以一旦密码改变了，您的本地设置将不再工作。所以在本地设置中使用API key是非常重要的。因此，一旦针对新服务器、新Artifactory服务器、Maven、Gradle、SPT或PI表单的所有本地设置、笔记本电脑或桌面生成API密钥，都需要进行相应的更新。
之前我们讨论了一些所需的更改。我们需要准备几件事。首先，我们要确保这个过渡过程是平稳的。为了帮助实现这一点，首先我们设置了每小时从旧服务器到新服务器的自动工件传输。TeamCity构建继续发布到Artifactory的旧服务器。同时，来自旧服务器的构件将自动推送到新服务器。因此，一旦构建配置切换到一个新的Artifactory，所有的新构建都将在旧构建停止的地方继续进行。我的意思是，来自OBS的一般构件将可用于新构建。
所以在这种情况下，不应该有任何干扰事实上，良好的体验不应该有任何干扰。正如您可能意识到的，或者在您进行持续构建时经历过的，工件通常有时可能被新的构建所需要，比如明天或下周。因此，保持所有在迁移之前生成的构件对于迁移之后的构建可用是非常重要的。
这里有一个工件转移的示例。我们简单地使用cron作业和JFrog cli命令。这是一个搜索规范的输入，如果你使用过JFrog cli，你可能会很熟悉。因此，在这里我们使用AQL Artifactory查询语言，仅标识我们感兴趣的用于迁移工件的存储库。在这个例子中，我们包含了一个路径匹配来查找所有的com/SalesForce工件。所以我们会查找过去60分钟内下载或更新的所有工件。这意味着基本上我们对所有在过去一小时内被更新、重写或任何东西的工件感兴趣。然后按小时计算。
在这里，在这里的底部，您可以看到使用JFrog cli后的命令行，我们从旧的Artifactory服务器下载，然后将相同的工件上传到新服务器。一旦我们开始下沉工件，我们就可以使用新的设置进行构建验证测试。当然，我们不希望中断任何正在进行的生产构建。因此，我们创建了一个新的TeamCity代理映像。这个新的TeamCity代理映像基于现有映像。
然后我们更改本地设置以指向新的服务器，新的Artifactory服务器，然后从新的代理映像启动一个新的代理实例。通过使用新的代理实例，我们能够执行测试构建。我们如何测试同龄人?首先，我们克隆现有的工作构建配置和更新，Maven设置点到新的Artifactory，然后我们需要一个针对新的代理实例的账单。然后验证构建结果。
在这一步中，正如您在这里看到的，我们对一个新的代理实例进行了构建测试。而且对正在进行的任何事情，针对旧服务器的开发测试或构建，都没有任何中断。一旦我们验证了构建，基于构建本身的新构建设置，我们评估了正确性，构建性能，最好没有任何差异，但如果没有，至少旧的和新的构建设置之间不应该有构建性能差异。
在我们使用新的TeamCity和Artifactory设置验证构建结果之后，我们需要为所有对等点执行迁移。所以这需要一些时间来维护。对我们来说，这是相当简单的。首先，我们需要非常清楚地沟通什么是迁移步骤，什么是维护计划。
一旦信息发出，我们就会与所有涉众达成协议，我们就能够进行维护和迁移。下面是我们完成迁移所采取的几个高级步骤。首先，我们需要运行TeamCity服务器备份和数据库快照。我们暂停TeamCity队列。在这一点上，不会发生新的构建。一旦构建队列暂停，我们就开始思考，再次从旧的Artifactory服务器到新的Artifactory服务器查看工件。
正如我前面提到的，肯定有一个cron作业不断地将工件从旧的Artifactory服务器移到新的Artifactory服务器。接下来的步骤包括更新TeamCity构建配置，并将一个TeamCity代理启动配置。为什么发射配置很重要呢?这与以下步骤有关，包括，我们需要关闭旧的代理实例，然后启动一个新实例。
此时，新实例将从新的代理启动配置中启动。因此，它们将包含针对新Artifactory服务器的所有更新设置。同时，我们需要在GitHub中搜索所有Artifactory的硬代码引用，在GitHub中我们管理所有源代码。因此，所有这些自己的工件引用必须针对新服务器进行更新。在替换对新服务器的引用之后，我们准备继续所有构建活动。
在这一点上，我们重新启用TeamCity构建队列。从所有构建恢复的那一点开始，我们准备好与所有涉众就迁移结果进行沟通。那么我们如何完成迁移呢?一个关键方面是沟通。在执行这个过程时，我多次提到，我们会交流迁移步骤。我们交流迁移步骤。需要做什么，在服务器客户端应用哪些更改以及用户本地设置。一旦迁移了所有的构建配置，并且恢复了构建队列，我们就会通知所有涉众迁移成功。我们提供服务器端和客户端更改的摘要。我们重申所需的用户本地更改。那么，当我们拥有全球开发团队时，为什么这方面如此重要?
反复沟通是非常重要的关于为了继续他们的本地构建，他们需要应用什么更改。否则，可能会出现开发人员生产力问题。为了帮助支持我们的用户，我们设置了办公时间来回答任何支持问题。
我们设置了办公时间来回答任何支持问题。例如，一些用户可能在登录新服务器时遇到困难，或者在设置API密钥凭据时遇到困难，或者在本地设置时遇到困难。
我们在最终构建配置迁移后的两周内专门安排了一些时间段，以确保我们继续提供支持。我们可以根据需要提供更多一对一的支持。总之，这个故事讲的是什么?它是关于迁移工件的。我们为什么要这样做?
旧的服务器基础设施很复杂，没有得到很好的支持。因此，升级成本或维护是不确定的。这对迁移非常重要，我们需要对迁移路径的有效性有高度的信心。那么如何做呢，我们如何完成这个迁移工作呢?
有几个关键方面。一是我们建立了自动转移的存储库，我们确定了所有需要的更改。一旦我们确定了所需的更改，我们就需要验证隔离配置中的所有更改。同样，这一步是关键的，因为在我们尝试验证所需的所有更改时，我们显然不想中断任何正在进行的构建测试活动。一旦验证完成，我们将更改应用到所有PO配置。然后我们与用户沟通关于本地设置的更改，以及继续提供必要的支持。
今天的演讲到此结束。
非常感谢。
期待您的提问，并享受接下来的swampp活动。
谢谢你！
