背景 在大型企业内部，网络通常会被划分成多个不能直接访问的区域。比如本例中，网络被分成了内网和DMZ两个区域。出于安全的考虑，内网的机器不能直接访问外网。内网访问 DMZ 的机器、DMZ的机器要访问外网都需要单独提流程。 但是，我们的应用能部署到 DMZ 区域中吗？答案是技术上不是问题，但是管理上不允许这样做。 所以，在这样的大型企业内部，应用都会部署到内网中（本例中的A、B、C、D）。 可是，总会有一些应用需要发 HTTP 请求到外网。比如实施DevOps平时，我们的应用需要从外网拉取依赖。 这时，怎么办呢？本文就是为解决此问题而写。 解决方案 最后的解决方案如下： Privoxy 是一个HTTP 协议过滤代理。 Squid 是HTTP代理服务器软件。Squid用途广泛，可以作为缓存服务器，可以过滤流量帮助网络安全，也可以作为代理服务器链中的一环，向上级代理转发数据或直接连接互联网。 说实话，光看介绍，笔者一开始也一头雾水。不过，看完本文就应该知道它们的作用了。 以下是方案具体实施步骤： 在应用机器上设置全局环境变量： export http_proxy=http://192.168.1.100:3126 export https_proxy=http://192.168.1.100:3126 这一步的作用是将本机的 http 流量都代理到 192.168.1.100 的 3126 端口 在 192.168.1.100 上安装 Privoxy。它的作用是根据配置，决定流量走哪个网络。本例中，它的作用是我们指定的http请求，走到 dmz。而其它的则和原来一样。它的配置如下： cat /etc/privoxy/config listen-address 192.168.1.100:3126 forward .abc.com/ 192.168.42.12:3127 listen-address 指 Privoxy 监听的IP和端口 forward 指接收到符合域名规则（.abc.com）的请求，将转发给 192.168.42.12 的 3127 端口。 到此，得到的效果就是当在应用机器访问 abc.com,admin.abc.com 等时，这些流量都会被 Privoxy 转发到 192.168.42.12 的 3127 端口。其它 HTTP 请求则不会。 而 192.168.42.12 则是安装了 Squid 实现 HTTP 代理的机器的 IP。 ...

