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

前言

随着微服务架构与容器虚拟化技术的发展，持续集成与持续交付的概念又重新回到了大家的视野，越来越多的公司开始使用持续集成的系统来解决频繁发布带来的质量问题；使用持续交付的工具来实现代码在不同环境上的自动部署。原本有些学院派乌托邦式的思想正被千千万万次的集成与部署证明着它应有的价值。那么究竟是因为什么让持续集成与持续交付这个已经不再年轻的软件开发与交付的思想重新焕发绽放迷人的光彩呢/p>

传统软件交付之殇

传统软件的开发与交付的周期都很漫长，一款普通的企业软件通常需要十几个开发人员，几个月的时间来完成，从需求的分析、系统的设计、编写测试用例、系统开发、单元测试、组装测试到交付调试。有条不紊的流程与规范像一辆绿皮火车下的枕木，稳定而可靠的保证整个系统缓慢的推进，每一次交付、升级，都需要提供基础的硬件、软件的环境、软件的代码、软件的文档与手册。还记得刚刚迈入软件开发行业的时候，跟随公司的服务团队，驻场交付产品，每一个驻场工程师都按照之前预演过好多遍的流程，对照着系统的部署手册，一步一步的组装硬件，安装软件，稍有差池，就要按照对应的应急预案进行回滚。开始的时候觉得交付像一个神圣的仪式，将用智慧和汗水构建成的软件交付给客户使用，是一种非常荣耀和值得骄傲的事情；后来越来越多次的产品交付让我深深的感觉每一次交付都像分娩一样痛苦，扪心自问是否有简单更舒畅的流程可以将软件交付给客户呢/p>

传统模式的反思与CI/CD概念的提出

在这张图中我们讲述了一个持续集成与持续交付的流程，从代码的提交、构建与编译、单元测试到部署环境、集成测试与发布。软件交付本身就是一件复杂的事情，不同的产品、不同的架构、不同的业务形态会导致持续集成与持续交付的实现上有非常大的不同。还记得很久以前流行一个关于哲学的笑话，当你问十个哲学家什么是哲学的时候，你会得到十一种答案，因为每个人都有对哲学不同的理解。对于持续交付也一样，Martin Fowler讲述了一个乌托邦式的软件开发与交付的模式-持续集成与持续交付，但是前辈只给了我们先进的思想，并没有给出默认的实现。不同的公司、不同的产品、不同的技术栈、不同的开发与部署形态决定了持续集成与持续交付注定是因人而异的，在大家不断摸索什么样的方式是持续集成与持续交付的最佳实践的过程中。有的人做少了，只实践了其中的一部分，导致基本的交付能力上有缺欠；有的人做多了，引入了更多复杂的流程，导致原本应该提速的交付流程，像穿着名牌高跟鞋参加跨栏一样，怎么也快不起来。

如果将上面的流程具象化一个LNMP(Linux、Nginx、MySQL、PHP)的例子，就变成了如下的过程。

如上图，我们将刚才的例子用Docker的方式进行推演，发现原本和编程框架或者环境耦合的部分现在通过Docker进行了标准化，这样不同语言不同框架不同业务场景的开发者就可以快速的时间自己的持续集成与持续交付了。

软件定义交付时代已到来/h2>

云计算的兴起，让越来越多的IT基础设施变成虚拟的、软件定义的，比如软件定义存储、软件定义 络等等。通过编程的方式可以将原本的IT基础设施进行创建、分配、管理，屏蔽掉了底层的硬件的异构。反过来看云端交付的场景，是否可以变成软件定义的。我们可以通过资源编排（例如阿里云的Ros或者AWS CloudFormation）定义基础的设施；可以通过Docker软件定义部署；云资源和容器化的应用都可以用API的方式来实现软件定义运维。

软件定义基础设施+软件定义部署+软件定义运维=软件定义交付个问题留给大家更多的思考。

阿里云容器服务是阿里云2015年12月推出的基于容器的CaaS产品，集成了阿里云OSS、ECS、SLB、SLS、VPC、RDS等多款IaaS云产品的能力。容器的交付方式虽然给交付带来了很多的便利，但是还远远不够，阿里云容器服务为微服务、持续交付提供了大量云交付的能力，可以让Docker的交付过程更顺畅。在下一篇文章中，我们将讨论下阿里云容器服务提供了什么样的功能特性满足大家的云端交付场景。

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树容器编排(生产环境 k8s)kubelet,kubectl,kubeadm三件套8582 人正在系统学习中