作者回复: 会的，第29篇就是自动化测试。

另外你说的场景是不是指的单元测试、集成测试、端对端测试这样的场景？

作者回复: 💯

作者回复: 👍赞，从工具入手，从持续集成、自动化测试、代码审查这些好的开发实践开始，就能很快起到改进的效果。然后再是优化开发流程，把好的实践工具化流程化。最后再考虑去优化开发模型，去优化开发过程中的各个环节。

作者回复: 既然你能模拟数据，那么就可以自动化测试了，参考《29 | 自动化测试：如何把Bug杀死在摇篮里？》中的内容。
一个完整的自动化测试要包括三个部分的测试：验证功能是不是正确、覆盖边界条件、异常和错误处理。

你不需要覆盖所有的测试，你只要覆盖上面三部分就可以。

剩下的你就是要解决如何校验测试结果的问题了。我对硬件所知有限，不知道是否有方法可以做到。你也可以考虑是否有间接的方式，比如说一个测试用例完成，通过软件触发拍一张照片，然后你集中确认这些照片，那么还是可以减少很多劳动。

作者回复: 先不用管其他人其他公司如何，先从自己做起，从手头的项目做起🤝

作者回复: 我觉得对于大部分时候，微服务之间应该是独立的，而不是依赖过于紧密，如果每一个新功能都会这样，那架构设计一定是有问题的，需要重新思考服务划分的合理性。

但你需要有更多上线或者场景我才能针对性提出一些意见。

对于有一些确实需要跨服务合作的大Feature这样也是正常的，就是需要一起协作，实现商量好通信协议，分头开发，再联调。

作者回复: 生产环境要人工介入这个是正常的，但还是要考虑一些可以优化提高的地方，比如说：
- 整个部署过程应该尽可能保证自动化，人工只是发动部署和监控部署过程，并不需要太多手工操作
- 做好监控和自动报警，有问题及时回滚（要做到可以回滚）
- 测试环境和生产环境应该尽可能一致，在测试环境部署的程序也应该尽可能一致，避免出现同样代码部署在测试环境正常，一部署到生产环境就出问题

作者回复: 要注意是“合并”而不是“覆盖”

比如说bug1涉及file1和file3的修改，那么开发A合并的时候只合并file1和file3。
等到开发B修复了bug2，修改了file1和file2，file2直接合并，file1需要手动去修复合并冲突才能合并。

每个人开发之前，都会从master获取最新版本，合并的时候，如果出现冲突，要先解决冲突才能合并进去。

这些其实你应该自己去动手试试，会体会更深刻。

作者回复: 广义的集成是包含代码合并、编译、自动测试还有部署的。

持续集成就是频繁的集成，例如每次提交代码都会集成，或者可以手动触发集成。