从devops看自动化发布

本次分享的主题是从devops看自动化发布，自动化发布实际上是devops闭环的末端应用部署，实现应用部署的自动化听起来美好，但在背后与整个流程有着千丝万缕的关系，想弄明白就要从整体角度来理解。那么在自动化部署带来的便捷背后遵循着什么理念，或者说它构成了什么体系中的一环，接下来会为大家讲解。

被玩儿坏的敏捷开发——Agile：在介绍devops之前首先要说一种开发模式，那就是敏捷模型，敏捷开发这个词儿在我国已经被玩儿坏了，因为很多啥都不懂的无良老板命令员工去开发一个项目，只顾图快，然后就搬来了敏捷开发这个筐，啥啥都往里装，搞得就跟上了敏捷开发就真的能亩产万斤一样。那么真正的敏捷开发是什么样呢，比如我之前有一个项目就是敏捷开发，每天早晨会开一个晨会，讨论一下当前进度，看一下哪些需求还没做，一般会有一面墙，上面贴满了写着需求的小纸条，产品人员确定细化需求后与主要开发者确定需求体量，需求上墙后会分为undo、doing、test几个区域，当天完成的工作会提交到git上做一下集成，完成的需求会有测试人员提测，一般来说一个版本的需求发布周期为两个星期，从需求到开发到测试部署这样每个版本的间隔尽量缩短，类似于微积分，把巨量不规则的工作理出条理提高工作效率，这就是对敏捷开发的一个粗略描述。

那么为什么敏捷模型突然流行起来，为什么项目都用敏捷模型呢？随着技术的发展，软件开发周期越来越短，竞争对手应对市场需求越来越快，每个人都在图快，每个人都希望能够快速把握市场，在上层决策对开发需求起主导作用时，敏捷模型作为最好的选择才会突然流行起来。

刚才有一句话，就是随着技术的发展，究竟是什么技术在支撑着我们，让我们开发周期越来越短，应对市场需求也越来越灵活呢？敏捷模型实践的背后技术支撑正是一个叫做devops的理念，devops并不是什么工具，不是什么语言，也不是什么产品，它是一种哲学思想，也就是说当你遵循使用devops哲学思想之后，你就可以实现非常频繁快速的应用迭代和发布，devops可以理解成为沟通development和operations之间的桥梁。

Development指代的是开发环节，这里我们把产品和开发放在一起统称为development，他们的融合改造是通过敏捷模型实现的，那么devops则实现了开发和运维的融合，这个词也正是取用于此，是dev-ops的结合。

Devops至今没有一个权威的定义，搞得各家都有各家的说法，我提炼了一下它大概具有如下几个特性，一切自动化，缩短周期应对灵活需求，和沟通各环节。用一个图来描述devops，左边是dev，右边是ops，下面提供了一个反馈机制，其中穿插着精实，快速迭代，敏捷开发等思想，这些统称为devops，它也可以说是一种文化。

那么具体点儿来说，devops在我们身边有哪些看得见摸得着的东西呢？

比如说我们用的Windows系统，如果你加入到了Windows的内部预览计划的话你会发现三四天就有一个很大的更新，平常玩的游戏也是，三天一个小补丁；三天一个小补丁。这些产品如今能发布的这么快，这好像和我们传统软件工程是不一样的，比如我有个上海的哥们儿，他们公司使用的是瀑布模型，在他们公司里发布一次的成本很高：比如说他们产品现在要上线了，所有人要卡着时间点倒计时，所有的开发人员、运维人员、质量保证、架构师都齐聚一堂，大家一起加班到凌晨，可能这个软件要部署很多次，第一次部署发布大家会遇到很多问题，所有工程师要hotfix，架构师要不停诊断原因，这样跑需要不停打电话解释，所有人折腾到很晚，项目成功上线，看到所有用户涌进来，他们可以看到各个仪表上数值上涨，这个情景看起来很帅，但是不要忘记了，让这么多工程师加班一宿的成本是相当高的，也就是说，在传统软件工程中，一次发布的成本很高，在发布前所有人都要进行代码整合，重新进行测试，发布过程中所有人都要在场，参与诊断问题，在发布成功之后，所有人还要监视程序是否能够平稳运行下去，而敏捷我又提到了，它几星期就是一个周期，几星期就需要发布一次，如果每次发布成本像发射火箭这么高，我们就不可能每星期就发射一次火箭，而在devops理念中，每星期发射一次火箭则变成了可能。

