全面回答什么是持续集成和持续交付？

本文介绍了持续部署，持续学习，持续交付，DevOps开发以及运营和维护，希望对您的学习有所帮助.

持续集成（CI –持续集成）

以传统方式，集成过程通常在每个人完成工作之后和项目结束时进行. 集成过程通常需要数周甚至数月，并且可能非常痛苦. 持续集成是在开发周期的早期阶段进行集成的一种做法，因此可以更频繁地构建和集成代码.

CI表示在家里用笔记本电脑写代码的开发人员（例如Steve）和在办公室桌上写代码的开发人员（例如Annie）可以分别为同一产品编写软件. 称为源代码存储库的地方. 然后他们可以根据编写并合并在一起的代码来构建软件，并测试其是否按预期的方式工作.

开发人员通常使用称为CI服务器的工具来构建和集成它们. CI要求Steve和Annie具有自检代码. 这些代码测试本身可确保它们将按预期工作. 通常会调用这些测试. 集成代码后，当所有单元测试通过时，Steve和Annie将获得绿色的构建版本. 这表明他们已经验证了他们的更改已成功集成，并且代码按测试所期望的正常工作.

但是，尽管集成代码可以成功运行，但仍无法投入生产，因为尚未在类似的生产环境中对其进行过测试和验证以表明其可以正常工作.

完成CI后，您可以在下面的“连续交付”部分中阅读更多信息.

为了练习CI，Steve和Annie必须将代码提交到主要的源代码存储库，并频繁且频繁地集成和测试其代码. 通常每小时一次，但每天至少一次.

CI的优点是集成代码成为“非事件”. 该软件已编写并集成. 在使用CI之前，代码集成是在创建过程完成之后发生的，所有集成一次完成，并且花费的时间未知. 现在，借助CI，代码集成每天都在发生，而只需几分钟. 这只是我们的工作方式.

您的团队可能正在执行CI（或者至少他们认为自己正在制造麻烦）. 您可以询问他们是否每天都集成代码来确认这一点. CI是连续交付所需的第一个实践. 实际上，如果您签入了帮助文本，文档或图片，则可能一直在进行集成.

连续交付（CD）

让我们回到两个开发人员史蒂夫和安妮. 持续交付意味着Steve或Annie每次对代码进行更改，集成和构建时，他们还将在与生产环境非常相似的状态下进行自动化代码测试. 我们将在不同环境中的这一系列“部署测试”操作称为部署管道. 一般而言，部署管道具有开发环境，测试环境和准生产环境，但是这些阶段随团队，产品和组织的不同而不同. 例如，我们的Mingle团队拥有一个称为“蛋糕”的准生产环境，而Etsy的准生产环境则称为“公主”. （注释: 消除开发环境和生产环境之间的差异，请参阅Docker技术系统）

在每个不同的环境中，由Annie或Steve编写的代码都将分别进行测试. 这给了他们越来越大的信心. 对您来说，将代码部署到生产环境中时，它将起作用. 至关重要的是，只有通过部署管道中的先前测试的代码才能被提升到下一个测试环境. 这样，Annie和Steve可以从每个环境的测试中获得新的反馈. 如果出现问题，他们可以更轻松地了解问题出在哪里，并在代码进入生产环境之前对其进行修复.

持续学习（持续学习）

此过程对我们的工作非常有帮助. 这意味着，如果在所有环境中都通过了安妮的测试，则可以知道她的代码应在生产环境中按预期工作. 在测试完所有环境之后，您可以立即决定用户是否可以使用它. 我们现在是否要将此绿色建筑用于生产？当然！而且，当您的开发人员完成构建时，将立即向客户提供经过全面测试的新工作软件. 双！

连续部署（连续部署）

这是一种实践，也就是说，在通过所有测试阶段后，史蒂夫（Steve）和安妮（Annie）所做的每项更改都会自动投入生产. 蒂姆·菲茨（Tim Fitz）首先提出了一个很好的解释. 有些公司这样做，而另一些则没有. 如果要实现连续部署，则必须首先实现连续交付. 因此，在开始练习CD之前，哪一种更适合您都没关系. 无论哪种方式，我都认为持续交付与有助于整体业务能力的事物有关，因此您至少应参与决定是否使用持续部署. 毕竟，如果您正在阅读本文，那么您可能站在“业务方面”.

DevOps（开发和运营–开发和运营）

“ DevOps”一词源自“开发-发展”和“运营-运营”的词汇组合. DevOps是一种文化，可促进开发人员（例如Steve和Annie）和其他人员（例如5星级运营和维护明星Joey）之间的合作-通常被称为运营和维护. 具体来说，它是软件交付和部署过程中的交流与协作，旨在更快，更可靠地发布更高质量的软件.

具有所谓DevOps文化的组织的共同特征是: 具有多种技能的独立团队（Steve，Annie和Joey属于同一团队），高级测试和发布自动化（连续交付），以及共同的目标，具有多种技能的团队成员.

您可能会发现，可以在您的组织中使用的模型之一是，我们的开发人员Steve和Annie将与诸如Joey之类的运营人员一起交付完成的软件，而不仅仅是他们刚刚完成的代码. 同样python持续交付，史蒂夫（Steve），安妮（Annie）和乔伊（Joey）都是公共产品或服务团队的成员，他们将共同负责产品支持和维护，而不是让运营和维护团队独自承担支持的责任.

