过这些关卡意味着成功通过性能、回归和可访问性测试。增加的门禁包括：
AccessibilityTesting
An automated testing tool that produces a scorevaluewhichisthencomparedagainstapredefinedminimumscoretobeconsideredpassing.
可访问性测试
通过一个自动化测试工具，产生一个分数值，然后与预定的最低分数进行比较，如果大于这个最低分数就可以认为是通过了。
SecretsScanner
TheSecretScannerlooksforplaintextsecretswithinsourcecode.Anythingthatcouldgrantknowledgeoraccesstoitemsthatpeopleshouldotherwisenothaveaccesswouldbeconsideredasecret.
秘密扫描器
秘密扫描器寻找源代码中的纯文本秘密（译者注：比如密钥）。任何可能授予人们知识或人们不应该访问东西会被认为是秘密。
SecurityScanner
Security Scanner is an automated scan that checksforanydependencyvulnerabilities.
安全扫描器
安全扫描器是一种自动扫描，可以检查任何依赖性的漏洞。
ContentScanner
A content scanner looks for language-specific filesanddirectoriesthatshouldnotexistwithinsourcecontrol.
内容扫描器
内容扫描器寻找不应该存在于源代码控制中的特定语言的文件和目录。
StaticCode Analysis
A Static Code Analysis tool measures code qualityviaunit-testcoverageandreportsinformationaboutcodequalitytoCItools.
静态代码分析
静态代码分析工具通过单元测试覆盖率度量代码质量，并向CI工具报告代码质量信息。
7.8 Deployments 部署
The ability for each team to autonomously deploy components on demand has been a game-changer in many high-performing organizations like Spotify [34]. Deployment rates were increased from the end of every Sprint to an on-demand Continuous Integration/Continuous Deployment pipeline (CI/CD). Dependencies on other release teams were eliminated to allow for on-demand independent releases by each team. Deployments could occur at any time due to downtime being eliminated through the use of Blue- Green Deployments [35].
每个团队按需自主部署组件的能力已经成了许多高绩效组织（比如Spotify）的制胜法宝 [34]。部署频率从每个Sprint结束时进行一次提高到利用CI/CD流水线按需持续集成和持续部署。客户营销部通过努力消除了发布团队间的依赖性，允许每个团队按需独立发布。由于通过使用蓝绿部署消除了停机时间，部署可以在任何时候发生[35]。
Previously, deployments happened at a maximum of once per week, with a typical cadence of once every two weeks. This was because code deployments involved an external team that manually deployed code to production environments, and this could only be done during late evening hours because of downtime that would occur. The deployments took multiple hours of planning and coordination. The actual code deployment would last 2-3 hours, frequently resulting in needing to roll back the deployment if changes caused unanticipated errors in production.
以前，部署工作最多每周一次，典型的节奏是每两周一次。这是因为代码部署涉及到一个外部团队，他们手动将代码部署到生产环境中，而这只能在晚间进行，因为可能会出现宕机的情况。每次部署都需要几个小时的计划和协调。实际的代码部署将持续2-3个小时，如果变更导致生产环境中出现意想不到的错误，需要频繁的回滚部署。
7.9 Infrastructure 基础设施
The current infrastructure dependencies caused bottlenecks and increased cycle times. All Scrum Teams were dependent on an external infrastructure team that would manage on-premises servers. The servers were a black box to the
