汽车之家开发团队使用代码发布系统的经验总结

pushguide发布系统，是汽车之家正在使用的代码发布系统。「代码上线」是运维日常工作中最重要的一部分。在没有发布系统之前， 所有的业务都需要运维来手动上线。 上线工作对运维人员来说是不小的工作量。 为了解放生产力，提高上线效率，我们开发了该系统。

1. 背景
（1）野蛮生长阶段
业务线自己各自为战，没有统一的代码规范， 发布流程。 上线之前提交上线单通知运维人员手动上线。这种模式的缺点不言而喻，运维人员需要随时待命， 从上线部署到最后验证， 有问题的话回滚都需要运维人员全程手动完成，费事费力。
（2）统一规范，使用发布系统发布
业务线接入CI和发布系统之后， 业务方通过CI打包自己的代码， 通过发布系统自助完成发布。如发布代码有问题，可以在系统上直接选择要回滚的版本。 运维人员只需要配置好要发布的模块即可。大大解放了运维的工作量。同时，各个业务线需要按照统一规范组织自己代码结构才能够使用发布系统。

2. 设计原则
什么样的系统更适合于汽车之家的业务？ 首要要满足不同业务线的不同项目类型的发布，这些类型包括.net项目、java web项目、windows计划任务等。 其次，公司有大量的windows服务器， 发布系统需要同时支持windows和linux。最终我们选择基于saltstack自动化运维配置工具设计开发发布系统， 使用该工具的好处如下：
（1）python开发，和运维开发的技术栈一致。对于以后的扩展，二次开发都很方便
（2）快速, 原生提供了http api支持
（3）支持windows

3. 发布系统架构
3.1 发布系统的整体架构
发布系统前端通过salt api与salt master进行通信， 发布任务描述信息到salt master。salt master通过salt命令调用我们自己开发的模块来完成一次发布任务。

3.2 发布系统与其他系统如何合作完成代码发布
我们需要通过CI系统来打包代码，通过配管系统来部署代码运行环境，如tomcat等等。通过CI以及配管系统提供的接口，我们在发布系统中获取到发布的版本和配置的tomcat信息

3.3 发布系统对上线流程的抽象
我们把一次上线流程抽象成以下四个阶段
（1）准备阶段
（2）发布前阶段
（3）发布阶段
（4）发布后阶段
为了支持不同发布类型和可扩展性， 我们通过继承抽象出不同的类来完成一次上线流程，如下所示：

4. 遇到的问题
作为重要的代码发布系统， 稳定性上一定要有可靠的保证， 这样才能让业务方人员放心大胆的使用系统发布代码。但是在发布系统的使用过程中我们也遇到了一些问题。
4.1 确保salt的稳定性
由于pushguide是基于saltstack来完成代码的发布，所以对saltstack的运维又显得很重要。在前期的使用的我们经常遇到由于salt的问题导致发布系统出现不可用的情况。所以我们优化了整个salt的架构。通过使用多机房multi master来保证salt的稳定性。关于salt的高可用方案，网络上也有一些其他做法如加入代理层，重写returner模块等方法。但从效果看，目前的multi master可以满足我们现在的发布需求。
4.2 代码的规范
系统使用前期，由于业务方的代码不够规范，比如我们在现实场景中会遇到有的业务方把业务代码和日志文件放在一起，代码目录非常大，导致发布的失败。所以对于发布系统的来说，我们不能仅仅是发布代码， 同时可以制定代码，目录规范来约束业务方规范自己的代码。
4.3 监控
对于发布系统web服务的监控自然是必不可少的， 同时我们还定时对接入发布系统的主机salt minion连通性进行检测， 发现有salt minion不可用情况及时处理， 避免在发布时失败的情况

5. 发布案例
下面以一次代码发布为例， 详细介绍发布系统的使用。
运维人员登录发布系统，会根据权限展示运维人员可以看到的发布模板。

进入新建模板页面， 填写必要信息， 新建模块。在模板类型选择中可以选择本次配置的是.net、java、windowd计划任务等。

配置完成后，如果业务方有上线， 只要进入发布页面，选择要发布的版本，点击发布，就可以自助的发布代码。

在发布页面， 同时还可以看到上次发布的情况，已经发布每个阶段的情况。

业务方人员还可以在统计分析页面查看自己的发布情况，包括发布时间，发布次数，成功率等等。

6. 未来可以做的事
6.1 异步发布
目前发布系统的做法是同步发布， 点完发布后，页面会阻塞在当前。 未来我们把整个发布过程异构， 使整个发布过程的体验更加稳定，流畅。
6.2 自动回滚
我们可以为让业务方人员选择是否自动回滚以及要回滚到的版本。 当发布失败时， 执行自动回滚逻辑， 让发布更加轻松智能。
6.3 对发布数据的应用
通过统计业务方的发布情况， 我们可以规范业务方的发布行为。比如哪些时间段的发布成功率低，那些服务器总是发布失败等等情况。通过这些数据分析， 帮助业务方提高上线的成功率和发布质量。
6.4 可视化发布
以后我们可以做到上线的每个阶段可视， 比如用流程图展示出发布在哪个阶段出了问题， 可以直接在该阶段选择是否回滚或其他操作等。

7. 小结
发布系统马上要接入公司的所有业务线，这对我们来说是一个不小的挑战，如何优化我们的系统，提高系统的稳定性，如何让用户体验更好，满足更多需求,我们还有很长的路要走。