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

1. docker

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

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

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

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

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

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

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

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

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

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

docker

第一反应就是 docker

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

@ivyliner

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

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

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

@dennyzhang

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

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

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

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