滚滚长江东逝水，浪花淘尽英雄。是非成败转头空。青山依旧在，几度夕阳红。—— 《临江仙》 电脑店 从前，有一家电脑店。原来你即是老板，又是店员时，拿到清单，你就必须亲自动手采购，然后一个个零件组装。每天都做着即重复又辛苦的活。 虽说你的组装技术已经很娴熟了，但是偶尔还发生装错的情况（大概是那天和老板娘吵架了），把一个客人要求的 CPU i5 装成了 CPU i7。结果是你亏本或者赚得少了。 后来，你采购了一个自动组装电脑的机器人。你只要告诉它电脑的配置，并把零件放到指定的箱子中。接着启动这台机器，它就自动帮你组装好电脑了。它每天都干重复的活也不会叫辛苦。 最重要的是准确，它不会因为心情不好，而装错。因为它根本不会闹情绪。 这样，老板就可以从重复的工作解放出来。然后将多出来的时间花在与人的沟通上，为有不同需求的人设计更合适的电脑配置清单。毕竟游戏发烧友和办公小白领的需求是不一样的。 在运维领域，不少运维人都干着即是老板又是店员的工作。如果在运维领域也能有这样的“机器人”该多好。事实上，Ansible、Puppet、Check 就是这样的机器人。 为什么要从零设计一个运维机器人 本文并不想生硬地罗列 Ansible 的各个知识点。因为那样，大家不如直接看 Ansible 官方文档就好。 笔者采用从零设计一个运维机器人的方式来告诉你，为什么 Ansible 会是现在这个样子。当然，现实中的 Ansible 不会像本文所写的那样一步步设计。 为什么要这样呢？因为笔者觉得只有知道一个工具背后的设计原理，真正用这个工具才会得心应手。 运维机器人的最终模样 首先，需要确定一下实现这个运维机器人的目的是什么。我们并不是希望所有的运维工作都交给运维机器人，而是希望运维工作中重复的那部分尽可能的交给机器人，把创造性的工作全部交给人。如下图所示。 以终为始是一种非常有效的实现目标的思考模型。根据此思考模型，我们首先必须探讨运维机器人的最终模样。然后，再讨论可能的解决方案。 那么，什么样的运维机器人能帮助我们实现上述的自动化运维目标呢？想像一下。是不是只要我们对着运维机器人说一句：“我要部署一个 Nginx 到 192.168.12.11”。它就可以帮我们完成了？ 但是它怎么知道如何连接到 192.168.12.11 呢？是使用用户名密码的方式，还是使用私钥？它又怎么知道 Nginx 需要什么样的配置呢？一问下来，其实，语音运维只适用于启动一些预定义的动作。就像汽车的一键启动。你不可能使用语音来对 Nginx 进行大量的配置。 而纯文本才是进行大量配置的最好媒介。 所以，运维机器人的最终模样是：我们将部署的主机 IP、登录方式、Nginx 的配置放在一个文本文件中，然后运维机器人读取这个文本文件，然后根据配置进行部署。如果部署的是业务系统，我们还需要准备该业务系统的二进制包。如下图所示。 那么，我们在文本文件中使用何种语言描述我们的配置需求呢？可以分成两种。一种是利于人类学习的自然语言（如英语）。另一种是利于机器读取的结构化数据（如YAML、JSON）。 按当前的技术实现的可能性，不论是运维机器人，还是交给其它程序，都需要将自然语言转到结构化的数据。就像程序员，需要将业务知识翻译成编程语言；像编译器将编程语言翻译成机器真正能识别的二进制代码。 运维机器人的真正核心不是将自然语言转成结构化的数据。所以，文本文件中，我们直接写结构化数据。同时，我们决定使用 YAML 格式作为结构化数据的载体。因为它是非常流行的配置文件格式。降低人们写结构化数据的难度。 当然，好的设计不应该与具体配置文件格式耦合。 实现运维机器人要解决哪些问题 以上只是确定了运维机器人的最终模样及使用方式，解决的是用户的问题。但是因为我们是运维机器人的设计者，我们必须考虑如何实现它。 回想一下，平时我们的运维人员是如何实现自动化的？是不是写好了 bash 脚本后，然后将脚本上传到目标机器，最后在目标机器上执行该脚本。 这个 bash 脚本其实也可以算是一种结构化的数据格式，而且是一种不需要再做编译，目标机器能直接运行的格式。 在平时的自动化方式基础上进行抽象。我们觉得要实现运维机器人要解决的关键问题有： 需要将 YAML 转成目标机器可执行的程序（或脚本）。 需要将可执行的程序上传到目标机器，并执行。 为什么一定要将 YAML 转成目标机器可执行的程序呢？直接写 bash 不就可以了？ ...

注：Dao 在不同语言中的叫法可能不一样。Dao 可以理解为对数据进行持久化的具体实现。 关于实体的保存，笔者知道行业内有两种方式： dogDao.save(dog); dog.save(); 相信不少同学，现实中，通常使用第一种，很少见到第二种写法。 为了让大家站在同一个讨论上下文，笔者决定贴出更详细的代码。 注：以下代码会省略很多本文不相关的代码，比如数据校验。读者朋友不必太纠结。 第一种写法：save 方法写在 Dao 上 Dog dog = new Dog() dog.setName('didi'); dog.setColor('white'); dogDao.save(dog); 第二种写法：save 方法写在实体上 // DogService.java Dog dog = new Dog() dog.setName('didi'); dog.setColor('white'); dog.save(); 这两种写法，有什么区别吗？事实上，从字面上看，没有什么区别。因为 Dog 类的 save() 方法是这样实现： // Dog.java public void save(){ dogDao.save(this); } 但是从抽象的角度来看，就不一样了。 假如你的项目中存在这样的抽象： 如果采用第一种写法，意味着，每多出多一种 Animal，我们就必须多写一套 Service。Service 中会很多这样的方法： // DogService.java void save(Dog dog){ dogDao.save(dog); } // FishService.java void save(Fish fish){ fishDao.save(fish); } // BirdService.java void save(Bird bird){ birdDao.save(bird); } 相信大家对于以上代码并不陌生。 ...