一个理念，不一定对：为什么这么说呢，一个理念好理解，我们刚才解释了这么多，那么为什么说不一定对呢，我们来开一下脑洞，devops作为一个理念，一种文化，一套模式，可以说是我们当今这个时代孕育出来的一个产物，它符合我们现代社会快节奏的主旋律，它也慢慢变成了IT界的一个共识，也就是说它红了，但是任何事物都有一个生命周期，比如网红，早期网红凤姐，上电视上杂志，现在鲜有人提及，甚至连千万级别粉丝的微博都注销了，很难说是她娱乐了大众还是大众消费了她，我想表达的是，devops是建立在当代潮流基础上，如果社会风向变了，它也就不适用了。有一种可能是devops也会随着时代进步，但忒修斯之船悖论是它的归宿，就是说每次给这艘船更换一个部件，等所有部件都被陆续更换过一遍了它是不是还是原来那艘船？到时候devops还应不应该叫devops？

或者有另一种可能，看过三体的同学应该知道有一个技术爆炸的概念，我们远的不说，就拿手机举例子，上世纪末的大哥大BP机，到后来的诺基亚，再到后来的iPhone4，再看看现在我们手里的手机，只是短短30年从语音通话到现在面对面视频和百花齐放的APP，完成了如此巨大的变化，当然这也得益于网络技术的快速发展，从2G几K的上网速度到现在的4G+，再到即将迈入的5G边缘化计算物联网时代，不得不说我们正处于技术爆炸之中，但是此爆炸的余热正随着摩尔定律的失效而降温，而下一次爆炸正在酝酿，随时可能到来，那就是量子技术，量子计算机一旦发展起来，算力将远超现有架构的机器不知道多少倍，那会给我们现在熟悉的一切带来毁灭性的影响，例如现有的密码体系将不堪一击，密码只是通过数学概率保证安全性，高安全性的密码以现在的机器可能算几年都算不出来，而量子计算机可能瞬间就破解了，靠算力维持的比特币挖矿体系将在分分钟内把所有矿挖了出来，但区块链体系并不会崩溃而会进化，这个各位如果有兴趣可以单开一次分享讨论这个事儿。    

人工智能，现在是人工智障，如果算力上去了就真的有可能通过算法描述出来真正的AI，从各方面完全超越人类，搭配量子网络，承载更大数据量，更多形式的传输，到时可能只剩云计算了，我们没必要，也不需要在家放一台笨重的计算机，只需要有一个终端，比如谷歌的搭载Chrome OS的Chrome Book，它的设计理念就是数据完全存在网络上，而这台上网本就是一台硬件级别的浏览器，随时随地在任何一台Chrome Book上登陆你的账号，就能完整体验谷歌全家桶给带来的个性化服务，再比如微软公司的游戏模拟飞行2020，几乎完整还原了地球样貌，游戏容量超过70个PB，玩家不可能下载到本地计算机，只能联网加载所视区域的游戏内容，这就是云计算的未来，这也可以单开一个分享讲，那么我们会不会就像《阿凡达》里潘多拉星球一样，有一棵世界树，我们的头发连到树上就加入到了庞大的云中，我们就像《头号玩家》一样，完全进入到了另一个世界，身临其境。    

