工具是DevOps实践的重要组成部分，相比于DevOps文化和方法，工具是看得见，摸得着，更加直观的。大家都认可这样一种说法—如果只把工具链搭建起来，而没有形成DevOps文化，这样的DevOps不会获得明显的收益。但是我想换个角度来思考一下，能否通过对工具的合理使用，促进文化的形成和DevOps方法的落地呢？本篇文章我将致力于通过长期的工作实践，学习和思考，整理关于通过工具推动DevOps落地相关的最佳实践。（此文档是不断更新的，如果要持续关注请关注我的博客。）
先引用xebialabs发布的PERIODIC TABLE OF DEVOPS TOOLS（V3）：https://xebialabs.com
- 如何形成文化：奖励符合文化的行为，惩罚不符合文化的行为。
- 人通常是整个环节中最不稳定的因素。所以自动化不仅仅能提高效率，而且能避免由于手工操作而带来的错误。
词汇表
CI：Continuous Integration 持续集成
CD：Continuous Deploy 持续部署
CD：Continuous Delivery 持续交付，是指将应用交付到生产环境为用户提供服务，持续交付与持续部署不同的是，部署到生产环境是需要手动触发的，但部署的过程是自动化的。交付是业务范畴，而不仅仅是技术。
SCM: Source Configuration Manage
通过工具推动DevOps落地的最佳实践
Git
| 理论依据 | 最佳实践 |
|---|---|
| git | 提交代码必须写push注释 |
Jenkins
| 理论依据 | 最佳实践 |
|---|---|
| 每次提交触发构建 | webhook |
| 每次提交必须基于上一次的成功构建，如果构建状态是失败的则不能提交代码 | 持续反馈构建状态，邮件/大屏幕等 |
| CI的一个最佳实践：中断的CI构建需要立即采取行动，因为它表明了主线质量的严重问题。开发人员必须尽快修复它，以便可以再次构建它，并且继续开发。 | 构建必须保证是成功的，当构建失败时，必须立即修复。谁提交代码导致的构建失败，谁就负责修复。 |
| 持续反馈：持续，快速，有效的反馈是CI流程的重中之重 | 使用多种通知途径，通知失败/不稳定的构建。还包括在一系列失败或不稳定的构建后，首次成功的构建也要通知，以表明问题已得到修复。 |
| 持续反馈：基于实际构建考虑什么样的通知策略是适当的，而不是所有的构建都采用同样的通知策略 | 哪些通知发给开发人员，哪些通知发给测试人员，哪些通知发给项目经理要有区分。可以使用Email Extension Plugin插件更精细的控制通知邮件策略。为每个项目创建一个邮件组，尽可能的让项目相关信息为所有相关人同步。 |
| 持续反馈：当构建失败时，知道有人发现了这个问题并正在修复它是有意义的。这可以让相关的人知道谁在处理这个问题，并且避免多个开发人员解决同样的问题。 | Claim插件 |
| 持续反馈：构建分发器 | 通过Radiator view插件，将失败和不稳定的构建显示在团队成员显而易见的大屏幕上。 |
| 持续反馈：通知到IDE | Eclipse插件可以通知到开发人员使用的Eclipse |
| 持续反馈：即时消息通知 | 如jabber，IRC，微信等 |
| 自动化部署的一个基本原则就是重用二进制库，部署到不同环境（测试/UAT/生产环境）时应该使用相同的二进制文件（如WAR/JAR）而不是重新构建一遍。因为重新构建的二进制文件与已通过测试的版本可能已经有所变化。 | |
| 例如JDBC这样的环境依赖的配置不应该内嵌到WAR/JAR文件中。 | 使用配置管理，如百度开源Disconf，携程开源Apollo |
| 数据库回滚的最安全的办法是通过快照 | 在部署新版本之前先给数据库做个快照，以便回滚 |
SonarQube
代码质量的定义是主观的，所以需要一个工具来统一质量标准。
| 理论依据 | 最佳实践 |
|---|---|
| 将代码质量检查左移，越早发现代码问题，修复的成本越低。在开发阶段，测试阶段，UAT阶段和被最终用户发现的修复成本是不同的。 | 让开发人员在IDE中使用SonarLint插件，使代码质量问题在提交到代码仓库之前就暴露并解决。开发人员也不愿意看到当自己的代码提交到仓库之后SonarQube报告出bug或者其它问题。 |
| SonarQube关注新增代码和被修改的代码 | 合理设置Leak period 和 Gate，Gate应该关注new code |
| Gate作为指示程序能否发布到生产的阀门 | 1. 强制不通过Gate阀门的程序不能发布，而且必须立即修复使其通过Gate阀门 |
| 统一规则 | 一个团队要统一代码质量标准（rule），并且标准要文档化，透明化。使每个人都清楚规则。 |