如何验证部署过程的正确性？

[dennyzhang]

系统更新，出问题后，开发童鞋们第一反应经常是：会不会是部署过程的 bug? 部署的是否为想要的版本？

当然多半是开发的 bug 。不过，有点的尴尬是，有时候真的是 deployment 的 bug 。这种事情出个二三次，就足以伤害开发童鞋对我们部署代码的信任。

大家有什么妙招吗？

我在 reddit 也发了一个相似的帖子。
https://www.reddit.com/r/devops/comments/58lf6d/verify_what_we_deployment_is_what_we_want/

[tomczhen]

1. docker

2. 让开发交付编译好的二进制文件，直接提交到版本控制系统中，使用配置文件进行各项配置（数据库，各种 key ，参数之类的），这样只需要对部署后的结果进行对比就行了（ md5/sha1 ），当然配置文件可以直接使用文本对比差异。

3. 对关键部分增加自动测试环境，比较检查基础配置项目或者业务逻辑之类的。

4. 把开发用的机器拖到生产环境去当服务器。:doge:

[dennyzhang]

赞赞。第二条和第三条比较相似。

第二条中，我是生成一个 cksum ，放到 artificat repo 的 branch_name 目录下。倒没想过把 binary 提交到 SCM 。感觉会有些大。

第三条中，部署自动化时是跑 serverspec 。还没想好，怎么把同样的逻辑应用于真实系统部署后的验证。感觉会有不少 code duplication 。有什么好的建议吗？

[ivyliner]

第二条当你的编译环境没有固定的时候会很坑. 遇到过有人离职了, 后面同学根本无法知道当初这个二进制是怎么 build 出来的.

[coagent]

1. 尽量减少人工操作，能自动化或者程序操作的就写脚本或借助工具来完成，这样能避免人工操作导致的错误。我们 Java 是使用 maven + jenkins 部署，正在调研 docker 部署。服务器环境参数不变的情况下， Jenkins 部署过程的 console output 和程序运行日志，即可证明是开发的 Bug 还是运维的问题。

2. 多总结每次遇到的问题，运维面对开发的 Bug ，反过来开发面对 deployment 的 bug 的态度，会影响两方的一些信任，多互相学习、交流，少指责不面对，认真总结、面对 Bug, 并最大努力避免下次出现相同问题，形成一个良性循环，有持续改进流程的良好流程体系和作业方法，信任度自然就有了。

3. 细心、复查、确认的 deployment 执行（过程）也很重要。

[huluhulu]

docker

[Tinet]

第一反应就是 docker

[PaleCheung]

合理的部属当然是自动化的。

[tomczhen]

@ivyliner

我待的是小公司，各种问题用比较脏的办法解决对我来说是“最优”的——懒才是运维的必要特点。

运行 /编译环境问题，要开发和运维一起坐下来解决掉，如果进入各种撕逼的节奏，我想到的办法就是让开发交付二进制编译成果。

我也知道这个办法不是一个好办法，不过至少能快速解决我的问题，减少撕逼时间。

@dennyzhang

如果是直接从 SCM 中签出的话，我觉得文件校验这块版本控制系统是应该有做的——毕竟这个问题实在是太低级了。

小公司项目连文档都没有，更不谈专门写什么测试用例了，反正我只是校验了下配置文件，剩下的就是纠如何自动的实现搭建一个最接近生产环境的测试环境，还得不影响生产环境（公司项目是.net 平台， windows server ）。

至于后面的问题，慢慢找资料解决了。

准备试试 windows server 2016 的容器功能，虽然公司肯定不会让我用这么新的版本到生产环境。