这样的生活是我们现在不可想象的，但十几二十年后完全有可能实现，到时候我们看这些可能就跟我们家里老人看智能手机一样，根本玩儿不转了。所以每次技术爆炸的间隔越来越短，每次带来的技术进步也越来越大，而量子我们只是应用其特性就能带来翻天覆地的变化，如果基础科学发展到完全弄明白量子技术是怎么回事了，那将会开启另一个时代了。所以在这种背景下，大家想想IT界还会是现在这种节奏吗，我们的devops还会存在吗？所以我们说它能一直对下去吗？将来它可能作为一个概念载入历史，但不可能属于将来，以前连计算机都没有，更不可能属于以前。Devops属于今天，不属于明天，更不属于昨天。

有点扯远了，说回来我们在传统发布过程中都是优先保证我们应用程序本身正常，例如我们需要去某某云买一台新的服务器，然后在服务器上安装数据库系统，部署我们的软件，安装Web服务器，把各种需要的参数都设置调节好，完成好数据库的播种，解决相关的问题，最后才能完成这次发布，如果发布完成后过了几天我们的程序挂了，出了点问题，我们第一反应都是服务器出问题了，我们只需要到服务器上去看看问题的日志，解决这个问题，保证服务器正常就可以了，这是传统软件工程的方法。但是在devops理念中，它有一个非常重要的观念就是一切部署发布都要实现自动化，所谓自动化是什么意思呢，就是说每一次发布我们都不在乎，服务器也不在乎，我们只在乎一件事，就是我们的代码和管道。

代码我们都理解，我们经常使用git来管理我们的代码，审查pull request合并代码，管理代码分支。管道又是什么呢，管道又叫流水线，这要说回敏捷模型，敏捷就是一个大的流水线，有反馈人员提交了反馈，进入开发人员的工作工单中，产品组成员按照优先级排好，开发组成员完成这些工单。但这里有一个细节，工单一旦完成，合并到了主分支中，发布是谁在做呢？并不是人在发布，而是流水线本身就有发布功能，而且流水线本身还有代码检查功能，优先保证代码和管道，就是要在每一次发布的时候是全自动的完成代码检查和自动部署，为了保证这一点，实际上背后有非常复杂的技术支撑，有PaaS层的云计算，有容器技术，有DSC期待配置方法，还有很多哲学思想，比如之前我们有大神讲解的Kubernetes管理docker就是其中一种。

我们说回这个图来解释流水线，流水线是一条管道而真正的功能是各功能组件去做的，流水线负责调用这些组件完成一个闭环的协调。最重要的为了保证代码的自动检查和自动部署，其中最核心的两个概念是Continuous Integration和Continuous Delivery，听到这你可能觉得很玄乎，什么。。。。。。我们暂且叫它CI和CD吧，简单来说，CI是保证你的代码每一次都能通过集成，CD是保证你的代码可以自动化部署，你可能还是觉得这是什么玩意儿？好玄乎儿啊！

在传统软件发布过程中，例如明天就要发布了，今天每个人各负责了几个模块，显然今天晚上我们要把所有人写的模块整合到一起，结果一整合的时候发现有问题，可能这个模块我写了一遍，他也写了一遍，我们一块写了两遍，而另一个模块谁都没写到；多带带编译每个模块都是0 error 0warning，结果整合到一起就发现几百个error几千个warning，这是传统软件工程中非常常见的一个现象，就是各组开发人员都完成了自己所需要的开发时，我们一般都把每个组开发的各个组件整合在一起，这个过程叫做集成，集成的过程中非常容易产生巨量的错误，我们称这种过程叫做集成地狱，之所以一次发布成本这么高，就是为了解决集成地狱中这些巨量的错误。