您还将看到，对于实现CD和DevOps的组织而言，动作的自动化变得越来越重要. 这是因为，为了实现CD和DevOps所期望的可重复，正常且成功的软件发布过程，组织必须转向自动化. 手动过程容易出错且效率低下.

DevOps文化通常与持续交付相关联，因为它们都旨在增强开发人员和运营团队之间的协作，并且它们都使用自动化流程来更快，更频繁，更可靠地构建，测试和发布软件. 人们喜欢我们想要的所有这些东西.

下一步是什么？

尽管开发团队经常看到流程改进的直接好处，但是CI，CD和DevOps对我们其他人也有很多好处. 简而言之，我相信实践CD并拥护DevOps文化的组织将能够更频繁地向其客户提供更有价值，更可靠的软件. 这不是很好吗？尤其是如果您处于“商业方面”（更多的客户信任，更多的订单）.

有用的条款

签到–签入

将本地开发的代码更改推送到常规代码存储库的过程. （注释: 也称为“提交”）

CI服务器–持续集成服务器

用于构建和测试源代码的工具. CI服务器将告知开发人员最新的代码构建是否成功以及是否继续通过测试.

开发环境–开发环境

开发人员在哪里创建，集成，构建和测试代码.

部署管道–部署管道

这是Steve和Annie的代码在准备好准备好交付生产环境之前经历的一系列阶段. 一般来说，这些将是“构建，单元测试，部署”. 不同的将在不同的阶段运行. 只有当代码贯穿整个部署管道运行时，软件才能交付到生产环境.

绿色建筑–绿色建筑

绿色是成功的标志. 绿色版本或内部版本是通过测试开发和交付过程的特定阶段的版本. 通常，除非构建或版本为绿色，否则不会升级到部署管道的下一阶段. 绿色版本的反面是红色版本（见下文）

增量开发-增量开发

不要与迭发相混淆（见下文）. 增量开发是指一次完成产品结构的一小部分，直到全部完成. 将一部分添加到每个增量中，这些增量可能很小也可能很大. 您可以通过增量开发来使用CI，但是使用增量开发可能难以实现连续交付或连续部署，因为您必须等到所有增量完成后才能交付价值. Jeff Paton的《蒙娜丽莎》（Mona Lisa）是解释增量开发与迭发之间差异的一个很好的例子. （注释: 请参见下图，这意味着达到目标的不同方式）

增量开发

迭发

整合-整合

个人或团队编写的所有代码都需要合并. 我们称之为整合. 在持续集成中，我们通常意味着需要定期合并个人的软件代码. 在连续交付中，我们通常指的是来自不同团队的软件集成，以创建整个产品.

迭发-迭发

不要与渐进式开发相混淆（请参见上文）. 迭发是从头到尾一个接一个地构建产品，并不断改进直至完成. 该产品是迭发的，这意味着每次迭代都必须改进同一部分. 功能在不同的迭代中是不同的，并且计划的和预期的产品更改介于两者之间. 您可以使用连续集成，连续交付或连续部署进行迭发. 参见上图，了解增量开发与迭发之间的区别.

主/干/干线–（翻译: 源代码管理系统中的分支概念，有关详细信息，请参阅Git代码管理系统）

“ Master / trunk / mainline”是源代码存储库的主分支，即主行. 大多数人都在主干上发展，这意味着他们总是将自己的更改集成到主线中. 当个别开发人员拥有自己的分支机构，或者团队将具有不同特性的分支机构时，其他人则使用基于分支的开发.

生产环境–生产环境

在此处部署或发布软件. 使用您的产品或网站的客户最有可能使用此环境. 也可以称为: “生产中”，“产品中”python持续交付，“”.

红色版本–红色版本

红色表示失败. 红色版本或内部版本是指在开发和交付过程中未通过特定测试阶段的版本. 通常，如果软件以红色构建，则不会升级到部署管道的下一个阶段. 红色结构与绿色结构相反.

源存储库–源代码存储库

这是源代码所在的位置. 史蒂夫（Steve）和安妮（Annie）有他们正在处理的本地代码版本（这意味着代码在自己的计算机上），但是在开发人员提交修改后的代码之后，源代码存储库将包含所有代码.

测试自动化–自动化测试

持续集成和持续交付需要高质量的自动化测试. 测试是一种检查软件是否按预期工作的方法. 自动化测试是对代码编写的测试，可以在将代码检入公共源代码存储库后自动运行.

在CI领域，每当集成和构建软件时都运行单元测试. 如果测试失败，则将软件版本确定为“红色”，“中断”. 发生这种情况时，某些工作场所将出现“红灯”或悲伤的声音（提示构建失败）.

如果构建失败，则Steve和Annie（提交错误代码的人）需要对其进行修复，使其绿色并使其正常工作. 他们可以修改代码来修复它，或者删除导致中断的更改.

单元测试–单元测试

单元测试是代码中的自动化测试，用于测试低级整体代码，以确保它们可用并按预期工作. 单元测试被认为是实施CI和CD的前提条件. （注解: 单元测试在许多语言和框架中得到了很好的支持）

本文内容不用于商业目的. 如果涉及知识产权问题，请联系薄伟峰（021-64471599-8017）的所有者，我们将立即处理.

【福利】填写问卷并发送选择的测试包+界面测试课程！为测试行业做些事！

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-219395-1.html