您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

登陆区域的测试驱动开发 (TDD)Test-driven development (TDD) for landing zones

测试驱动的开发是一种常见的软件开发和 DevOps 过程,可提高任何基于代码的解决方案中新功能和改进的质量。Test-driven development is a common software development and DevOps process that improves the quality of new features and improvements in any code-based solution. 基于云的基础结构和基础源代码可以使用此过程来确保登陆区域满足核心要求并且具有高质量。Cloud-based infrastructure, and the underlying source code can use this process to ensure landing zones meet core requirements and are of high quality. 当在并行开发工作中开发和重构登陆区域时,此过程特别有用。This process is especially useful when landing zones are being developed and refactored in a parallel development effort.


在云中,基础结构是代码执行的输出。In the cloud, infrastructure is the output of code execution. 结构良好、经过测试和验证的代码会生成一个可行的登陆区域。Well-structured, tested, and verified code produces a viable landing zone. 登陆区域是用于托管工作负荷的环境,预配置通过代码。A landing zone is an environment for hosting your workloads, preprovisioned through code. 它包含基础功能,这些功能使用一组定义的云服务和最佳实践来实现成功。It includes foundational capabilities using a defined set of cloud services and best practices that set you up for success. 本指南介绍一种方法,该方法使用测试驱动的开发来完成该定义的最后一部分,同时满足质量、安全性、操作和监管要求。This guidance describes an approach that uses test-driven development to fulfill the last part of that definition, while meeting quality, security, operations, and governance requirements.

此方法可用于在早期开发过程中满足简单的功能请求。This approach can be used to meet simple feature requests during early development. 稍后在云采用生命周期内,此过程可用于满足安全、操作、监管或合规性要求。Later in the cloud adoption lifecycle, this process can be used to meet security, operations, governance, or compliance requirements.

完成的定义Definition of done

"设置为成功" 是一种主观语句。"Set up for success" is a subjective statement. 在登陆区域开发或重构工作期间,此声明为云平台团队提供了极少的可操作信息。This statement provides the cloud platform team with little actionable information during landing zone development or refactoring efforts. 缺乏清晰的情况可能导致云环境中缺少预期和漏洞。This lack of clarity can lead to missed expectations and vulnerabilities in a cloud environment. 在重构或展开任何登陆区域之前,云平台团队应当清楚地了解每个登陆区域的 "已完成定义"。Before refactoring or expanding any landing zone, the cloud platform team should seek clarity regarding the "definition of done" for each landing zone.

"完成" 的定义是云平台团队与其他受影响团队之间的一个简单协议。Definition of done is a simple agreement between the cloud platform team and other affected teams. 本协议概述了预期的增值功能,这些功能应包括在任何登陆区域开发工作中。This agreement outlines the expected value added features, which should be included in any landing zone development effort. "完成" 的定义通常是一种与短期云采用计划相匹配的清单。The definition of done is often a checklist that's aligned with the short-term cloud adoption plan. 在成熟的进程中,清单中的预期功能都有其自己的验收标准来更清晰地创建。In mature processes, those expected features in the checklist will each have their own acceptance criteria to create even more clarity. 当增值功能每个都满足验收条件时,登陆区域已充分配置为实现当前波或发布的成功。When the value-added features each meet the acceptance criteria, the landing zone is sufficiently configured to enable the success of the current wave or release of adoption effort.

当团队采用其他工作负荷和云功能时,已完成和验收条件的定义将变得越来越复杂。As teams adopt additional workloads and cloud features, the definition of done and acceptance criteria will become increasingly more complex.

测试驱动开发周期Test-driven development cycle

使测试驱动开发有效的循环通常称为红色/绿色测试。The cycle that makes test-driven development effective is often referred to as a red/green test. 在此方法中,云平台团队基于已完成和已定义的验收条件的定义, (红色测试) 开始失败测试。In this approach, the cloud platform team starts with a failed test (red test) based on the definition of done and defined acceptance criteria. 对于每个功能或验收条件,云平台团队将完成开发任务,直到测试通过 (绿色测试) 。For each feature or acceptance criteria, the cloud platform team would complete development tasks until the test passes (green test). 测试驱动的开发周期 (或红色/绿色测试) 会重复下图和下表中的基本步骤,直到可以满足完成的完整定义。A test-driven development cycle (or red/green test) would repeat the basic steps in the following image and list below until the full definition of done can be met.


  • 创建测试: 定义测试以验证是否满足特定值添加功能的验收条件。Create a test: Define a test to validate that acceptance criteria for a specific value-add feature has been met. 尽可能自动执行测试。Automate the test whenever possible.
  • 测试登陆区域: 运行新的测试和任何现有的测试。Test the landing zone: Run the new test and any existing tests. 如果以前的开发工作中尚未满足所需的功能,并且不包括云提供商的产品/服务,则测试应该会失败。If the required feature hasn't already been met by prior development efforts and isn't inclusive to the cloud provider's offering, the test should fail. 运行现有测试有助于验证新的测试是否不会降低现有代码提供的登录区域功能的可靠性。Running existing tests will help validate that your new test doesn't reduce reliability of landing zone features delivered by existing code.
  • 展开并重构登陆区域: 添加或修改源代码以满足请求的值添加功能,并提高基本代码的质量。Expand and refactor the landing zone: Add or modify the source code to fulfill the requested value-add feature and improve the general quality of the code base. 为了满足测试驱动开发的最大精神,云平台团队只需添加代码即可满足所请求的功能。To meet the fullest spirit of test-driven development, the cloud platform team would only add code to meet the requested feature and nothing more. 同时,代码质量和维护是一种共享工作。At the same time, code quality and maintenance is a shared effort. 在满足新功能请求时,云平台团队应通过删除重复项并阐明代码来寻找改进代码。When fulfilling new feature requests, the cloud platform team should seek to improve the code by removing duplication and clarifying the code. 强烈建议在新代码创建和源代码重构之间运行测试。Running tests between new code creation and refactoring of source code is highly suggested.
  • 部署登陆区域: 一旦源代码能够满足功能请求,就可以在受控测试或沙盒环境中将修改后的登陆区域部署到云提供商。Deploy the landing zone: Once the source code is capable of fulfilling the feature request, deploy the modified landing zone to the cloud provider in a controlled testing or sandbox environment.
  • 测试登陆区域: 重新测试登陆区域应该验证新代码是否满足所请求功能的验收条件。Test the landing zone: Retesting the landing zone should validate that the new code meets the acceptance criteria for the requested feature. 所有测试通过后,此功能将被视为已完成,并且认为满足验收条件。Once all tests pass, the feature is considered complete and the acceptance criteria are considered to be met.

