如上所述here,
以下是持续交付的原则。
Every build is a potential release
Eliminate manual bottlenecks
Automate wherever possible
Have automated tests you can trust
在传统的构建过程中，不使用持续交付方法，我们将代码提交到主分支，出于多种原因，主要是为了开发人员和测试人员之间的协作。
关于第一原则，每次提交如何可能成为潜在的发布？
这非常简单 - 如果您创建了一个提交并将更改推送到了 master，然后您运行了一个构建并且您的自动化测试全部成功执行，那么这个构建可以用作发布。
因此，原则与构建更相关，而不是提交，但是如果您已配置为针对推送到 master 的每个更改启动构建（Automate wherever possible原则），那么在这种情况下它是一个同义词。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