当电梯到的时候，一只大土狗也跟着我进了电梯。我按了7楼。大狗依然张开嘴吐着舌头，站在原地。电梯直达7楼，我不知道大土狗要去几楼，所以没帮它按。走出电梯后，电梯理所当然的关门，然后向下了。它还在电梯里。 一天，我们一家人挤进电梯下楼。电梯有一股恶臭。儿子叫了一声：大黄。这时，我才注意到拥挤的电梯里，大土狗在角落里。看样子，它也是要下楼。 后来，从我老婆那里了解到。她经常看到这只大土狗，所以和儿子给它起了一个名字：大黄。因为它的毛是黄色的。 而狗的主人就住在11楼。只不过，现在主人不要它了。它现在每天就睡在前主人的11楼的门外。饭点的时候，就会看到它端端正正的坐在餐桌不远处，目不转睛地看着吃饭的人。偶尔会有好心丢给吃的给它。 当听到这些时，就酸了鼻子，两眼湿润。 再后来，当我和大黄坐电梯时，都会帮它按下11楼。 某一天，在楼下的操场边上，看到大黄兴奋地围在一年轻人的身边疯跑。看得出来，年轻人是它的前主人。只是当年的主人已经不是它的主人。年轻人直视前方冷漠地自走自的，仿佛大黄不存在一样。 而我身为旁观者，本来想说点什么，最后，也只能路过。

前段时间，项目实施人员告诉我，我写的 Ansible 脚本中有一处写死了版本号。并把代码截图给我看。我一看，这代码是老版本了。他代码应该没有更新。我这么跟他说。 然后他说出了一句出乎我意料的话：我们不是研发，不会天天去关注代码。 最后，我回了一句：要想自动化，就必须关注代码。屏幕背后的我，露出无奈与惋惜的表情。 惋惜的不是他有没有关注代码这件事情。而是他使用职位来限制住自己的能力。 不要笑话上面的同事，工作中不少这样的事情： 我是测试，那是研发的事情。 我是研发，那是运维人员的事情。 我是设计人员，不是研发。 前段时间，听另一个项目组的同事说：两周一迭代，前一周测试闲死，后一周开发闲死。 当时，我问了两个问题： 在后一周的时候，开发在干嘛？ 在后一周的时候，产品经理在干嘛？ 开发与产品经理都不是很忙的情况，为什么他们不可以参与测试呢？如果问他们，得到的回答可能是：因为那是测试的事情。 后来，我仔细想，那是XXX的事情，其实也不能完全怪他们。因为现实中，如果线上出现测试不到位的Bug，测试人员很可能会被 KPI。 最后，我才恍然大悟：那是XXX的事情的思维方式并不是员工原本的思维方式，而是这个管理制度下的结果。

本月在公司内部做了一次 Ansible 的入门工作坊。本文即对这次工作坊的设计过程进行一次总结。其他技术类的工作坊也可以参考。 设计过程大概过程如下文所述。 首先，我们需要确定参加本次工作坊的受众。他们是否具有最基本的前提。本次工作坊的受众有开发、测试、运维，还有毕业生。但是他们都会使用 shell。这已经满足最基本的前提。同时，了解受众后了，也就可以因材施教。 第二，分析工作坊的内容。Ansible 是一款上手非常容易的自动化运维工具。它的特点就是实操性非常强，不需要理解 Ansible 背后的概念就可以使用的工具。 笔者根据受众和教学内容的特点，得出本次工作坊的目标（教学目标）： 知道 Ansible 是什么，并知道它的作用。 了解如何查文档。 能部署一个 Spring Boot 应用。 是不是很简单？其实不然。整个工作坊没有一个人能完成所有的任务。同时发现有运维和开发基础的同学会做得更快。 那接下来怎么实现这个目标呢？笔者使用的是任务驱动的方法。也就是受众通过做一个个任务，在任务中完成学习。同时，教师可以任务过程穿插讲相关的知识点。 以下为任务列表： 执行 ansible-playbook -i hosts playbook.yml 成功 创建用户 apps 及用户组 apps： user 模块: https://docs.ansible.com/ansible/latest/modules/user_module.html group 模块: https://docs.ansible.com/ansible/latest/modules/group_module.html 创建以下文件夹，并设置文件夹的用户和组为 apps： /apps，/apps/hello，/apps/hello/bin，/apps/hello/logs file 模块: https://docs.ansible.com/ansible/latest/modules/file_module.html 将 helloworld-0.0.2.jar copy 到 /apps/hello/bin 目录下，设置该 jar 文件的用户和用户组为 apps copy 模块: https://docs.ansible.com/ansible/latest/modules/copy_module.html 使用 template 模块将 app.service copy 到目标服务器的 /etc/systemd/system 中，并重命名 hello.service : template 模块: https://docs.ansible.com/ansible/latest/modules/template_module.html 启动 hello 服务 service 模块: https://docs.ansible.com/ansible/latest/modules/service_module.html 监听 hello 服务是否启动成功 wait_for 模块: https://docs.ansible.com/ansible/latest/modules/wait_for_module.html 为目标机器安装 JDK 1.8: 在本地仓库中创建 roles 目录 clone 代码：https://github.com/geerlingguy/ansible-role-java 到 roles 目录中 在 playbook.yml 文件中加入 ansible-role-java 的role 创建自定义 role: hello role 进入 roles 目录：cd roles 使用命令生成 role 模板：ansible-galaxy init hello 将 hello 的部署逻辑（在 playbook.yml 中）写入到 hello role 中 将 hello 部署到多台机器 需要修改 hosts 文件 多环境部署 任务的设计并不是随意的，而是有意的。比如： ...

