持续交付的原则 [英] Principles of continuous delivery
问题描述
此处，
下面是连续交付的原则。
Below are the principles for continuous delivery.
Every build is a potential release
Eliminate manual bottlenecks
Automate wherever possible
Have automated tests you can trust
在传统的构建过程中，不使用连续交付方法，出于多种原因，我们在master分支中提交代码，主要是出于开发人员和测试人员之间的协作。
In traditional build process, without using continuous delivery approach, We commit the code in master branch, for multiple reasons, mainly for collaboration among developers and testers.
关于第一个原则，每个提交如何成为潜在的发布？
With respect to first principle, How can every commit be a potential release?
推荐答案
这很简单-如果创建了提交并将更改推送到主版本，然后运行构建并成功执行自动化测试，则可以将该构建用作发行版。
It's quite simple - if you created a commit and pushed changes to master and after that you run a build and your automated tests are all executed successfully, then this build can be used as a release.
因此，该原理与构建而不是提交有关，但是，如果您已配置为对推送到主服务器的每个更改都启动构建（尽可能地自动化原则），那么在这种情况下，它就是一个同义词。
So, the principle is more related to build rather than to commit, but if you've configured to start a build for every change that pushed to master (Automate wherever possible principle), then in this case it's a synonym.
这篇关于持续交付的原则的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
