持续集成CI, 持续部署CD, 持续交付CD要点

在本指南中,您将了解持续集成的所有方面,它与持续部署和持续交付的关系以及如何开始使用这些实践。了解了它们之后,我们将详细讨论最佳实践和工作流程,并在最后提供完整的资源列表。

什么是持续集成?

持续集成(Continuous Integration)是一种开发实践,开发人员经常将代码集成到共享存储库中,最好每天进行几次。然后可以通过自动构建和自动测试来验证每个集成。尽管严格来说,自动化测试不是CI的一部分,但通常会暗示它。

定期集成的主要好处之一是,您可以快速检测到错误并更轻松地定位它们。由于引入的每个更改通常很小,因此可以快速查明引入缺陷的特定更改。

近年来,CI已成为软件开发的最佳实践,并遵循一系列关键原则。其中包括版本控制,构建自动化和自动化测试。

此外,持续部署和持续交付已成为最佳实践,可让您随时随地部署应用程序,甚至在每次引入新更改时甚至将主代码库自动推入生产环境。这使您的团队可以快速行动,同时保持可以自动检查的高质量标准。
在这里插入图片描述

持续集成并不能消除错误,但确实可以使查找和删除错误变得更加容易。
– ThoughtWorks首席科学家Martin Fowler

持续集成,持续部署和持续交付之间有什么区别?

持续集成 Continuous Integration

这种做法是将团队中不同开发人员的变更尽早集成到主线中,最好每天进行几次。这样可以确保各个开发人员处理的代码不会转移太多。当您将流程与自动化测试结合在一起时,持续集成可以使您的代码变得可靠。

持续部署 Continuous Deployment

与持续集成密切相关,是指使您的应用程序随时可部署,如果最新版本通过了所有自动化测试,甚至可以自动发布到测试或生产环境。

持续交付 Continuous Delivery

保持代码库随时可部署的做法。除了确保您的应用程序通过自动化测试外,它还必须具有将其投入生产所需的所有配置。然后,许多团队都会进行推送更改,以立即将自动化测试传递到测试或生产环境中,以确保快速的开发周期。

在这里插入图片描述
阅读有关该主题的更多信息:

第1部分:持续集成初学者指南

您应该集中精力尽早建立简单的 持续集成过程。但这不是结束的地方。尽管持续集成(CI)很重要,但这只是该过程的第一步。您还希望设置持续部署(CD),该流程可自动执行软件部署并让您专注于构建产品。

持续集成(CI)与持续部署(CD)

正如我们之前所指出的,持续部署与持续集成紧密相关,是指保持您的应用程序可随时部署,甚至在最新版本通过所有自动化测试后甚至自动发布到生产环境中。

如果您希望真正快速发布产品,则应该自动化整个工作流程,而不仅仅是测试。设计良好且运行顺利的持续部署(CD)解决方案将成为您使用的工具之间,尤其是SCM(源代码管理)提供商/服务器与所使用的托管环境之间的粘合剂。从一开始,他们就可以依靠完全自动化的流程来帮助新员工加入并发展团队。

在此处阅读有关该主题的更多信息: Jason Blanchard的“ Thoughtful:持续集成(CI)推广

什么是最好的持续集成和部署工具或服务?我该如何选择呢?

有很多解决方案。如果只想获取工具列表,则可以查看Codeship,TravisCI,SemaphoreCI,CircleCI,Jenkins,Bamboo,Teamcity或许多其他工具。在Quora上,您还可以找到有关该主题的许多文章和讨论,其中包含有价值的信息 。那里几乎有无限的机会。但是随后出现了一个问题:“如何在这些之间进行选择?”

您的选择将在很大程度上取决于:

托管与非托管解决方案

您必须做出的第一个决定是要托管的软件即服务(SaaS)解决方案还是自托管的解决方案。

如果您喜欢自托管解决方案,则需要管理自己的服务器。SaaS解决方案不需要这样做,但是如果您需要一些边缘保护功能,它可能会受到更大的限制。如果您碰巧使用GitHub,Bitbucket,Heroku或其他云服务,那么您很可能需要SaaS解决方案,因为它适合您现有的工作流程。