小明修复了 Web 后端的一个不大不小的 Bug。只修改了一行代码。并在 UAT 环境测试通过。 可是，当我问他为什么不发版时，他说： 代码是测试通过了，但是修改了一行代码，等和其他人的功能一起上吧 在我不长不短的职业生涯中，经常遇到这样的小明。我已经见怪不怪了。 笔者的观念是：如果变更的代码上线不会死人，能上就上。如果每次发版都很痛苦，那么先把发版难这个问题解决。至少也要朝着这个方向前进。 为什么我会这样觉得呢？因为： 程序员写出来的代码，只有真正运行在生产环境上了，才算完成工作。测试通过的代码不上线，就是库存。这在丰田称为“库存的浪费”。也就是不发布到生产环境，你为什么要写出来？还测试通过了。 如果一个分支停留太长时间，分支之间发生冲突的可能性就越大，而解决冲突这类操作对于产品的最终用户来说，是毫无价值的。用丰田生产方式的话说来，就是“动作上的无效劳动”。再者合并冲突过程容易再次引入缺陷。所以，应该避免分支停留过长时间。这个“过长”怎么定义，需要具体问题具体分析。 后记 其实，我很理解小明说出这样的话。大多是因为对部署没有足够的信心。对于没有自动化部署的团队来说，属于正常现象，你不能将责任推到一个人身上。而解决部署难的问题，不仅在管理上下功夫，还要在技术上下功能。

Photo by **Leon Macapagal **from Pexels 团队每天都会面对着看板开早会。过完卡后，会有一些技术问题需要进行深入讨论。大家你一句我一句，实在说不清了，我就想从桌子上拿一支笔将想法画出来。 但是在会议室找不到可用的笔，然后跑到文印室也找不到。这样，几分钟过去了，5个人团队就干等着我找笔。实在找不到，我们只得打开投影仪，打开 Windows 系统自带的画图软件画起架构图。 在经历过几次这样的痛苦后，我决定找办公室负责采购的小姐姐说这事。小姐姐心好，从其它地方拿笔到我们经常早会的会议室。 最后小姐姐补充：本月的文具已购买，下月我再向经理审批再买哦。 我当时没有反应过来，没有理解她这句话的意思。 过了两个星期，我发现又没有笔可用了（后来发现是我在文印室没有找仔细）。我再次找到小姐姐。并跟她说：能不能多放一些笔？ 小姐姐说：笔是统一放在文印室的，因为不知道哪个地方需要用。所以，你们有需要去文印室拿哦。 我说：文印室也没有了，没找到。 然后我实在没有忍住，一连串说了几句文具的成本是多低，节约人的时间，提高工作效率，可以节约更多的成本。 她似乎没有听进去：之前放了一支，你们又丢了。 我说：就一支，是不是别人拿到别的会议室了？ 她说：不知道。我买文具是要经理审批的。 我这才想意识到，她没有决定权。问题出在经理那里。为什么经理不允许买呢？ 从小姐姐那里了解到原来有一次小姐姐按往常一次提流程买笔和本子。谁知经理说：纸巾每月买可以理解，但是为什么笔和本子每个月都要买。 这就是现在为什么小姐姐很少买笔和本子的原因了。 最后，我也不提笔的事情了。因为我单独找经理谈这个事情，在当前的环境下，会被人说“跨级”。再者对小姐姐可能也不好。 谁知，过了两个星期，事业部的副经理从会议室跑出来，问：有没有见到大头笔？ 我苦笑地说：没有。 苦笑是因为我猜到发生在我身上的事，也会发生在别人身上。只不过没想到，发生在了经理级别上而已。 后来，也不知道他有没有找到笔。但是那个会议室还是偶尔找不到笔。 不知道读者朋友看出来问题没有？笔者认为关键问题出在： 提效不一定非要花巨资买个 DevOps 平台，效率发生在每一个企业运营的细节。 软件工程是知识密集型工作，人与人之间需要高效沟通。那么笔、白板（或纸）就是即高效，成本又低的工具。说实在点，工作少出现一个沟通失误，节约下来的钱就可能买下整个公司几年的笔了。小姐姐没有认识到，经理也没有认识到。 企业文化让看到问题的人不敢提问题。 你没有想到吧，一个负责采购小姐姐的决定，也可能影响一家公司的效率？这里没有贬低小姐姐的意思。每个岗位都有它的意义。 这些问题怎么从根本上解决？ 笔者认为，关键点是没有人从效率的角度考虑公司内部的行为。小姐姐考虑的是下次提流程时，经理不会问那样的问题。经理疑问了文具为什么用得这么快，但是并没有深究（几支笔的事情，当然没有必要深究）。其他人（可能）不想惹事，也不会找相关的人提“笔”的事情。在很多企业奉行谁提问题谁解决。有时我怀疑这句话对企业是有害的。 怎么解决呢？我只说一句：解铃还须系铃人。 一定能解决吗？我不知道。因为我也只是觉得可以解决。所以希望和更多人交流解决之道。 我把这些写出来，很有可能犯“政治错误”，得罪某些人。我还是要写出来。因为我相信还有不少企业发生类似的事情。不敢面对，怎么进步。

