持续集成与持续交付与持续部署 [英] Continuous Integration vs. Continuous Delivery vs. Continuous Deployment
问题描述
这三个术语有什么区别？我的大学提供了以下定义：
持续集成基本上只是意味着开发人员的工作副本与一天的共享主线同步数次。
持续交付被描述为持续集成的逻辑演变：始终能够将产品投入生产！
持续部署在连续交付后被视为合乎逻辑的下一步：在通过质量检查时自动将产品部署到生产中
他们还提供一个警告：有时，如果您能够连续部署到测试系统，也会使用连续部署这一术语。
让我困惑。
持续集成
我同意你大学的定义。
您的版本控制系统中的分支策略。
它与您分配给开发人员的任务大小有关;如果一项任务估计耗时4-5个工作日，那么开发商在接下来的4-5天内不会有任何煽动性的交付，因为他还没有做任何事情。
所以大小很重要：
小任务=连续集成
大任务=频繁集成
理想任务大小不会超过一天的工作量。
持续交付
基本上有三个
b这所学校，参观 Addison-WesleyMartin Fowler签名系列，并假设自2007年发布以来被称为持续集成，2011年之后被称为持续递送，它们可能是与连续的 相同的概念性想法的第1 + 2卷。
strong>持续交付与敏捷软件开发相关
这所学校的想法是，持续交付是关于能够支持敏捷运动中的原则，而不只是作为一个概念性思想或意向而是真实的。
按照敏捷清单中的第一条原则设定，其中连续交付 实际上是第一次使用：
我们的最高优先级是通过早期和持续交付有价值的软件来满足客户。 p>
这所学校声称，持续交付是一种范例，涵盖对您的定义已完成。
此学校接受持续交付和热门词汇或大趋势DevOps
连续的（连续的）连续的方法，它们都是相同的硬币，它们都试图拥抱或封装这种新的范式或方法，而不只是一种技术。交付是持续部署的同义词
第三所学校倡导持续部署
当开发人员准备好一些东西时，它会立即传递给最终用户，在大多数情况下，意味着它应该被部署到生产环境中。
加入哪所学校
您的大学明显加入第一所学校，并声称我们指的是同一出版物系列的第1 + 2卷。我认为这是滥用「连续交货」一词。
我个人主张，持续交付现实生活中支持敏捷运动所提出的想法和概念。所以我加入了学校，说这个词包含了一个完整的范式，如DevOps。
使用
主要是由创建部署控制台的工具供应商主张，试图从更广泛使用的持续交付$ b
持续部署
持续部署的重点主要与最终用户对软件更新的访问依赖于更新一些集中的来源，这个集中的源并不总是容易更新，因为它是单一的或具有（太高）一致性（Web，SOA，数据库等）。
对于生产软件的许多域，如果没有集中的信息源（设备，消费产品，客户端安装等）或信息的集中源容易更新（应用商店工件管理系统，Open源代码仓库等），几乎没有关于术语连续部署的宣传。它们只是部署;这不是一件大事 - 这不是一个需要特别关注的痛苦。
连续部署不是每个人都感兴趣的事实，也是一个论点，学校声称交付和部署是同义词所有错了。因为即使你在设备中使用嵌入式软件或为框架发布开源插件，持续交付对每个人都是非常有意义的。
你的大学定义为连续部署是持续交付的一个自然的下一步骤，隐含地假定每个QA的交付应该立即变为对终端用户可用，更接近我部落用来描述术语持续发布的定义。
一个发布可以是一个非常具有战略性或政治性的东西，没有理由假设每个人都想一直这样做（除非他们是一家流媒体服务类型的公司的在线书店）。然而，不盲目地释放所有东西的公司可能有任何数量的原因，他们想要成为部署的主人，所以他们也做连续部署 。不是发布到生产，而是发布候选人到生产环境。
大学错了。他们错误地将持续部署视为持续发布。
持续部署只是一个连续地将开发过程的结果移动到
持续交付故事情节
在图片中，它都活着：
持续集成过程是状态转换图中的前两个动作。如果成功 - 则启动实现完成的定义的连续传递流水线。部署只是必须在此管道中不断进行的许多操作之一。理想情况下，进程从开发者提交到VCS的点自动进行到管道已经确认我们有一个有效的发布候选者的点。
What's the difference between these three terms? My university provides the following definitions:
Continuous Integration basically just means that the developer's working copies are synchronized with a shared mainline several times a day.
Continuous Delivery is described as the logical evolution of continuous integration: Always be able to put a product into production!
Continuous Deployment is described as the logical next step after continuous delivery: Automatically deploy the product into production whenever it passes QA!
They also provide a warning: Sometimes the term "Continuous Deployment" is also used if you are able to continuously deploy to the test system.
All this leaves me confused. Any explaination that is a little more detailed (or comes with an example) is appreciated!
Continuous Integration
I Agree with your university's definition. Continuous Integration is a strategy for how a developer can integrate code to the mainline continuously - as opposed to frequently.
You might claim that it's merely a branching strategy in your version control system.
It has to do with the size of the tasks you assign to a developer; If a task is estimated to take 4-5 man-days then the developer will have no incitement to deliver anything for the next 4-5 days, because he's not done with anything - yet.
So size matters:
small task = continuous integration
big task = frequent integration
The ideals task size is not bigger than a day's work. This way a developer will naturally have at least one integration per day.
Continuous Delivery
There are basically three schools within Continuous Delivery:
Continuous Delivery is a natural extension of Continuous Integration
This school, looks at the Addison-Wesley "Martin Fowler" signature series and makes the assumption that since the 2007 release was called "Continuous Integration" and the one that followed in 2011 was called "Continuous Delivery" they are probably volume 1+2 of the same conceptual idea that has to do with continuous something.
Continuous Delivery has to do with Agile Software Development
This school takes off-set in the idea that Continuous Delivery is all about being able to support the principles in the agile movement, not just as an conceptual idea or a letter of intent but for real - in real life.
Taking off-set in the first principle in the Agile Manifest where the term "continuous delivery" is actually used for the first time:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This school claims that "Continuous Delivery" is a paradigm that embraces everything required to implement an automated verification of your "definition of done".
This school accepts that "Continuous Delivery" and the buzz word or megatrend "DevOps" are flip sides of the same coin, in the sense that they both try to embrace or encapsulate this new paradigm or approach and not just a technique.
Continuous Delivery is a synonym to Continuous Deployment
The third school advocates that Continuous Deployment and Continuous Delivery can be used interchangeably to mean the same thing.
When something is ready by the hands of the developers, it's immediately delivered to the end-users, which in most cases will mean that it should be deployed to the production environment. Hence "Deploy" and "Deliver" means the same.
Which school to join
Your university clearly joined the first school, and claims that we're referring to volume 1+2 of the same publication series. My opinion is that this is a misuse of the term Continuous Delivery.
I personally advocate for the understanding that Continuous Delivery is related to implementing a real-life support for the ideas and concepts stated by the agile movement. So I joined the school that says the term embraces a whole paradigm - like "DevOps".
The school that uses delivery as a synonym to deploy is mostly advocated by tool vendors who create deployment consoles, trying to get a bit of hype from the more widespread use of the term Continuous Delivery.
Continuous Deployment
The focus on Continuous Deployment is mostly relevant in domains where the end-user's access to software updates relies on the update of some centralized source for this information and where this centralized source is not always easy to update because it's monolithic or has (too) high coherence by nature (web, SOA, Databases etc.).
For a lot of domains that produces software where there is no centralized source of information (devices, consumer products, client installations etc.) or where the centralized source for information is easy to update (app stores artifact management systems, Open Source repositories etc.), there is almost no hype about the term Continuous Deployment at all. They just deploy; it's not a big thing - it's not a pain that requires special focus.
The fact that Continuous Deployment is not something that is generically interesting to everyone is also an argument that the school that claims that "delivery" and "deploy" are synonyms got it all wrong. Because Continuous Delivery actually makes perfectly good sense to everyone - even if you are doing embedded software in devices or releasing Open Source plugins for a framework.
Your university's definition that Continuous Deployment is a natural next step of Continuous Delivery implicitly assumes that every delivery that is QA'ed should go become available to the end-users immediately, is closer to the definition that my tribe use to describe the term "Continous Release". Which in term is another concept that doesn't generically makes sense to everyone either.
A release can be a very strategic or political thing and there is no reason to assume that everybody would want to do this all the time (unless they are an online book store a streaming service type of company). Nevertheless, companies that don't blindly release everything all the time may have any number of reasons why they would want to be masters of deployment anyway, so they too do Continuous Deployment. Not of release to production, but of release-candidates to production-like environments.
Again I believe your university got it wrong. They are mistaking "Continuous Deployment" for "Continuous Release".
Continuous deployment is simply the disciplin of continuously being able to move the result of a development process to a production-like environment where functional testing can be executed in full scale.
The Continuous Delivery Storyline
In the picture it all comes alive:
The Continuous Integration process is the first two actions in the state-transition diagram. which - if successful - kicks off the Continuous Delivery pipeline that implements the definition of done. Deployment is just one of the many actions that will have to be done continuously in this pipeline. Ideally the process is automated from the point where the developer commits to the VCS to the point where the pipeline has confirmed that we have a valid release candidate.
这篇关于持续集成与持续交付与持续部署的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