当所有增值功能和验收条件都通过其关联的测试时,登陆区域就已准备就绪,可以支持下一轮云采用计划。When all value-added features and acceptance criteria pass their associated tests, the landing zone is ready to support the next wave of the cloud adoption plan.

完成定义的简单示例Simple example of a definition of done

对于初始迁移工作,完成的定义可能非常简单。For an initial migration effort, definition of done may be overly simple. 下面是其中一个非常简单的示例的示例。The following is an example of one of these overly simple examples.

  • 初始登陆区域将用于托管10个工作负荷,用于初始学习目的。The initial landing zone will be used to host 10 workloads for initial learning purposes. 这些工作负荷对业务并不是对敏感数据的访问权限。These workloads are not critical to the business and have no access to sensitive data. 将来,这些工作负荷很可能会发布到生产环境中,但关键程度和敏感性不应更改。In the future, it's likely these workloads will be released to production but criticality and sensitive is not expected to change. 为支持这些工作负荷,云采用团队需要满足以下条件:To support these workloads, the cloud adoption team will need the following criteria met:

  • 网络分段,与建议的网络设计保持一致。Network segmentation to align with proposed network design.

  • 访问计算、存储和网络资源,以承载与数字房地产发现一致的工作负荷。Access to compute, storage, and networking resources to host the workloads aligned to the digital estate discovery.

  • 命名并标记架构以方便使用。Naming and tagging schema for ease of use.

  • 应将此环境视为有权访问公共 internet 的外围网络。This environment should be treated as a perimeter network with access to the public internet.

  • 在采用工作过程中,云采用团队会对环境进行临时访问,以更改服务配置。During adoption efforts, the cloud adoption team would like temporary access to the environment to change service configurations.

  • 仅出于识别目的:在生产版本之前,这些工作负荷需要与企业标识提供者集成,以控制正在进行的标识和访问,以便进行操作管理。For awareness only: prior to production release, these workloads will require integration with the corporate identity provider to govern ongoing identity and access for operations management purposes. 此时应吊销云采用团队的访问权限。At which time the cloud adoption team's access should be revoked.

上面最后一个点不是功能或验收条件。The last point above is not a feature or acceptance criteria. 但这是一个指示,将需要其他扩展,并且应及早与其他团队探讨。But it is an indicator that additional expansions will be required and should be explored with other teams early.

完成定义的其他示例Additional examples of a definition of done

云采用框架内的管理方法提供了一个有关管理团队自然成熟度的叙述。The Govern methodology within the Cloud Adoption Framework provides a narrative journey through the natural maturity of a governance team. 此旅程中嵌入了几个 "完成定义" 和 "验收条件" 的示例。Embedded in that journey are several examples of "definition of done" and "acceptance criteria", in the form of policy statements.

  • 初始策略声明:企业策略的示例,以及基于提前阶段采用要求完成的初始定义。Initial policy statements: Example of corporate policies governing and initial definition of done based on early stage adoption requirements.
  • 标识扩展:企业策略的示例,该示例管理已 完成的定义 ,以满足为登陆区域展开标识管理的要求。Identity expansion: Example of corporate policies governing definition of done to meet requirements to expand identity management for a landing zone.
  • 安全扩展:企业策略的示例,该示例管理已 完成的定义 ,以满足与参考云采用计划相匹配的安全要求。Security expansion: Example of corporate policies governing definition of done to meet security requirements aligned to the reference cloud adoption plan.
  • 操作扩展:企业策略的示例,管理 完成的定义 ,以满足基本操作管理要求。Operations expansion: Example of corporate policies governing definition of done to meet basic operations management requirements.
  • 成本扩展:企业策略的示例,管理 完成的定义 ,以满足成本管理要求。Cost expansion: Example of corporate policies governing definition of done to meet cost management requirements.

以上示例是基本示例,用于帮助为你的登陆区域制定 完成的定义The above examples are basic samples to help develop a definition of done for your landing zones. 对于 云管理的五个层面,还提供了其他示例策略。Additional sample policies are available for each of the Five Disciplines of Cloud Governance.

后续步骤Next steps

若要加快 Azure 中的测试驱动开发,请查看 azure 的测试驱动开发功能To accelerate test-driven development in Azure, review test-driven development features of Azure.