DevOps探索之旅（二）——工具的那些事

上回说到“小开”公司开始引入DevOps来解决开发和运维工作中存在的问题。DevOps不只是工具，但也离不开工具，自动化工具经常是DevOps实施的切入点。这就面临着两个问题：哪些环节需要引入工具？引入哪些工具？

对于第一个问题，让我们秉着会哭的孩子有奶喝二八原则，看看哪个环节哭的最凶工作占比最大。不论是根据行业数据统计还是我们的直观感受，大多数组织都是开发环节工作比重最高，小开也不例外。而开发人员的工作主要包括两部分：

编码工作需要充分发挥人的聪明才智，工具暂时替代不了；

编译则需要将新开发的代码和原有代码进行合并、编译和构建。对于敏捷开发的团队，需要频繁的执行代码拉取、等待本地编译、自测、提交等动作，否则本地代码会和服务器上的主干代码差异过大而导致合并问题。

 

我堂堂资深程序构建师·高级软件创造者·代码Master·LORD_OF_APP（以下简称码农），怎么可以去做这些频繁重复又没有技术含量的工作？所以一般我们会先把这部分频繁且重复的工作自动化。如此一方面减少了开发人员的工作负担，提升了他们的效率；另一方面，自动化工具可以突破人工进行集成构建的频率限制，实现时时刻刻都可以集成的能力，这我们称为持续集成。

持续集成实现了代码在服务器上进行自动检查、合并和构建，那么构建之后呢？现在压力来到了测试这边。不忍看到测试工程师压力山大的样子，小开的DevOps工程师在工具链中加入了自动化测试，代码构建之后可以自动运行测试脚本。

测试自动化之后，运维大哥表示也不能再手动了，把环境配置文件、镜像制作和运行的脚本也都放到了流水线中，测试通过后就可以自动执行，将程序包部署到指定的环境，这就实现了持续部署。

在引入了持续集成、持续测试、持续部署这几个核心环节之后，就可以再根据需要添加其它环节的工具，比如需求和任务管理、运维监控、制品管理、效能平台等等，最终打通研发过程的任督二脉，以迅雷不及掩耳盗铃儿响叮当之势完成从计划需求到发布部署的整套任务环节。

确定了引入工具的环节，我们再来看看各环节有哪些可选的工具：

 

选择困难症又犯了！医生说治疗的方法很简单，主要就是建立选型的评价指标，然后根据指标去评分就完事了。

一般的评价指标包括系统的限制、可用性、市场占有率、关联生态、学习曲线、可裁剪性、云端或本地等；在开源/闭源的选择上，还需要考虑成本、更新频率、社区和支持、用户评价、文档等方面的因素。每项指标下又可再细分若干更具体的可操作指标，例如系统的限制要素可包含操作系统、硬件需求、软件需求、浏览器的支持等；成本则可以进一步考虑License的类别和费用、维护费用、基础软硬件成本、学习成本、对现有系统的改造等因素。

注意，以上只是一些评价指标的例子，我们考虑最关心的几个指标就好，想太多可能引起新的选择困难症，医生说那要重新挂号交钱。

很少有工具能够成为各方面指标爆表的六边形战士，因此还需要确定指标的优先级或权重，再由团队及专家评分，或系统测试评分后，加权得出选定的方案。对于选定工具的短板或风险，别忘了在使用过程中采取规避或缓解措施。

 当然，选择不是一次性的，实践是检验真理的唯一标准，实际使用的环境和场景能够真正评价这些工具是否适用。同时环境和场景也在变化，现在适合不代表以后也适合。就像感情不能勉强，工具也是一样。