为什么CI可以解决它呢，CI是持续集成，也就是说我和我的同伙一起要写一个项目，可能我要写用户账户管理模块，同伙要写音乐管理模块，比如我们要写音乐商店的话。如果我们在临上线前一天再集成我们的软件，那么我们一定会GG，假如我们在开始写整个项目的第一天，就保证每个人写的每次一代码提交都能够让代码稳定运行起来，也就说每次一在使用git commit的时候，都会有一个自动化的工具，这个工具将对我们代码尝试进行整合，实质上工具一般都会运行你的编译和你的集成测试、单元测试等，一旦工具发现，任何一次commit无法让代码通过它的整合，工具就会拒绝本次代码修改，从而保证我们代码任何一个时间内都是干净的，这就是CI的核心思想，它能够将我们的事故在它最初将要发生的时候以最低的成本警告我们的每一个开发者，这样我们就能够在最早的时间内得知什么时候出现的故障，修正这些故障，从而保证我们整个集成流水线工作非常顺利，任何一个时刻，我们找任何一份代码，都可以完成我们的项目，而我们的代码则在变得越来越好。

CD又是什么呢，CD是Continuous Delivery持续交付，我们知道发布一次软件成本很高，CD就是自动化这个过程，对于任何一次通过CI的代码修改都会触发CD管道，CD将全自动的取出在CI过程中编译好的项目，部署到你的服务器里，可以简单理解为自动化发布正是CD的一个实现。

在我们完善配置了CI和CD实现了Devops哲学思想之后，服务器只不过是我们运行代码的一个终端而已，我们每天只维护好我们的代码，而代码是直接影响着我们的服务器的，假如我们服务器挂了的话，那唯一出现问题的地方就是我们的代码啊，我们把代码就要修正好，然后重新跑一遍CI和CD管道，触发自动部署，很快就有新的服务器回来了，而且新的服务器就不会遇到之前挂的这种问题，假如公司有了新的成员，他只需要直接对代码做贡献就可以了，他甚至连开发环境都不需要安装，而他所做的贡献一旦被CI检查通过，就会触发CD，CD的工作就是直接部署到全球的用户中，这样所有的用户很快第二天就会收到一个更新，他们安装更新后就会享受到新来的内个人做的最新的代码贡献，在devops理念中，实际上运维成本是非常低的，一般在运行CD管道的过程中，整个环境都会被重新创建，而你需要保留的数据则会仍然保留，伴随着devops的发展，我们软件工程流水线中成本越来越低，而云计算技术的进一步成熟，paas技术，saas技术的普及，又进一步普及了devops。在今天的IT中，开发者真的不需要在乎运维，他也并不需要手动的去买一台服务器在上面安装mysql，他只需要在乎好自己的业务逻辑，我写好自己的代码，而代码的检查和自动部署交付到每个用户手中，都由非常成熟的devops理念全自动化的完成好。

接下来简单介绍一下自动化发布的应用发布模块，应用发布分两套方案，一条是通过Web浏览器与系统交互，另一条则是为接入流水线准备的接口，在前期系统配置和脚本编写全部完成后，发布将变得十分简单。

在Web端的应用发布中，你需要建立一套发布模板，就是给每个步骤操作连起来形成一套编排，它描述的是一个整体的发布方案，里面包含了提前编写好的操作步骤。随后建立发布策略，发布策略则是一道桥梁，沟通了模板和计划，建立策略时要先选择对某个应用系统建立，建立的时候要选择绑定哪个模板。你可以建很多个策略，但只能有一个默认策略，该业务系统建立发布计划时，将使用默认策略绑定的模板进行发布。建立发布计划时只需要选择业务系统，然后填好版本号和计划时间，版本号是唯一的，计划时间则是计划建立完成通过审核后将自动执行的时间，上传文件部分支持本地上传和git链接上传。如果点击快速发布后则进入待执行状态，提交审核则会进入提审状态，有权限的账号可审核该计划，保存草稿则会保存到草稿标签中，为可编辑状态。

计划发布完成后点击完成的计划可以看到每个步骤的反馈结果，详情页中包含每一步操作执行的时间，执行输出的内容及执行结果，该结果可反馈流水线作为整个流程的闭环反馈。

END

更多精彩干货分享

点击下方名片关注

IT那活儿