你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

开发生命周期

开发生命周期策略为自动登陆区域创建期间的存储库、分支、自动构建、部署和回滚策略提供关键设计注意事项和建议。

存储库策略

设计注意事项

  • 考虑采用像 Git 这样的版本控制系统,为你的团队提供代码共享和管理的灵活性。

    • Git 是行业标准的版本控制系统。 它是一个分布式版本控制系统,你的本地代码副本是存储库的完整版本。
  • 了解 mono-repo 与 multirepo 存储库结构

    • 在单一存储库结构中,所有源代码都位于一个存储库中。
    • 在多存储库结构中,所有项目都组织到单独的存储库中。
  • 选择适合存储库内容的可见性设置。

    • 公共存储库可以匿名访问。
    • 专用存储库要求用户被授予对存储库的访问权限并登录以访问服务。
    • 你可以为 Azure DevOps ProjectsGitHub 存储库设置公共和私有可见性。
  • 考虑设置存储库权限,以帮助你控制谁可以为你的源代码做出贡献并管理其他功能。

  • 考虑将基础结构即代码 (IaC) 资源部署到 Azure。 IaC 允许你以声明性模型管理基础结构,有助于减少配置工作,确保部署之间的一致性,并避免手动环境配置。

  • Azure 通过以下方式为登陆区域的 IaC 提供支持:

设计建议

  • 使用 Git 作为版本控制系统。

  • 构建 Azure 登陆区域时使用私有存储库

  • 在共享自动化示例、公共文档和开源协作资料等非机密信息时,请使用公共存储库。

  • 采用 IaC 方法来部署、管理、治理和支持云资源。

分支策略

设计注意事项

  • 考虑使用允许团队更好地协作和有效地管理版本控制的分支策略

  • 考虑为你的分支使用特定的命名约定

  • 考虑使用分支权限来控制用户能力。

  • 考虑使用分支策略来帮助你的团队保护重要的开发分支。 有助于实施代码质量和变更管理标准的政策。 分支策略的示例包括:

  • 采用拉取请求策略可以帮助你控制合并到分支中的代码更改。

    • 定义合并策略
    • 拉取请求应该简单,文件数量保持在最低限度,以帮助审阅者更有效地验证提交和更改。
    • 拉取请求应该有明确的标题和描述,以便审阅者知道在审阅代码时会发生什么。
    • 可以使用拉取请求模板
    • 你可以在拉取请求完成后删除原始分支,从而为你提供更多控制和更好的分支管理。

设计建议

  • 采用基于主干的开发模型,其中开发人员致力于单个分支。 该模型有助于持续集成。 所有的功能性工作都在树干中完成,并且所有合并冲突都可在提交时解决。

  • 让你的团队为分支定义和使用一致的命名约定来识别已完成的工作。

  • 设置权限以控制谁可以读取和更新 Git 存储库分支中的代码。 你可以为单个用户和组设置权限。

  • 设置分支策略:

    • 要求使用拉取请求将分支合并到主分支。
    • 拉取请求需要最少数量的审阅者。
    • 重置所有批准投票以删除所有批准投票,但在源分支更改时保留投票以拒绝或等待。
    • 自动包括代码审阅者。
    • 检查注释解决情况。
  • 将 squash 设置为合并策略,这允许你在完成拉取请求时压缩主题分支的 Git 历史记录。 Squash 合并不是将主题分支上的每个提交添加到默认分支的历史记录中,而是将所有文件更改添加到默认分支上的单个新提交中。

自动化生成

设计注意事项

  • 考虑实施持续集成 (CI)。 CI 涉及定期将所有开发人员代码合并到一个中央代码库中,并自动执行标准构建和测试过程。

  • 考虑使用 CI 触发器:

    • Azure Repos Git。 你可以将分支、路径和标签配置为触发器以运行 CI 构建。
    • GitHub: 你可以配置分支、路径和标签触发器来运行 CI 构建。
  • 考虑在构建过程中包含 IaC 单元测试以验证语法。

  • 考虑在你的应用程序构建过程中包含单元测试。 查看可用于 Azure DevOps Pipeline 的任务。

  • 使用 Azure DevOps 服务连接或 GitHub 机密来管理与 Azure 的连接。 每个连接都应具有对 Azure 资源的正确访问权限。

  • 考虑使用 Azure 密钥保管库机密来存储和管理密码、API 密钥、证书等敏感信息。

  • Azure DevOps 代理可以自托管或 Microsoft 托管。

    • 当你使用 Microsoft 托管的代理时,系统会为你进行维护和升级。 每次运行构建作业时,都会创建一个新的虚拟机。
    • 你可以自行设置和管理自托管代理以运行构建作业。

设计建议

  • 每次团队成员提交对版本控制的更改时,使用 CI 自动构建和测试代码。

  • 将 IaC 和应用程序代码的单元测试作为构建过程的一部分。

  • 如果可能,请使用 Microsoft 托管的池而不是自托管的池,因为它们为每个管道运行提供隔离和干净的 VM。

  • 通过服务连接或 GitHub 机密将 Azure DevOps 或 GitHub 连接到 Azure 时,请确保始终定义范围,以便他们只能访问所需的资源。

  • 使用密钥保管库机密来避免对敏感信息进行硬编码,如凭据(虚拟机的用户密码)、证书或密钥。 然后在构建和发布作业中使用机密作为变量。

部署策略

设计注意事项

  • 考虑使用持续交付 (CD)。 CD 涉及从构建到环境的构建、测试、配置和部署。

  • 考虑使用环境。 环境允许你定位来自交付作业的资源集合。 常见环境名称的示例包括:

    • 开发
    • 测试
    • QA
    • 临时过程
    • 生产
  • 考虑使用 IaC 作为策略的一部分,以验证和确认部署前的变更。

设计建议

  • 使用 CD 通过自动构建、测试和部署代码到类似生产的环境来确保代码始终准备好部署。 添加持续交付以创建完整的 CI/CD 集成,帮助你尽早检测代码缺陷并确保你可以快速发布经过适当测试的更新。

  • 将环境用作部署策略的一部分。 环境提供以下好处:

    • 部署历史记录
    • 提交和工作项的可追溯性
    • 诊断资源健康状况
    • 安全性
  • 包括 IaC 部署前检查,这样就可以预览更改并查看创建、修改或删除资源的详细信息。

回滚策略

设计注意事项

  • 考虑制定回滚计划。 回滚部署涉及将部署恢复到已知的良好状态,并提供从失败的部署中恢复的关键能力。

  • 如果需要恢复提交中的更改、放弃更改或将分支重置为之前的状态,请考虑在 Git 中使用撤消更改

设计建议

  • 在需要恢复已提交文件的更改、放弃未提交的更改或将分支重置为之前的状态时,请在 Git 中使用撤销更改。