如果数据安全性非常重要,那么自托管服务器可能是您更好的选择。SaaS解决方案通常 使您可以将更多的精力放在核心产品上,因为您不必花费时间来维护基础结构并更新所有依赖项,而无需付出一些灵活性。

测试开源软件与专有软件

如果您有开源项目,则可以使用任一解决方案对其进行测试。可以是托管主机,也可以是非托管主机。他们两个都有优点和缺点。如前所述,托管(SaaS)解决方案不需要维护您身边的服务器,从而为您的产品工作/编码留出了更多时间。

绝大多数SaaS解决方案都遵循GitHub模型,您可以免费测试开源项目。一些开源项目确实需要对构建基础结构进行大量控制,尽管它们可能正在测试无法在托管解决方案中访问的操作系统的各个部分。在这种情况下,尽管增加了必要的维护开销,但任何现有的开放源CI服务器都应该做得很好。

持续集成和部署的优点和优势

持续集成有很多好处。良好的CI设置可以加快您的工作流程,并鼓励团队推动所有更改,而不必担心会破坏任何内容。它不仅具有更好的软件发行流程,还拥有更多的好处。持续集成也带来了巨大的业务收益。

降低风险

如果您更频繁地测试和部署代码,最终可以降低您正在从事的项目的风险级别,因为您可以更早地检测到错误和代码缺陷。这意味着它们更易于修复,您可以更快地对其进行修复,从而使它们的修复成本更低。正如Intercom的Darragh Curran在本文中所提到的那样,这将加快反馈机制并使您的沟通更加顺畅: 运输是您公司的心跳

更好的沟通

当您拥有已插入持续交付工作流程中的CI流程时,可以轻松地定期共享您的代码。此代码共享有助于在团队成员之间实现更大的可见性和协作。最终,由于每个人总是在同一页面上,因此这提高了组织内部的通信速度和效率。

更快的迭代

当您经常发布代码时,生产中的应用程序与开发人员正在开发的应用程序之间的差距将大大缩小。您对如何开发功能的想法很可能会改变。由于将自动测试每个小的更改,并且整个团队都可以知道这些更改,因此在开发新功能时,您将希望处理小的增量更改。这样可以减少假设,因为您可以更快地构建功能并自动测试和部署功能,以供用户尽快查看,从而更快地从中获取有价值的反馈。

更快地反馈业务决策

拥有配置项流程不仅对软件开发人员有利,而且对他们的经理也有利。双方都可以收集有价值的反馈并更快地获得见解。随着您更频繁地推送代码,您将拥有更多可用数据,可以对这些数据进行分析以检查产品是否朝着正确的方向发展。这种连续的数据流和度量标准的时间表(如依赖性, 单元测试,复杂性和 代码气味)也可以帮助更频繁地反映项目的进度,从而可以更快地做出技术和业务决策。

使用CI和CD的其他一些好处

  • 减少开发和部署过程的开销
  • 减少集成不同代码更改的时间和精力
  • 对每个更改启用快速反馈机制
  • 可以及早发现并预防缺陷
  • 帮助团队成员之间的协作,因此始终共享最新代码
  • 减少手动测试工作
  • 逐步构建功能可以节省调试时间,因此您可以专注于添加功能
  • 迈向完全自动化整个发布过程的第一步
  • 定期整合以防止不同分支机构出现分歧
  • 如果您要使用的功能长期运行,则可以持续集成,但请使用功能标志阻止发布。
    在此处阅读有关该主题的更多信息:持续集成的好处 Joe Green

第2部分:深入了解持续集成和持续交付

如果您对持续集成教程和最佳实践感兴趣, 建议您阅读下面提到的一些工程博客。您可以在那里找到非常有用的内容。

