持续集成/持续交付 (CI/CD) 软件（即团队用来构建、测试和部署应用程序的解决方案）在过去十年中取得了长足的进步。
组织曾经使用不同的开源工具拼凑 CI/CD 管道，但现在他们拥有大量端到端、供应商支持的企业 CI/CD 平台可供使用。由于这些解决方案提供了团队交付软件所需的一切，因此它们更易于部署和管理。
然而，尽管采用企业 CI/CD 平台有明显的好处，但迁移到该平台可能很困难。它带来了许多挑战，例如 CI/CD 管道停机风险以及安全和合规性挑战。
这就是为什么企业在迁移到较新的 CI/CD 解决方案时，应该制定详细的分步计划。下面介绍要克服的挑战，以及如何使 CI/CD 迁移尽可能顺利的提示。
为了展开讨论，我将重点介绍如何从 GitHub（现归 Microsoft 所有）迁移到 CI/CD 平台 GitHub Enterprise。在我的工作中，我看到越来越多的企业选择 GitHub Enterprise，帮助企业实现 IT 和软件交付实践的现代化。
GitHub Enterprise 迁移面临的挑战
GitHub Enterprise 是一个全面的 CI/CD 平台，可作为完全托管的解决方案使用，因此一旦迁移到该平台，使用起来就相对容易。不过，挑战在于将代码放入平台，以及进行必要的流程更改，以便开始使用该解决方案代替传统的 CI/CD 套件。
具体来说，预计将面临的挑战包括：
- 应用程序交付延迟：漫长而耗时的迁移过程会导致 CI/CD 操作停机，这意味着您的开发人员将无法推出应用程序更新。这最终会损害业务，因为在您的 CI/CD 管道转换期间，用户无法收到功能增强。
- 性能风险：未能选择正确的 GitHub Enterprise 部署策略并以最佳方式配置解决方案，可能会降低 CI/CD 性能并降低开发人员的工作效率，因为构建和测试应用程序的基础设施资源不足等问题。
- 培训要求：熟练的软件开发人员通常可以轻松学会使用新的 CI/CD 平台，但仍需要提高技能。重要的是不要忽视为开发人员提供时间来学习 GitHub Enterprise（或您要迁移到的任何解决方案）的必要性。
- 安全性和合规性：为了减轻恶意代码注入应用程序等风险，在迁移过程中实施访问控制以防止未经授权的用户访问新的 CI/CD 平台至关重要。
顺利进行 CI/CD 平台迁移的最佳实践
好消息是，只要采用正确的方法，迁移到 GitHub Enterprise 或类似的 CI/CD 平台就不必担心风险。以下最佳实践可以帮助简化流程。
- 选择正确的托管选项
与许多 CI/CD 平台一样，GitHub Enterprise 有两种基本形式：完全托管的基于云的选项和用户可以使用自己的基础架构安装和管理的版本。
总体而言，完全托管的解决方案往往是更好的选择，因为它可以大大减少用户的设置和维护工作量。但是，对于需要更好地控制其 CI/CD 环境的组织来说，自托管选项可能更合适。对于金融和保险等垂直行业的企业来说尤其如此，当组织在自己的基础设施上运行 CI/CD 软件时，安全和合规要求可能更容易满足（因此可以更好地控制敏感数据的管理和保护方式）。
- 配置细粒度的访问策略
与大多数现代 CI/CD 套件一样，GitHub Enterprise 提供访问控制功能，企业可以使用这些功能来确定谁可以在 CI/CD 工具中执行什么操作。例如，您可以授予某些开发人员对源代码的只读访问权限，同时允许其他开发人员对其进行修改。GitHub Enterprise 还支持基于环境的访问设置，这意味着您可以在开发/测试和生产环境中为同一用户配置不同的访问权限级别。
作为最佳实践，请利用这些细粒度的访问控制选项，为使用 CI/CD 平台的每个团队分配不同的访问权限。例如，您可能有一个管理团队，其权限扩展到更改 GitHub Enterprise 的配置，而另一个仅使用该平台的团队的访问权限级别较低。
- 使用 OpenID Connect 与云环境集成
GitHub Enterprise 提供身份管理选项，利用 OpenID Connect (OIDC) 与第三方云环境集成。
利用此功能，您可以在公共云基础架构上自动运行工作流程（例如应用程序构建），而无需将云访问凭据存储为长期存在的 GitHub 机密，这会带来很大的安全风险。此外，此方法会自动创建 GitHub 工作流程和操作执行的日志，您可以将其用于审计和监控目的。
- 利用单点登录
简化向 GitHub Enterprise 迁移的另一种方法是将该平台与您的企业已使用的单点登录 (SSO) 提供商（如 Microsoft Entra 或 Active Directory）集成。理想情况下，您还将通过 SSO 解决方案启用多因素身份验证 (MFA)，以增加另一层安全性。
这种方法无需单独管理现有帐户中的 GitHub Enterprise 访问凭据。它还减轻了 IT 团队在迁移过程中的负担，因为他们不必“重新发明轮子”，而是只需使用现有的登录解决方案即可。
- 记录常见任务
为了简化开发人员迁移到 GitHub Enterprise 的学习曲线，请记录常见任务 – 例如如何将代码从本地存储库或其他 CI/CD 平台迁移到 GitHub Enterprise。
这是另一种策略，它使您的团队无需反复重新发明轮子；每个人都可以遵循既定的计划，而不必强迫每个工程师自己想办法进行迁移。
- 发布工作流模式
更进一步，还可以考虑发布有关如何使用 GitHub Enterprise 中可能对所有团队都很重要的关键功能的详细步骤。例如，您可以详细说明如何在平台中创建拉取请求或构建 Docker 映像，或者如何执行基础设施即代码 (IaC) 部署。
再次，此策略降低了学习曲线，并帮助您的团队尽快在新平台上启动和运行。
- 使用 GitHub Actions 自动化常见工作流程
更进一步，您可以使用 GitHub Actions 为常见任务创建完全自动化的工作流程，该功能可让您在 CI/CD 管道的各个部分触发自动化操作。例如，您可以在代码签入后自动触发应用程序构建，或者在构建完成后自动开始测试。
不同项目或团队之间可能存在差异的高度复杂的工作流程并不适合这种类型的自动化，但核心例程可以完全自动化，从而使您的团队更容易开始使用新平台。
结论
无论您采用何种方式，迁移到 GitHub Enterprise 或其他现代 CI/CD 平台都需要时间和精力。但是，通过战略性地处理迁移，您可以最大限度地减少时间和精力——如果您想避免 CI/CD 迁移带来的风险并尽可能快速顺利地在新平台上启动和运行您的管道，就必须这样做。
