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

部署基础结构的性能注意事项Performance considerations for your deployment infrastructure

"生成状态" 显示你的产品是否处于可部署状态,因此生成是持续交付系统的检测信号。Build status shows if your product is in a deployable state, so builds are the heartbeat of your continuous delivery system. 在产品开发的第一天启动并运行生成过程非常重要。It's important to have a build process up and running from the first day of your product development. 由于生成提供有关产品状态的重要信息,因此应始终努力快速构建。Since builds provide such a crucial information about the status of your product, you should always strive for fast builds.

如果生成过程需要更长时间,则很难修复生成问题,并且团队将受到损坏的窗口失序程度。It will be hard to fix build problem if it takes longer to build, and the team will suffer from a broken window disorder. 最终,任何人都不能在意生成是否被破坏,因为它始终中断,并需要很多精力来修复它。Eventually, nobody cares if the build is broken since it's always broken and it takes lot of effort to fix it.

生成时间Build times

可以通过以下几种方式实现更快的生成。Here are few ways you can achieve faster builds.

  • 选择正确的 vm 大小: 加速构建开始,选择正确的 Vm 大小。Selecting right size VMs: Speeding up your builds starts with selecting the right size VMs. Fast 计算机可以在小时与分钟之间产生差别。Fast machines can make the difference between hours and minutes. 如果管道位于 Azure Pipelines,则可以使用 Microsoft 托管的代理来方便地运行作业。If your pipelines are in Azure Pipelines, then you've got a convenient option to run your jobs using a Microsoft-hosted agent. Microsoft 托管的代理可以为你处理维护和升级操作。With Microsoft-hosted agents, maintenance and upgrades are taken care of for you. 有关详细信息,请参阅 Microsoft 托管的代理For more info see, Microsoft-hosted agents.

  • 生成服务器位置: 在生成代码时,会在网络中移动大量的位,因此,将从源代码管理存储库和项目存储库(如源代码、NuGet 包等)中提取生成的输入。最终,需要复制生成过程的输出,而不仅需要复制已编译的项目,还需要测试报告、代码覆盖率结果和调试符号。Build server location: When you're building your code, a lot of bits are moved across the wire, so inputs to the builds are fetched from a source control repository and the artifact repository, such as source code, NuGet packages, etc. At the end, the output from the build process needs to be copied, not only the compiled artifacts, but also test reports, code coverage results, and debug symbols. 因此,这些复制操作的速度非常快。So it is important that these copy actions are fast. 如果你使用自己的生成服务器,请确保生成服务器位于源和目标位置附近,并可显著缩短生成的持续时间。If you are using your own build server, ensure that the build server is located near the sources and a target location, and it can reduce the duration of your build considerably.

  • 横向扩展生成服务器: 单个生成服务器可能足以满足小型产品的需求,但随着产品的规模和范围以及对产品进行操作的团队数量的增加,单台服务器可能不够用。Scaling out build servers: A single build server may be sufficient for a small product, but as the size and the scope of the product and the number of teams working on the product increases, the single server may not be enough. 达到限制时,可在多台计算机上水平缩放基础结构。Scale your infrastructure horizontally over multiple machines when you reach the limit. 有关详细信息,请参阅如何使用 Azure DevOps 代理池For more info see, how you can leverage Azure DevOps Agent Pools.

  • 优化生成:Optimizing the build:

    • 添加并行生成执行,以便我们可以加快生成过程。Add parallel build execution so we can speed up the build process. 有关详细信息,请参阅 Azure DevOps 并行作业For more info see, Azure DevOps parallel jobs.

    • 启用并行执行测试套件,这通常是一种非常大的时间保护程序,特别是在执行集成和 UI 测试时。Enable parallel execution of test suites, which is often a huge time saver, especially when executing integration and UI tests. 有关详细信息,请参阅 使用 Azure 管道并行运行测试For more info see, Run tests in parallel using Azure Pipeline.

    • 使用乘数的概念,你可以在其中扩展多个生成代理上的生成。Use the notion of a multiplier, where you can scale out your builds over multiple build agents. 有关详细信息,请参阅将 Azure 管道组织到作业中。For more info see, Organizing Azure Pipeline into Jobs.

    • 将部分测试反馈循环移到发布管道。Move a part of the test feedback loop to the release pipeline. 这将提高生成速度,并因此生成反馈循环的速度。This improves the build speed, and hence the speed of the build feedback loop.

    • 将生成项目发布到程序包管理系统解决方案,因此在生成结束时发布到 NuGet 源。Publish the build artifacts to the package management system solution, and hence publish to a NuGet feed at the end of a build.

人工干预Human intervention

为不同目的选择不同的版本非常重要。It's important to select different builds for different purpose.

  • CI 生成: 此版本的目的是确保编译和运行单元测试。CI builds: Purpose of this build is to ensure it compiles and unit tests run. 此生成将在一段时间内的每次提交或提交集时触发。This build gets triggered at each commit or set of commits over a period of time. 它作为项目的检测信号,可立即向团队提供质量反馈。It serves as the heartbeat of the project, provides quality feedback to the team immediately. 有关详细信息,请参阅 ci 触发器或批处理 ci 生成For more info see, CI triggers or Batching CI builds.

  • 夜间生成: 此版本的用途不仅是编译,还应确保运行必要的集成/回归测试。Nightly build: Purpose of this build is not only to compile but also ensure necessary integration/regression tests are run. 此生成可能需要更多时间,因为我们需要执行一些额外的步骤来获取有关该产品的其他信息。This build can take up some more time, because we need to do some extra steps to get additional information about the product. 例如,有关使用 SonarQube 的软件状态的指标。For example, metrics about the state of the software using SonarQube. 它还可能包含一组回归测试和集成测试,还可能会将解决方案部署到临时计算机,以验证解决方案是否正在继续工作。It may also contain a set of regression tests and integration tests and it may also deploy the solution to a temporary machine to verify the solution is continuing to work. 有关详细信息,请参阅 使用 cron 语法安排生成For more info see, scheduling builds using cron syntax

  • 发布版本: 除了进行编译外,运行测试这一生成还会编译 API 文档、符合性报告、代码签名以及在每次生成代码时不需要的其他步骤。Release build: Besides compiling, running test this build additionally compiles the API documentation, compliance reports, code signing, and other steps which are not required every time the code is built. 最后,此版本提供了黄金副本,该副本将推送到发布管道,以便在生产环境中进行部署。Finally this build provide the golden copy that will be pushed to the release pipeline to finally deploy in the production environment. 通常,手动触发 release 生成,而不是 CI 触发器。Generally release build is gets triggered manually instead of a CI trigger.

后续步骤Next steps