自2006年以来,CI和CD的格局正在迅速变化和塑造。不过,值得一提的是Martin Fowler的《持续集成》的原始 原理。Martin解释了最佳实践工作流程:

  1. 维护代码库
  2. 自动化构建
  3. 使您的构建自测
  4. 团队中每个人的每日承诺达到基线
  5. 每次提交(到基线)都应该构建
  6. 保持快速构建
  7. 克隆生产环境并在那里进行测试
  8. 轻松获取最新交付物
  9. 中的每个人都可以看到您最新构建的结果
  10. 自动化构建部署

业界一直在做得很好,以使这一点得以实现,软件团队在很大程度上能够遵循这些原则。随着容器出现,现在克隆本地和生产环境并在那里进行测试变得容易得多。Codeship的新Docker平台将为您提供更多的帮助。随时 在这里了解更多信息

连续交付清单

Martin Fowler的原则是考虑最佳设置软件开发过程的一个很好的起点。Jez Humble和David Farley在他们的《持续交付:通过构建,测试和部署自动化的可靠软件版本》一书中也指出,当您要提交代码时,以下列表应该是概述和清单。

  1. 提交更改之前,请检查构建当前是否处于“成功”状态。如果没有,您应该在提交新代码之前协助修复构建。
  2. 如果状态当前为“成功”,则应将个人工作空间重新配置为该配置。
  3. 在本地进行构建和测试,以确保更新不会破坏功能。
  4. 如果成功,请签入新代码。
  5. 允许配置项完成新的更改。
  6. 如果构建 失败,请 停止修复您的计算机。返回步骤3。
  7. 如果构建 通过,请 继续处理下一项。

您应该注意,这只是一个概述。您会发现许多不遵循这些确切步骤的服务和解决方案(例如步骤2)。但是,最好知道这些步骤。为什么?

因为许多开发人员(根据DZone 2014年的研究,高达41%)认为他们正在实现持续交付,而实际上只有不到10%的人实现了。(该调查是针对500多名IT专业人员进行的。大部分受访者是开发人员(68%)或团队经理(14%),而业务,质量保证和执行管理人员所占比例较小。大多数受访者的总部位于美国(36%)或欧洲(43%)。

这些人中只有不到10%的人从事连续交付工作。让这一切沉浸其中。这就是提醒我们不断逼近真正的持续交付的好原因之一 。一份好的清单肯定有助于建立正确的流程,并向您的团队以及潜在的管理人员进行解释。

这就是研究背后的公司DZone编制清单的原因之一。在“ 持续交付成熟度检查清单”中,您可以实际检查当前执行的实践,以了解您在“持续交付”的每个区域中的成熟程度。您在测试中获得的分数越高,您越接近CD成熟度。该清单不仅在编写代码时遵循,而且还可以帮助您确定公司CD流程中的弱点和需要改进的地方。CD过程的主要领域包括:

  • 源代码控制
  • 建立过程
  • 测试与问答
  • 部署方式
  • 能见度

您可以在此处下载他们的 清单

克里斯·沙扬(Chris Shayan)在此处撰写有关持续交付成熟度矩阵的文章时,介绍了您可能希望了解的该过程的早期版本 。
在这里插入图片描述
阅读有关该主题的更多信息:

如何开始连续交付

如果您想知道如何开始使用持续交付,我们的CTO Florian Motlik在Amazon Web Services Blog上发表的这篇文章将非常有帮助,阅读: 持续交付入门的五个技巧

如果您准备进行持续集成和交付,请立即尝试您的项目,立即注册一个免费的Codeship帐户!只需通过您的GitHub,BitBucket或GitLab帐户登录。

持续集成资源

我们已编制了一份资源清单,供您开始使用“持续集成和交付”,如果您对本主题的了解更多,则可以进行更深入的研究。您绝对应该查看我们的Codeship资源库 ,在这里可以找到免费的电子书,视频和指南。

图书

博客和网站

参考

https://codeship.com/continuous-integration-essentials

http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html

https://martinfowler.com/articles/continuousIntegration.html

发布了167 篇原创文章 · 获赞 17 · 访问量 3万+

猜你喜欢

转载自blog.csdn.net/zgpeace/article/details/105347389
今日推荐