本篇文章只是笔者看到外墙清洗工后，在管理方面思考的总结。笔者是外墙清洗行业的外行，所以，本文可能存在一些错误的假设。期望这些可能错误的假设不影响管理方面的思考。 引发思考的起因 某天上班，仰头看到大厦清洗外墙工人悬挂在20层楼的半空中作业，除了觉得他们危险外，脑海浮现一个问题。如果作为外墙清洗工的管理者，我们如何保证大厦的外墙的每一处被清洗干净了。 我们经常听管理者这么说： 我只要一个结果，不管过程。 可是这个“结果”是什么呢？ 谁来定义“结果” 回到外墙清洗的管理，作为工程队的管理者，我们要的结果是什么呢？ 面对这个问题，我们要马上回答的并不是“结果”的定义是什么。而是要问：这个问题本身应该由谁来回答。是由老板回答、管理者回答、还是由清洗工回答（我们假设管理者与老板这两种角色由不同的人担当）？ 也就是说，对于不同角色的人，对于“结果”的定义是不一样的。 清洗外墙作为一门生意，结果当然是以最低成本赚最多钱。对于这一点似乎不用定义了。 但是，这个结果只是“老板”希望自己得到的结果。它与管理者希望清洗工给的结果是两回事。如下图所示。 至此，我们发现“谁来定义结果”这个问题，应该换个问法：谁来确定管理者想要的结果与老板想要的结果之间的关系？ 笔者认为应该由管理者与老板共同确定。 如何确定不同层次结果之间的关系 管理者想要的结果与老板想要的结果处于不同的层次。那么如何确定不同层次结果之间的关系，这个问题由老板与管理者共同回答。 如果是把清洗外墙是一次性的生意，结果很准确，就是收到甲方的款。不论外墙是否真的被清洗干净了，因为贿赂验收人员我们一样能得到想要的结果。我们甚至可以设置一个部门专门搞定验收人员。这不是本文要讨论的范围。 如果基于企业长期发展的考虑，我们希望能把洗墙这项业务做好。最终会得到老板想要的结果。 本文，我们假设保证大厦外墙的每一处都被清洗干净是长期正作用于老板想要的结果的。如下图所示。 接下来，下文所说的“结果”均指管理者的结果。 如何验证结果 绕了一圈，终于把结果定义好了。现在咱们把“结果”定义为在文章开头就提了的： 保证大厦外墙的每一处都被清洗干净 但是我们如何验证这个结果呢？我们的管理者不可能也把自己挂在高高的外墙眼睁睁地检查清洗工洗过的每一处。就像产品经理不可能自己打 IDE 一行行的检查程序员的代码。 如果管理者无法做到，加一个监工不就行了？但是谁又来监督这个监工的工作呢？也就是谁来保证监工的工作做到位了呢？ 还有一种办法：让工人相互监工。这样，花两个人的工资，顶三个人的活。可是，在企业里待过的人动下脑子都知道这个方案就不可靠。他们会串通的嘛。因为“偷懒”符合他们的共同利益。（在信息透明度高的情况下，让人相互监工是可行的。比如结对编程。） 以上都是臆造出来的解决方案。都是基于“监工”的模型。看看我们的身边，是不是也是这样？ 回到我们的问题本身：如何确保大厦外墙的每一处都被清洗干净？我们换一种方式解决。 如果采用“激励”的方式呢？假如请了10个清洗工人，等最后清洗完成后，对这10个清洗工人的工作进行ABC评级。得A的人可以得到原来薪水的1.2倍，得B的人保持不变，得C的人是原来薪水的0.8倍。是不是感觉这套路很熟悉？ “激励”的模型虽好，解决的是清洗工人的积极性问题，还是没有解决我们的根本问题：如何验证结果。 定期验收 也许我们可以把“每一处”的标准降低。在所有的清洗工中，选一个最合适的人作为清洗工组长，让其工资高于一般的清洗工人。组长的其中一个重要职责是定期对玻璃进行验收。至于定期的周期设为多长，涉及到工作的反馈周期了，属于另一个问题了。暂不讨论。 虽然这样管理者不用自己被挂在外墙，但是“保证大厦外墙的每一处都被清洗干净”的结果强依赖于组长的责任心。 这个模型的缺点是管理者想要的结果必须强依赖于一个很不稳定的因素：组长的责任心。 用对比法解决 突然有一天，我再看大厦的时候想到，用清洗前和清洗后的大厦照片对比不就可以了吗？ 也就是在保证环境一致的情况下，在清洗前拍一次，在清洗后再拍一次。只要照片足够高清，你想对比多细节都可以。更进一步，我们甚至可以使用软件进行自动对比。 使用此种办法，除了解决以上方案的缺点，还使得“保证大厦外墙的每一处都被清洗干净”的结果从模糊变成准确被量化了。 这意味着什么？ 更短的反馈周期：每天都可以当天的清洗情况。这对于能否按时完成工作非常重要。 更准确的定义“干净”：怎么样才算干净，一对比就知道。同时，清洗工之间绩效对比也有了。 成本更低的检查“每一处”：由于只需要坐在电脑前进行检查，成本会低很多。可能不需要多发一份组长的工资了。 最后，笔者想找同一建筑的两张图进行对比，但是实在找不到。读者朋友就脑补一下吧。 使用对比法就是最终答案了吗？不是的。也许，将来成本更低的办法是使用外墙清洗机器人会代替人工。也许这样更容易得到老板想要的结果。 更甚至于搞个 AI 外墙清洗，然后融个资？笔者调皮了。 后记 以上内容虽不能完全重现笔者的思考过程。但是大体思路就是这样的。这个思考过程，在软件工程方面，笔者认为是相通的。 产品经理必须思考做出来的软件功能是否正作用于老板想要的结果；必须想办法加快反馈；必须想办法更低成本的检查程序员的工作结果；必须想办法让所有人准确理解需求。 同时，本文还有很多方面没有讨论，比如我们是否需要以及如何关心每个人想要的结果；清洗工也是人，企业中的人文关怀问题等等。 最后，说明一下，我并不想挑战别人的专业。以上只是讨论。欢迎大家交流 参考 玻璃外墙清洗的准备工作与注意事项：http://www.fjyybj.com/news/517.html 外墙清洗机器人现身多幢大楼，清洗前后泾渭分明！ https://juejin.im/post/5c73c3a251882562e5445024 人类真的是趋利避害的吗？：https://www.zhihu.com/question/60711385

