这是悟空的第 194 篇原创文章

官网：

你好，我是悟空。

忆往昔

记得我刚毕业那会，前公司就有先进的持续集成，当时那个项目是国外的项目，有多个国家的人合作，为了让多个异地团队能更好的合作，项目上一直在推进  DevOps 在公司的落地。

我所在的团队叫做 TeamBuild，主要做的事情包括打包、部署、自动化测试等等，那个时候 DevOps 在国内还不知名，很少有公司知道，后来国外刮起了一场 DevOps 的风，吹到了国内，就逐渐带动起来了。

记得团队主要做的事情如下：

• 用微软的 TFS 工具实现持续集成
• Powershell 自动化部署（我主要干这个，记得经常和领导加班到 3点）
• 微软 Azure 做持续交付
• 等等

现如今

现在所在的公司对 DevOps 并不看重，以至于很少有团队对 DevOps 很热心，但它其实是很有必要和价值的。

很多事情自己并不能决定，但是可以先通过自己的实践来为团队创造一点价值，如果有可能，还能推广到其他团队，前提是得自己先行！

这本书

最近写了几篇通过 Jenkins 来做持续集成和持续交付的文章，就顺便找了一本 Jenkins 的书来补充理论知识。

这本书的名字是：《Jenkins 2.x 实践指南》

本书大部分内容是讲如何通过 Jenkins pipeline 实现持续集成、持续交付的各个阶段：包括构建、测试、制品管理、部署等。

抛开技术本身，我觉得文中挺有意思的两个地方：

共鸣点一

我个人觉得打包部署是一件很繁琐的事情，也很容易出错，已经影响了个人和团队的工作效率。

文中从社会学的理论中找到提高软件工程生产力的理论基础。

下面是截取的文中内容：

软件工程的三要素：

劳动力：通常将软件开发工程师、测试工程师认为是劳动力。然而，当他们不在工作状态时，就不能称其为劳动力，只能称为劳动者。

劳动资料：严格意义来说，办公场所、座椅、生产工具等都被称为劳动资料。本书主要讨论的是生产工具。笔者从硬件、软件的角度对生产工具进行了分类。

劳动对象：不像制造汽车，在开发软件时，劳动对象则是看不见、摸不着的知识。笔者将软件工程中的知识分为业务知识和技术知识。

不论招到什么样的程序员，管理者都要关心的是，如何帮助劳动者达到最佳工作状态，以产出更多的劳动力。不在工作状态，就不能称之为劳动力，只能称为劳动者。也许，那些经常随意打断程序员的管理者需要反思一下了

共鸣点二

2013年，作者曾经在团队中全面推行Jenkins pipeline。作者遇到的最大问题并不是技术上的，而是团队中有决定权的人是否看清了pipeline带来的收益和成本，以及团队成员是否有时间、有意愿去学习。可能再过几年，当持续交付的概念变为软件行业的“常识”后，人们才会觉得写代码配置pipeline更简单。如果你的领导和同事愿意实践，那么恭喜你已经跨过了最艰难的一步。但是这并不意味着后面的路就会一帆风顺，可能还会遇到以下情况：

（1）团队中从来没有人实践过持续集成和持续交付。

（2）原来只需要关心开发的开发人员，突然要关心构建是否通过、关心运维了，会有一种“活比以前多了”的感觉。

（3）对保守的老员工是一种冲击，老员工的那种救火式的“个人英雄”会慢慢地被工程化所替代，老员工必须跟上发展的步伐。

推荐再看下这两本书：

《持续交付 2.0 - 业务引领的 DevOps 精要》，可在微信读书上看

《持续集成：软件质量改进和风险降低之道》，微信读书上还未上架。

如果你也对 DevOps 感兴趣，欢迎加我好友交流：passjava，备注：DevOps。