首先，我们将工件从Artifactory服务器转移到一个具有高可用性的新Artifactory。我们需要在TeamCity中更新构建配置。我们为什么要这么做?首先，旧的Artifactory服务器版本很旧，多年来被多个团队共享，多年来由于一个单一的故障点被多个团队共享。
同时，在新的Artifactory服务器中，它在Kubernetes集群中配置为高可用性。那么，我们如何让这些事情发生，让这些改变发生呢?首先，我们需要更新TeamCity服务器和代理设置。在源代码中，我们需要更新对Artifactory服务器的硬代码引用。在用户站点上，更新时所有maven、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查询语言，只标识我们感兴趣的用于迁移工件的存储库。在这个例子中，我们包含了一个路径匹配来查找所有的/ 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配置。然后我们与用户沟通关于本地设置的更改，以及继续提供必要的支持。
今天的演讲到此结束。
非常感谢。
期待大家的提问，并在接下来的SwampUP活动中尽情享受。
谢谢你！
