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

换个角度看持续交付

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

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

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

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

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

标准化与流水线

对于大多数的企业而言,通常情况下不会投入大量的精力来开发属于自己的持续交付系统,一般会选择开源的持续交付方案或者使用提供持续交付能力的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化,运维人员会花费跟多的精力在自动化持续交付平台流程的建设与优化、基础设施的建设(监控、日志、扩容)等等。

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

个人简介

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

时间: 2024-10-29 23:50:46

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

基于容器服务的持续集成与云端交付(二)- 多维度打磨交付能力

前言 在上一篇中,和大家一起讨论了传统软件交付的问题.持续交付的难点.以及为什么云端的容器交付可以协助大家快速的持续交付. 但是当真正的将一个系统通过云端容器交付的时候会发现不能单纯的将Docker作为一种交付工具来对待,更多的时候是作为一个交付平台的基础设施来看待,还需要关心的是使用Docker后网络.存储.安全.性能.监控等等不同方面带来的变革. 因为交付的本质是将一套复杂的软件系统从零到一完成开发.测试.部署.上线的过程,软件的复杂度直接关系到了交付的难度,特别是现在微服务的架构方式越来越

基于容器服务的持续集成与云端交付(一)- 交付之禅

前言 随着微服务架构与容器虚拟化技术的发展,持续集成与持续交付的概念又重新回到了大家的视野,越来越多的公司开始使用持续集成的系统来解决频繁发布带来的质量问题:使用持续交付的工具来实现代码在不同环境上的自动部署.原本有些学院派乌托邦式的思想正被千千万万次的集成与部署证明着它应有的价值.那么究竟是因为什么让持续集成与持续交付这个已经不再年轻的软件开发与交付的思想重新焕发绽放迷人的光彩呢? 传统软件交付之殇 传统软件的开发与交付的周期都很漫长,一款普通的企业软件通常需要十几个开发人员,几个月的时间来完

基于容器服务的持续集成与云端交付(四)- 多种发布方式

前言 哲学有各种各样的流派,百家争鸣,但是只有一个哲学问题是严肃的,那就是生与死.而云端交付过程中也只有三个问题是严肃的. 如何重建你的系统 How to recreate your system? 如何安全地部署你的系统 How to safely change your system? 部署后的问题监控与解决 When something has gone wrong? 在前面的文章中,我们讲述了什么是云端交付,如何搭建从零搭建一个持续交付系统,而今天我们要谈的是如何安全的部署你的系统,部署

基于容器服务的持续集成与云端交付(三)- 从零搭建持续交付系统

前言 在上一篇文章中讨论了容器服务提供的交付能力,在本文中我们将讨论如何从零搭建一个持续交付系统. 对于大多数公司而言,选择一个合适自己的持续交付系统是尤为重要的一件事情,不同的公司.不同的业务使用的场景也各不相同,因此要根据自己的业务场景与发展方向来选择合适的方案.根据不同的业务场景与交付方式,阿里云容器服务提供了三种不同的持续交付方案. 基于Jenkins的持续交付方案 基于Jenkins的持续集成和持续交付方案是所有方案中最灵活.能力最强的方式,但也是需要客户自主运维的方案.对于现有提供持

使用阿里云容器服务Jenkins实现持续集成和Docker镜像构建(updated on 2017.3.3)

持续集成作为敏捷开发重要的一步,其目的在于让产品快速迭代的同时,尽可能保持高质量.每一次代码更新,都要通过自动化测试来检测代码和功能的正确性,只有通过自动测试的代码才能进行后续的交付和部署.本文主要介绍如何将时下最流行的持续集成工具之一的Jenkins结合阿里云容器服务,实现自动测试和镜像构建推送. 接下来的演示是如何通过阿里云容器服务Jenkins实现自动测试和Docker镜像构建,实现高质量的持续集成.具体场景:每次代码提交到GitHub上的nodejs的项目中,阿里云容器服务Jenkins

微服务的持续集成,四步“构建”一个代码世界

本文讲的是微服务的持续集成,四步"构建"一个代码世界,大师Martin Fowler对持续集成是这样定义的:持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成.每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误. 今天我们就来聊一聊微服务的持续集成. 目录 一.持续集成之构建 二.持续集成之部署 三.持续集成之测试 四.持续集成之发布 五.总结 一.持续集成之构建 当微服务产生

基于 Jenkins 快速搭建持续集成环境

持续集成是一种软件开发实践,对于提高软件开发效率并保障软件开发质量提供了理论基础.Jenkins 是一个开源软件项目,旨在提供一个开放易用的软件平台,使持续集成变成可能.本文正是从持续集成的基本概念入手,通过具体实例,介绍了如何基于 Jenkins 快速搭建持续集成环境. 持续集成概述 什么是持续集成 随着软件开发复杂度的不断提高,团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题.尤其是近些年来,敏捷(Agile) 在软件工程领域越来越红火,如何能再不断变

Docker在云平台上的最佳实践: 当容器服务遇到深度学习

12月9日云栖计算之旅线下沙龙第2期<Docker在云平台上的最佳实践>,阿里云技术专家必嘫给大家带来了"当容器服务遇到了深度学习"的演讲.本文主要从深度学习的兴起开始谈起,进而介绍了Docker技术.阿里云容器服务,重点介绍了支持云上的高性能计算应用需要哪些,包括GPU的调度.隔离和监控. 视频回顾 深度学习 人工智能已经进入了深度学习时代.传统的让机器自动化的方式已经不再适合解决一些问题,机器学习开始兴起,让机器像小孩子一样自己去认识世界.而深度学习本身是机器学习的一个

Jenkins与Docker的持续集成实践

本文讲的是Jenkins与Docker的持续集成实践[编者的话]持续集成(CI/CD)是一种软件开发实践.用于帮助团队成员频繁.快速的集成,测试他们的工作成果,以尽快发现集成错误. 更频繁.更早的集成意味着更早的发现问题.通过持续集成,及时发现和解决代码故障,提高代码质量,减少故障处理成本等等. [3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站]本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览:持续集成系统介绍:客户端与服务端的