pushguide发布系统，是汽车之家正在使用的代码发布系统。「代码上线」是运维日常工作中最重要的一部分。在没有发布系统之前，所有的业务都需要运维来手动上线。上线工作对运维人员来说是不小的工作量。为了解放生产力，提高上线效率，我们开发了该系统。
1.背景（1）野蛮生长阶段业务线自己各自为战，没有统一的代码规范，发布流程。上线之前提交上线单通知运维人员手动上线。这种模式的缺点不言而喻，运维人员需要随时待命，从上线部署到最后验证，有问题的话回滚都需要运维人员全程手动完成，费事费力。（2）统一规范，使用发布系统发布业务线接入CI和发布系统之后，业务方通过CI打包自己的代码，通过发布系统自助完成发布。如发布代码有问题，可以在系统上直接选择要回滚的版本。运维人员只需要配置好要发布的模块即可。大大解放了运维的工作量。同时，各个业务线需要按照统一规范组织自己代码结构才能够使用发布系统。
3.发布系统架构3.1发布系统的整体架构发布系统前端通过saltapi与saltmaster进行通信，发布任务描述信息到saltmaster。saltmaster通过salt命令调用我们自己开发的模块来完成一次发布任务。
3.2发布系统与其他系统如何合作完成代码发布我们需要通过CI系统来打包代码，通过配管系统来部署代码运行环境，如tomcat等等。通过CI以及配管系统提供的接口，我们在发布系统中获取到发布的版本和配置的tomcat信息
3.3发布系统对上线流程的抽象我们把一次上线流程抽象成以下四个阶段（1）准备阶段（2）发布前阶段（3）发布阶段（4）发布后阶段为了支持不同发布类型和可扩展性，我们通过继承抽象出不同的类来完成一次上线流程，如下所示：
4.遇到的问题作为重要的代码发布系统，稳定性上一定要有可靠的保证，这样才能让业务方人员放心大胆的使用系统发布代码。但是在发布系统的使用过程中我们也遇到了一些问题。4.1确保salt的稳定性由于pushguide是基于saltstack来完成代码的发布，所以对saltstack的运维又显得很重要。在前期的使用的我们经常遇到由于salt的问题导致发布系统出现不可用的情况。所以我们优化了整个salt的架构。通过使用多机房multimaster来保证salt的稳定性。关于salt的高可用方案，网络上也有一些其他做法如加入代理层，重写returner模块等方法。但从效果看，目前的multimaster可以满足我们现在的发布需求。4.2代码的规范系统使用前期，由于业务方的代码不够规范，比如我们在现实场景中会遇到有的业务方把业务代码和日志文件放在一起，代码目录非常大，导致发布的失败。所以对于发布系统的来说，我们不能仅仅是发布代码，同时可以制定代码，目录规范来约束业务方规范自己的代码。4.3监控对于发布系统web服务的监控自然是必不可少的，同时我们还定时对接入发布系统的主机saltminion连通性进行检测，发现有saltminion不可用情况及时处理，避免在发布时失败的情况
进入新建模板页面，填写必要信息，新建模块。在模板类型选择中可以选择本次配置的是.net、java、windowd计划任务等。
配置完成后，如果业务方有上线，只要进入发布页面，选择要发布的版本，点击发布，就可以自助的发布代码。
在发布页面，同时还可以看到上次发布的情况，已经发布每个阶段的情况。
7.小结发布系统马上要接入公司的所有业务线，这对我们来说是一个不小的挑战，如何优化我们的系统，提高系统的稳定性，如何让用户体验更好，满足更多需求,我们还有很长的路要走。