<b>说明：关于oops的写法，oops在英文中用在犯错了时发出“哎哟”声，刚开始提到devops，大家觉得是一个很先进的方式，可以提升开发和运维之间的效率，但是实践中，发现devops做的不恰当就会变成dev “oops”，也就是“做不好的devops就会被调侃为dev oops”，此为技术圈的黑幽默。</b>
在云栖大会开源专场，来自阿里云的高级开发工程师莫源为现场听众带来了题为《dev oops ? no , devops！》的分享。在分享中，莫源从持续交付之禅、持续交付系统jenkins以及derrick助力开发者轻松容器化三个方面由浅入深地讲述了devops是如何通过选择合适的工具降低等待和技术成本，提高企业自动化。
以下内容根据现场分享和幻灯片整理而成。
devops的趋势
devops越发被开发者所提及，尤其在与docker相关的领域，devops被认为是开发者快速部署的最佳实践。从2016年统计结果来看，74%的开发者已经开始使用devops，而这一数据在15年只有66%；企业界已有81%的企业已采用devops，而这一数据在15年只有70%。然而，统计数据表明62%的开发者在使用devops时需要他人指导；44%的开发者仍处于调研和测试devops的初级阶段。由此可见，devops是一种势不可挡的趋势，但同时也是“尸横遍野”的战场。
大家口中的devops
为了更好地了解devops，下面分别来看一下两个常见的最简化持续交付流程——传统应用的持续交付流程和容器化应用持续交付流程。
传统应用的持续交付流程是从代码开发提交代码到代码仓库；代码仓库触发构建后，由持续集成系统测试、预发并正式环境部署。
容器化应用持续交付流程如上图所示，相比于传统应用的持续交付流程，容器化应用在持续集成系统中新增了镜像构建与推送，之后再通过分发编排模板完成部署。
很多开发者从各类演讲或者社区中拿到上述类似的方案后就回到公司开始进行devops实践。然而，在企业实现过程中，devops的实施变得越加复杂，有的企业在实施devops时引入了新的架构、新的部署环境（paas、docker、serverless）；有的企业引入了新的工具链、新的流程以及新的“职位”。这新引入的一切给企业带来了更多生产运营的成本。但这并不是devops想要的结果！
devops不是让你成为全能忍者（既懂开发又懂运维，还能兼顾测试），而是消除“等待”与“浪费”。在传统的服务流开发模式中，从前期的需求分析、设计、实现、验证到后期的运维部署，每一个流程都是由不同的角色负责，例如产品经理负责需求分析和设计、开发工程师负责实现、验证是由测试工程师负责，而后期的维护是运维工程师的职责。因此，也就产生了“等待”与“浪费”，“等待”与“浪费”出现在项目流转过程中，不同角色交替职责时，比如说等待基础架构的设计、等待应用程序部署、等待其他团队的反馈，甚至有时需要等待漫长的审核流程。
那么devops是怎样消除这些“等待”造成的“浪费”呢？首先一点是消除不必要的流程；第二消除不必要的特性；第三消除不必要的人工；第四消除不必要的返工。
devops之禅
那么devops到底是怎么解决上述提到的等待和浪费呢？答案就是分而治之，将大的目标分成不同的、小的目标，每一个子类目标可以进行快速的设计、开发、测试和交付。利用分而治之分方式让每一个步骤可验证、可交付。先分而治之，让一个大的开发周期变成小的开发周期再进行快速开发是devops之禅，一味地追求自动化部署反而违背了持续交付的初心。
<b>devops热门的领域</b>
devops最近几年的热门领域主要是cloud native、microservices、docker和serverless，这四个领域经常和devops结合在一起。devops的本身并不是一个技术问题（而是业务问题），但是技术的变革需要devops来填平带来的技术成本。devops实现是一个适配器，封装了本地开发与远程交付之间的实现。
近年来，devops的工具链变得越发繁多和复杂。因此，选择适合企业业务的工具链尤为重要。传统应用和容器化应用交付的过程中，其核心都是持续集成服务器。换句话说，持续集成服务器是devops最重要的一环，是交付流程的发动机。在开源领域，持续集成服务器最为有名的是jenkins，也是最适合的持续集成产品。
<b>jenkins</b>
jenkins可以在非常多的场景中和其他的持续交付工具进行集成。
上图展现了jenkins的几大特性，首先jenkins具有非常强大的插件支持，目前大概有1000左右的插件可用；第二，可以与100多个devops工具无缝集合使用；第三，它还可以和devops的工具链集成；最后，它还可以和devops的pipeline集成，上图也给出了不同阶段下，jenkins可以集成的工具。
jenkins固然很好，但其也存在自身的问题。大家对jenkins1.0有所诟病，主要是jenkins1.0其老派的设计和功能。
而在今年新发布的jenkins2.0版本中，我们可以看到如下5个方面的更新：
（1） ui 更新，新版的ui界面如上图所示。
（2） pipeline as code (pausable,durable)
（3） servlet3.1 and websocket
（4） docker support in pipeline
（5） blue ocean beta
为了让开发者更好地使用jenkins，阿里云在在jenkins相关的领域做了一系列的增强：
（1）目前，阿里云提供一键部署jenkins及slaves的能力:
·提供go、java、python、php、node.js的slave镜像；
·基于docker-compose一键部署master与slave集群；
·基于容器服务的运行时管理，可以动态生成任务构建容器。
（2）提供更多针对阿里云环境的部署插件（容器服务）：
·阿里云容器服务插件。
（3）提供jenkins基于阿里云场景的devops方案（ecs、容器服务）：
·惠及云计算的能力，实现cloudops、containerops；
·蓝绿无宕机发布、弹性扩容应对尖峰流量等。
jenkins容器服务解决方案
阿里云结合云服务的管理能力、docker的标准化交付能力与jenkins的强大的插件系统与任务分发引擎，为开发者提供云原生的jenkins containerops解决方案。
devops改造例子
下面分享一个客户利用devops改造docker的真实案例。
该客户原来的结构分为本地开发、测试环境测试、集成环境、预发部署测试、线上部署、运维与报警。其中前两个过程是开发感知，中间两个过程是测试感知，最后两个过程是运维感知，而整体过程是由架构师感知。
当其进行devops改造之后，中间的步骤基本都采用自动化的方式，自动化整体设计是由架构师负责完善地。改造完成之后，devops节约了大量时间和成本，让架构师更多的感知架构的改造；让开发专注在本地的开发上；运维更专注于线上运维与部署。
基于docker的devops的难点从来不是如何搭建持续集成服务器，也不是如何通过容器管理平台进行运维。而是docker带来的学习成本（dockerfile是第一大门槛）。从四个角色来讲，运维工程师和架构师是不可能不感知docker的，那么我们是否可以让开发者尽量少的感知docker的存在？
答案是必须的——derrick！
derrick主要解决的就是让开发者专注本地开发，降低docker的学习成本；它通过独特的机制自动生成dockerfile，让开发者无感知docker的情况下在本地调试容器化的应用；此外，derrick现已支持node.js、python、java等多种语言，并将于近期开源，敬请期待。