网站建设模式有哪些内容,免费设计签名的软件,微信公众号图文模板免费下载,销售网站一、简介
CI / CD的采用改变了开发人员和测试人员如何发布软件。 最初是瀑布模型#xff0c;后来是敏捷开发#xff0c;现在是DevOps#xff0c;这是现代开发人员构建出色的产品的技术路线。随着DevOps的兴起#xff0c;出现了持续集成#xff08;Continuous Integration…一、简介
CI / CD的采用改变了开发人员和测试人员如何发布软件。 最初是瀑布模型后来是敏捷开发现在是DevOps这是现代开发人员构建出色的产品的技术路线。随着DevOps的兴起出现了持续集成Continuous Integration、持续交付Continuous Delivery 、持续部署Continuous Deployment 的新方法。传统的软件开发和交付方法正在迅速变得过时。从历史上看在敏捷时代大多数公司会每月每季度每两年甚至每年发布部署/发布软件。然而现在在DevOps时代每周每天甚至每天多次是常态。当SaaS正在占领世界时尤其如此您可以轻松地动态更新应用程序而无需强迫客户下载新组件。很多时候他们甚至都不会意识到正在发生变化。开发团队通过软件交付流水线Pipeline实现自动化以缩短交付周期大多数团队都有自动化流程来检查代码并部署到新环境。今天我们将介绍什么是CI / CD / CD以及现代软件公司如何使用工具将部署代码的流程自动化。
持续集成的重点是将各个开发人员的工作集合到一个代码仓库中。通常每天都要进行几次主要目的是尽早发现集成错误使团队更加紧密结合更好地协作。
持续交付的目的是最小化部署或释放过程中固有的摩擦。它的实现通常能够将构建部署的每个步骤自动化以便任何时刻能够安全地完成代码发布理想情况下。
持续部署是一种更高程度的自动化无论何时对代码进行重大更改都会自动进行构建/部署。
这些阶段中的每一个都是交付管道的一部分 。在Humble和Farley的书《持续交付可靠的软件版本中通过构建测试和部署自动化》解释“对软件的每次更改都会在发布过程中经历一个复杂的过程。该过程涉及构建软件然后通过多个测试和部署阶段进行这些构建。反过来这需要许多人之间的合作也许需要几个团队之间的合作。部署管道对此过程进行建模并且它在持续集成和发布管理工具中的实现使您能够在从版本控制转移到各种测试和部署以向用户发布时查看和控制每个更改的进度。” 软件交付流水线
二、持续集成CI
通过持续集成开发人员能够频繁将其代码集成到公共代码仓库的主分支中。开开发人员能够在任何时候多次向仓库提交作品而不是独立地开发每个功能模块并在开发周期结束时一一提交。
这里的一个重要想法是让开发人员更快更频繁地做到这一点从而降低集成成本。实际情况中开发人员在集成时经常会发现新代码和已有代码存在冲突。如果集成较早并更加频繁那么冲突将更容易解决且执行成本更低。当然还有一些权衡。此流程变更不提供任何额外的质量保证。实际上许多组织发现这种集成变得更加昂贵因为它们依赖于手动过程来确保新代码不会引入新的错误并且不会破坏现有代码。为了减少集成任务期间的摩擦持续集成依赖于测试套件和自动化测试执行。然而要认识到自动化测试和持续测试是完全不同的这一点很重要我们会在文章结尾处详细说明。
CI 的目标是将集成简化成一个简单、易于重复的日常开发任务这将有助于降低总体构建成本并在周期的早期发现缺陷。要想有效地使用 CI 必须转变开发团队的习惯要鼓励频繁迭代构建并且在发现 bug 的早期积极解决。
三、持续交付CD
实际上是 CI 的扩展其中软件交付流程进一步自动化以便随时轻松地部署到生成环境中。CD 集中依赖于部署流水线团队通过流水线自动化测试和部署过程。此流水线是一个自动化系统可以针对构建执行一组渐进的测试套件。CD 具有高度的自动化并且在一些云计算环境中也易于配置。在流水线的每个阶段如果构建无法通过关键测试会向团队发出警报。否则将继续进入下一个测试并在连续通过测试后自动进入下一个阶段。流水线的最后一个部分会将构建部署到和生产环境等效的环境中。这是一个整体的过程因为构建、部署和环境都是一起执行和测试的它能让构建在实际的生产环境可部署和可验证。
AWS上提供了现代CI / CD管道的可靠展示。亚马逊是云计算提供商之一提供令人印象深刻的CI / CD 管道环境并提供一个演练过程您可以从其中选择众多开发资源并将它们链接在一个易于配置且易于监控的管道中。 许多人认为持续交付的吸引力主要在于它自动化了从提交代码到仓库再到测试和发布产品过程的所有步骤。这是构建和测试过程细致的自动化但是如何发布以及发布什么仍然是需要人工操作持续部署可以改变这一点。
四、持续部署CD
持续部署扩展了持续交付以便软件构建在通过所有测试时自动部署。在这样的流程中不需要人为决定何时及如何投入生产环境。CI/CD 系统的最后一步将在构建后的组件/包退出流水线时自动部署。此类自动部署可以配置为快速向客户分发组件、功能模块或修复补丁并准确说明当前提供的内容。
采用持续部署的组织可以将新功能快速传递给用户得到用户对于新版本的快速反馈并且可以迅速处理任何明显的缺陷。用户对无用或者误解需求的功能的快速反馈有助于团队规划投入避免将精力集中于不容易产生回报的地方。随着 DevOps 的发展新的用来实现 CI/CD 流水线的自动化工具也在不断涌现。这些工具通常能与各种开发工具配合包括像 GitHub 这样的代码仓库和 Jira 这样的 bug 跟踪工具。此外随着 SaaS 这种交付方式变得更受欢迎许多工具都可以在现代开发人员运行应用程序的云环境中运行例如 GCP 和 AWS。最受欢迎的自动化工具是 Jenkins以前的 Hudson这是一个由数百名贡献者和商业公司 Cloudbees 支持的开源项目。Cloudbees 甚至聘请了 Jenkins 的创始人并提供了一些 Jenkins 培训项目和附加组件。除了开源项目之外还有一些更现代化的商业产品例如 CircleCICodeship 和 Shippable。这些产品各有优缺点我鼓励开发人员在开发流程中一一尝试它们以了解它们在您的环境中的工作方式以及它们如何与您的工具、云平台、容器系统等协作。
五、下一步是什么
一旦部署了现代化的 CI/CD 流水线您可能会意识到开发人员工作流程中的一些工具和流程也需要进行现代化改造。测试是一个要着重关注的领域如果您的部署频率是每天或者一天多次您的每次测试可能需要数小时甚至一晚上才能完成。mabl 正在使用机器学习解决这个问题。
原文来自https://dzone.com/articles/what-is-cicd
