基于容器服务的持续集成与云端交付(五)- 探究持续交付系统的本质

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介:

换个角度看持续交付

在《基于容器服务的持续集成与云端交付》系列中,我们已经讨论了持续集成与持续交付给软件开发带来的变革,介绍了如何从零搭建一个持续交付系统以及在阿里云上面如何实现持续交付。

不过,在这篇文章中,我们会用一个不一样的角度来思考持续交付,到底持续交付给我们带来了什么,在容器的持续交付的场景中还缺少什么。回到本系列第一篇文章中的容器持续交付的流程图:


f694553ec98973d343ca89d2af7006ab222f8bc7

这张图中描述了一个基于容器的持续交付的流程,它定义了几个阶段,本地开发阶段、持续集成阶段、持续交付阶段等等,规定了在每个阶段中该做什么事情,开发人员、运维人员应该应该承担什么样的任务与责任。

从某种意义上来讲,持续交付不只只是一个技术问题,更多的是探究自动化软件标准化的交付流程的问题,通过技术的手段将软件开发、测试、集成、交付过程中的每个步骤进行标准化,然后再用一个灵活的流水线将不同的步骤串起来。

软件交付和汽车制造的原理是相似的,最早的汽车是纯手工打造的,产量低可靠性差。随着科技的发展,一辆汽车的零件可以由全球各地的公司制造,然后在一个可编程的流水线上快速的组装出来,现在组装一辆汽车只需要几分钟的时间,而这都得益于模块的标准化和可扩展的流水线。同样持续集成效果的好坏取决于标准化的程度与流水线的扩展能力:标准化程度越高、流水线扩展性越好持续交付的能力就越强。下面我们来讨论如何实现或者选择持续交付中的“标准化”与“流水线”

标准化与流水线

对于大多数的企业而言,通常情况下不会投入大量的精力来开发属于自己的持续交付系统,一般会选择开源的持续交付方案或者使用提供持续交付能力的SaaS服务,例如基于Jenkins的持续交付方案或者阿里云的CRP持续交付平台系统等等。

在Docker还没有兴起的时代,持续集成的方式通常是通过自动化配管工具来实现标准化的,比如Ansible的playbook、Chef的Cookbook等等,但是这些自动化配管工具更倾向于配置的管理与环境的初始化,换言之,自动化配管工具并不是面向交付的标准化而是更倾向于配置管理流程的标准化。

而Docker的兴起,给我们带来了交付流程标准化的可能性。当所有交付流程都变得标准化后,流水线(pipeline)则可以将不同的交付流程穿起来,实现持续交付的流程。

如何演进持续交付系统

1.制定合适自己业务形态的标准与流程

持续交付要符合自己的业务场景与形态,我们经常可以在社区中看到不同的持续集成的方案,但是,最开始要做是根据自己的业务形态来执行流程与标准。有了业务场景再去选择合适自己的持续集成方案。比如阿里云容器服务提供基于Hub的简单的持续集成方案,提供基于Jenkins的开源的持续集成方案也提供基于CRP的持续集成的方案。他们分别面向不同的场景、解决了不同的问题。先明确自己持续交付的场景与所需要的能力然后再选择不同的持续集成的方案。

2.选择一条合适的流水线或者流水线的默认实现

Docker已经帮我们解决了大部分交付流程中的标准化问题,那么选择一条适合的流水线则尤为重要,SaaS类的云服务通常情况会提供标准的流水线(pipeline)实现,但是相比而言,基于DSL的Jenkins的流水线(pipeline)是更为强大的选择。针对于不同的业务,开源的Jenkins流水线灵活的程度大于SaaS类的持续交付系统的流水线大于固定流程的流水线。

3.根据业务的需求不断的丰富流水线上的流程

在使用持续集成的过程中,我们会根据业务的形态的变化,不断的在流水线上添加或者删减持续交付的流程。当持续交付的流程被大家认可并遵守的时候,持续交付的能力就会真正的展现出来。通过类似模块化的插拔将不同的组件不同的流程融合在一起,不断的演进,满足不同维度的业务场景与方向。

尾声

还有什么是我们没有讨论的?其实Docker给我们带来的不只只是标准化的部分,还有更多的是职责划分的思考,从前从软件的开发到测试之前的部分是开发负责的,而从测试、上线、后期的线上运维都是运维的人员负责的。

不过,软件架构的变革例如微服务的兴起等等会导致运维变得越来困难,从前一个企业只有少量的“巨石”软件系统,运维人员只需要运维少量单一的技术框架的系统即可。但是,现在一个微服务系统可能有几十个模块,每个模块的运行时环境、运维方式都不尽相同,这给运维带来的难度是指数级增长的。

