10月24日总结

想起初来公司时，我们还是在发布机上直接执行发布脚本来运行和部署服务，并且正式环境和测试环境的脚本都在一起，直接手动操作脚本时存在比较大的风险就是将环境部署错误，并且当时脚本部署逻辑还没有检测机制，服务部署起来后，还必须登录到对应机器查看服务是否正确启动，整个部署过程可以说是很折磨人了。于是，我开始着手改善这块。
如何优化#

第一，整个编译部署过程将不再允许登录到发布机手动执行发布脚本了，这样的风险性比较大，决定采用jenkins来完成编译和发布的工作，这样能让开发者通过界面操作来进行编译部署。

第二，之前脚本缺少检测机制，决定改善脚本，首先在部署前，脚本需要检测对应的服务的配置文件是否符合标准，我们的配置文件是json格式，其次在部署完成后，检测服务是否正常启动，如果没有启动，则尝试再次部署，直到失败3次后将不再重试。
部署模式思考🤔#

在决定朝着这两个优化点进行优化后，我开始思考最终的部署模式，测试环境肯定是经常要部署和发布的，而正式环境则不需要经常发布，并且要谨慎发布。

所以我考虑在测试环境做个自动发布的功能，到代码合并到测试环境的分支(测试环境永远用固定的分支名)时，会触发jenkins的webhook机制来自动编译和发布到测试环境。