Jenkins 共享库是除了 Jenkins 插件外，另一种扩展 Jenkins 流水线的技术。通过它，可以定义轻松的自定义步骤，还可以对现有的流水线逻辑进行一定程度的抽象与封装。至于如何写及如何使用它，读者朋友可以移步附录中的官方文档。 对共享库进行单元测试的原因 但是如何对它进行单元测试呢？共享库越来越大时，你不得不考虑的问题。因为如果你不在早期就开始单元测试，共享库后期可能就会发展成如下图所示的“艺术品”——能工作，但是脆弱到没有人敢动。 [图片来自网络，侵权必删] 这就是代码越写越慢的原因之一。后人要不断地填前人有意无意挖的坑。 共享库单元测试搭建 共享库官方文档介绍的代码仓库结构 (root) +- src # Groovy source files | +- org | +- foo | +- Bar.groovy # for org.foo.Bar class +- vars | +- foo.groovy # for global 'foo' variable | +- foo.txt # help for 'foo' variable +- resources # resource files (external libraries only) | +- org | +- foo | +- bar.json # static helper data for org.foo.Bar 以上是共享库官方文档介绍的代码仓库结构。整个代码库可以分成两部分：src 目录部分和 vars 目录部分。它们的测试脚手架的搭建是不一样的。 ...