现在越来越多的人在讨论DevOps或者SRE,其实这并不是一个新的职业,更多的是对于开发与运维边界的重新定义。

个人觉得开发人员未来会更倾向于DevOps的方向发展,即开发人员中会有更细分的倾向,部分开发人员倾向于线上维护与组件调优而另一部分则侧重软件开发。

而运维人员会更倾向于平台化或者SRE化,运维人员会花费跟多的精力在自动化持续交付平台流程的建设与优化、基础设施的建设(监控、日志、扩容)等等。

持续集成与持续交付不仅是提速了交付的流程,更多的是优化了开发人员的职责划分与交付的方式。

个人简介

莫源,阿里云高级研发工程师。在加入阿里巴巴之前,先后在北京天方地圆科技有限公司、微软亚洲研究院任职。现主要负责阿里云容器服务产品的底层服务发现系统、集群管理系统的研发,从事容器的持续交付、持续集成的方案的设计与实现。在云计算、分布式系统、图像识别与虚拟现实方向有多年的开发经验。

相关实践学习
Docker镜像管理快速入门
本教程将介绍如何使用Docker构建镜像,并通过阿里云镜像服务分发到ECS服务器,运行该镜像。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
2月前
|
消息中间件 监控 NoSQL
容器化应用系统上生产的最佳实践
容器化应用系统上生产的最佳实践
|
3月前
|
存储 测试技术 持续交付
自动化测试与持续集成/持续交付(CI/CD):优化软件开发流程的利器
自动化测试与持续集成/持续交付(CI/CD)是现代软件开发中至关重要的环节,通过将自动化测试与持续集成/持续交付相结合,可以实现开发流程的高效优化,提高软件质量和交付速度。本文将探讨自动化测试与CI/CD的概念、原理及其在软件开发中的重要性,以及如何实施这些技术以提升团队的协作效率和软件交付质量。
55 1
|
21天前
|
数据采集 测试技术 API
ERP系统的数据迁移与集成指南
ERP系统的数据迁移与集成指南
23 0
|
27天前
|
运维 监控 Devops
构建高效自动化运维体系:基于容器技术的持续集成与持续部署实践
在数字化转型的浪潮中,企业的IT基础设施和软件交付模式正经历着深刻的变革。传统的运维方式已难以满足快速迭代、灵活扩展的现代业务需求。本文将探讨如何通过容器技术实现高效的自动化运维体系,重点分析持续集成(CI)与持续部署(CD)的实践方法及其对企业运维效率的影响。通过引入微服务架构、容器编排、DevOps文化等概念,我们旨在为读者提供一套全面的自动化运维解决方案,以支持业务的敏捷性和可扩展性。
|
2月前
|
Web App开发 前端开发 JavaScript
如何快速与呼叫中心系统CTI/API/SDK接口集成
由于呼叫中心系统涉及通信、CTI、终端设备、中继线路等技术与概念,从事信息管理系统、ERP、CRM、工单系统等的研发人员一般不是非常熟悉这部分技术,当需要提供具备呼叫中心能力的解决方案时,往往要用较多的时间来研究这些相对复杂的技术,对接过程比较长,开发调试有一定的阻力,基于此,我们提出一种更加简便高效的集成方法,可以零代码集成呼叫中心平台,实现项目快速上线。
如何快速与呼叫中心系统CTI/API/SDK接口集成
|
2月前
|
监控 数据可视化 测试技术
集成阿里云 RPA 与现有系统
随着企业对自动化和数字化转型的需求不断增长,阿里云 RPA(机器人流程自动化)技术成为了提升业务效率和减少人工操作的重要工具。本文将介绍如何集成阿里云 RPA 与现有系统,以实现更高效的业务流程自动化。
|
3月前
|
索引 容器
leetcode-6130:设计数字容器系统
leetcode-6130:设计数字容器系统
24 0
|
4月前
|
Java 调度 Docker
Docker【应用 01】Spring Boot 项目部署在Linux环境下的Docker容器内举例(任务调度系统 xxl-job 任务调度中心)(手动版)
Docker【应用 01】Spring Boot 项目部署在Linux环境下的Docker容器内举例(任务调度系统 xxl-job 任务调度中心)(手动版)
69 0
|
4月前
|
Ubuntu 应用服务中间件 nginx
Ubuntu系统重启自动启动Docker容器
Ubuntu系统重启自动启动Docker容器

相关产品

  • 容器计算服务