5．总结一些DevOps最佳实践

持续集成的原则

• 鼓励开发人员在开发分支上频繁的提交代码，随后触发CI流程，在CI过程中可以加入单元测试和代码质量检查等动作，这样产生代码冲突的几率会下降，并且代码质量也会提高的；

• 在下班之前，构建必须处于成功状态，原因是你的代码在第二天有可能是其它同事开发工作的基础，如何无法保证构建成功，会影响其它的人工作质量和效率，团队氛围也会产生坏的影响；

• 让开发环境上快速体现最新程序包

• 让程序、配置、数据分离，其实现在好多的单体应用开发时，是将程序、配置、数据裹在一起的，改一处，要解决一堆的依赖，改一处，牵扯到很多地方都要做更新，这些降低了版本迭代的效率，并且很可能会出现遗漏

• maven模式下，pom依赖尽量不要用system本地依赖模式，而是将二方库和三方库依赖到统一的类似Nexus介质库，整个组织一份，来屏蔽本地jar依赖差异导致的编译错误。

持续集成的最佳实践

• 构建过程，建议等待构建的结果，不要同时做其它的事情，尤其是构建失败之后不要提交新代码，这样很可能会错上加错，最后不知道到底是谁的错，这些错误的回溯会产生很大的成本。

• 提交之前在本地运行所有的提交测试

• 提交之前请更新本地代码，保证代码是最新的，冲突解决了，再提交

• 记得更新数据库、配置文件等

• 等构建成功后再继续其他工作

• 下班之前，构建必须处于成功状态

• 以十分钟为界限，如果代码提交后构建错误，十分钟之内无法解决问题，需要将新代码撤回，否则可能会影响其它同事的工作。

自动化部署的原则

• 原则1：确保从开发、各类测试到生产，使用相同版本的中间件和操作系统，保证从操作系统、到补丁包、到应用运行环境基线是一致的

• 原则2：同一套脚本，解决各类环境的部署问题，不要试图通过脚本来解决环境的差异性，因为环境的差异性本应该是不存在的，否则改了脚本，之前的各个环境还需要做脚本的回归测试

• 原则3：部署之前，事先设计回滚与零停机发布的策略

• 原则4：全量发布优先，尽量不要用增量发布，因为引入增量发布，就会引入手工操作，人工去选择哪些做增量

• 原则5：详细记录部署活动的整个过程

自动化部署的最佳实践

要做到自动化部署，要确保自动化部署的成功，最最重要的关键为：保障一致性！将要部署的各个环境一致；在各个环境执行的部署脚本一致；要部署的安装包也要一致！

• 从提测之后，所有环境运行的是同一个介质包，不要在SIT、UAT、准生产和生产等环节重复的打包

• 保证各个环境的操作系统、补丁和软件运行环境的基线一致；

• 保证使用同一的二方和三方库依赖，推荐Nexus

• 关于配置文件，建议：配置文件与代码的版本保持一致

○ 配置项清晰、规范、统一命名

○ 配置项模块化、且封闭

○ 每个配置项都是唯一的，避免顾此失彼

○ 避免过分设计，尽量简单

○ 建议逐步过渡到Apollo这样的统一配置中心，以key/value的形式管理各环境的配置项