首先，我们将工件从Artifactory服务器转移到具有高可用性的新Artifactory。我们需要更新TeamCity中的构建配置。我们为什么要这么做?首先，旧的Artifactory服务器版本是旧的，首先，旧的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密钥有一个好处。例如，用户可以使用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的硬代码引用，我们在这里管理所有源代码。因此，必须针对新服务器更新所有这些工件引用。在替换了对新服务器的引用之后，我们就可以继续所有构建活动了。
此时，我们重新启用TeamCity构建队列。从所有构建恢复的那一点开始，我们就准备好与所有涉众就迁移结果进行沟通了。那么我们如何完成迁移呢?一个关键的方面是沟通。在执行此过程时，我提到过几次，我们交流迁移步骤。我们传达迁移步骤。需要做什么，在服务器客户端和用户本地设置上应用什么更改。一旦所有构建配置迁移完成，并且构建队列恢复，我们就会通知所有涉众迁移成功。我们提供了服务器端和客户端更改的摘要。我们重申需要对用户本地进行更改。那么，当我们拥有一个全球性的开发团队时，为什么这一点如此重要呢?
反复沟通是非常重要的他们需要做什么改变才能继续他们的本地构建。否则，可能会出现开发人员生产力问题。为了帮助支持我们的用户，我们设置了办公时间来回答任何支持问题。
我们设置了办公时间来回答任何支持问题。例如，某些用户可能在登录新服务器时遇到麻烦，例如，某些用户可能在登录新服务器、设置API密钥凭证或其本地设置时遇到麻烦。
在最终构建配置迁移后的两周内，我们会预留一定的时间段，以确保我们继续提供支持。我们还可以根据需要提供更多一对一的支持。总之，这个故事讲的是什么?它是关于迁移工件的。我们为什么要这样做?
旧的服务器基础设施很复杂，没有得到很好的支持。因此，升级成本或维护成本是不确定的。这对迁移非常重要，我们需要对迁移路径的有效性有高度的信心。那么我们如何完成这个迁移工作呢?
有几个关键方面。一是我们建立了仓库的自动转移，我们确定了所有需要的更改。一旦我们确定了所需的更改，我们需要在隔离的配置中验证所有更改。同样，这一步是至关重要的，因为我们显然不希望在尝试验证所需的所有更改时中断任何正在进行的构建测试活动。验证完成后，我们将更改应用于所有PO配置。然后我们就本地设置的更改与用户进行沟通，以及继续提供必要的支持。
今天的演讲到此结束。
非常感谢。
期待您的提问，并享受SwampUP活动的其余部分。
谢谢你！
