星物语：部署流水线打通 DevOps 的任督二脉

星物语源自DevOps时代系列微信群（DevOps时代-水星群和火星群）的讨论精华，每周一期，记录属于我们自己的DevOps故事。

本周文章连连看

部署流水线小调查

部署流水线对企业DevOps转型的核心，我们在DevOps时代微信群做了个小调查，来看看大家的流水线做的如何：

一条流水线引发的讨论（精华）

本周发布了许峰老师又一力作，Capital One的DevOps转型案例，其中总结出真正的流水线需要具备的15个特性：

1. 版本控制

2. 最优的分支策略

3. 代码静态扫描

4. 80%以上的单元测试覆盖率

5. 漏洞（Vulnerability）扫描

6. 开源工具扫描

7. 制品（Artifact）版本控制

8. 环境自动创建

9. 不可变服务器（Immutable Server ）

10. 集成测试

11. 性能测试

12. 每次提交都触发：构建、部署和自动化测试

13. 自动化变更请求

14. 零停机发布

15. 功能开关

且看小伙伴们的讨论：

@许峻川：这个厉害了！

@李洋-互联网-北京： 代码静态扫描主要是做什么工作？

@龙井：代码静态扫描是指使用SonarQube这样的工具进行代码质量（规范）的扫描，并进行可视化，主要是扫描代码的七宗罪（重复率，复杂度，规范遵守等等）

@李洋-互联网-北京： 不可变服务器是什么意思？

@龙井：不可变服务器就是指不会对线上服务器（云主机、容器）进行变更，每次变更都是重启一个新的，docker天生就是不可变基础设施。AWS也支持这种方式进行部署（Netflix就是采用的这种方式）。核心的意图还是不希望不受控制的变更和蔓延。应用+配置+环境整体打包交付。

@李洋-互联网-北京：这个不可变就像你说的核心意图在于交付环境的标准化，服务器维度是不是也可以做到合理的管控，像openstack，只是相对于vm/容器之类的粒度大一些而已...

@龙井：OpenStack和AWS是一样的维度，部署的时候，部署系统不是将war包推到tomcat里，而是将一个经过验证的应用服务器（vm）替换现有的vm

Netflix的案例是采用的服务器的方式，只要服务器的启停，销毁很容易管理，我觉得是没问题。

@萧帮主：漏洞扫描看来很被忽视啊

@龙井：嗯，针对源码和制品的安全扫描会变得越来越重要的，可能目前安全能力主要集中在运维侧，还没有将安全内建到整个交付过程中

@李洋-互联网-北京：代码安全小公司容易忽视这点

@许峻川：从事安全行业的人员少，物以稀为贵

@龙井：这个案例里道出了两点挺有意思的内容：一类是从大事故中痛定思痛，另一类是从一个小问题反思，也许只有当大事故来临，才会重视。

@赵班长：在没有单元测试的前提下。自动化接口测试要覆盖至少80%以上

@Allan@Capgemini Testing：问个小问题 你们的build/deploy/test的脚本是否进pipe line管理？

@Rain：利用CI，自动化工具，开发-测试-部署-通知-运维（还没做到自动扩展）都是自动化及流水线化，每一步执行结果有记录，也有可视化，可测量可预测

Gitlab CI有很漂亮的图表

插件没有jenkins丰富，但对我们也够用了，开箱即用

DevOps时代社区的第一次直播

周二晚上，龙井同学给大家带来了《龙门阵之 DevOps 门外汉须知》的直播，差点儿就突破2500人次观看了，谢谢大家的捧场，尤其是打赏的各位老板！

《龙门阵》还会继续为大家带了更多DevOps分享，帮助大家学习，实践DevOps。

《龙门阵之DevOps门外汉须知》分享PPT，下载链接: https://pan.baidu.com/s/1i5ss6Gl 密码: dqzt

@石雪峰：听的入神了，媳妇都气的自己出去遛弯了，果然加入了一个邪教组织

@ wangxiankee：估计出去买了个榴莲回来

@视频有地方看嘛，昨晚加班没看着

直播回放：http://t.cn/RK2qT3x

水星+火星：双星汇聚

DevOps时代-水星群已经不够住了，我们开启了火星群，希望更多实践DevOps的小伙伴加入我们！也欢迎小伙伴们邀请朋友们加入组织。

来看看小伙伴们的反应：

@DEVOPS：感情还有四星了，金木火土

@龙井：五星连珠之日，就是DevOps落地之时

@黄威@新大陆-运维产品：集齐七颗星球，就可以召唤DevOps降落地球

@春秋花草风月醉：然后变超级赛亚人

DevOps团队与角色讨论

Capital One认为转型有三个关键中的关键：

1. 外包转向自建开发团队（外包公司要努力了）

2. 功能团队转成产品团队（一个产品团队就像一个多兵种的行动小组）

3. 不再区分Dev、Ops、QA、RM（Release Management），大家都在写代码，都是Engineer

来看同学们的讨论：

@Rain：不再区分Dev、Ops、QA、RM（Release  Management），大家都在写代码，都是Engineer。这样真的好吗？

@龙井：软件服务交付的链条上，大家都是同等重要的。但是创造价值的主要在开发活动，所以我们需要更多的自动化和协作，减少非增值的其他活动的时间，尤其是手工部署，手工测试。我理解可能有一些岗位会减少或消失，但是职能还是在的

@龙井：DevOps强调全功能团队，不用同职

@Allan@Capgemini Testing：代码也分很多种的 在全栈概念里 配置脚本 测试脚本 都是脚本，都是代码

郭老师的开源CMDB发布0.4版本了

@郭宏泽：这个平台是devops的一个产品化实践，欢迎感兴趣的同学参与

@ wingyiu：好像没有看到CI/CD

@郭宏泽：

CI CD确实还没，因为目前还是比较原始的阶段，软件从第一次提交github到现在不到三个月

软件的开发是要迭代的，devops的执行是要持续改善的。按规划1.0要一年后发布。到时会有比较完备的功能。

CI我不会做，但是会做接口和gitlab jenkins整合。

@Hunter：有没有简单的roadmap啊。郭老师

@郭宏泽：

CD，自动化，CMDB，监控，故障分析，关联处理将来是重点

Jenkins在界面上和操作逻辑上基本放弃治疗了，我将来会很重视界面和操作逻辑。

技术实践与组织文化的相互作用

技术实践和组织文化的作用与反作用，这个挺值得玩味的。

持续集成作为工程实践，对组织文化是有促进的，比如构建失败了，团队的人都知道是我搞坏了，我就会第一时间去修复。为了不破坏构建，我会尝试去使用内建质量的思路，在本地多做一些验证。也就需要接口级自动化测试和代码扫描的一些工程实践辅助我提高效率

招聘啦

@萧帮主：上海某大型股份制银行，求质量监控经理，薪资很不错，老板很nice

了解更多部署流水线的玩儿法，来DevOpsDays上海站吧

点击“阅读原文”，关注 DevOpsDays上海站