首先是版本管理。每一个需求对应一个代码分支，上线之前将各业务（前端、后端等）分支合并到一个提测分支上，测试通过后将代码合并至主干上。这时候通过 CI 部署到对应服务器的是合并主干后的一个版本，回滚则使用主干上的前一个版本。
当然以上是默认主干版本就是每个 release 的版本。
二，通过 CI 执行构建任务
CI 是可以跑一些脚本的，构建自然也不在话下。这也就意味着我们仅仅需要配置服务器端的构建任务即可，不需要将构建任务分布在各客户端（开发人员）下。
三，发布
从一个环境发布至更上一级的环境，也是通过 CI 自动完成。这对于我们开发人员就像是个黑盒子，只需要知道它会产生怎么样的内容就好，不需要关心其中的实现与流程。
如果有以上这三步，那么一个发布流程就只需要我们两步操作，提交代码至主干和点击发布。如果在 CI 上设置自动发布，即自动拉取主干的更新并发布，那么我们就只剩下一步操作了，提交代码至主干。
人
CI
提交代码
自动拉取代码 + 自动构建 + 自动发布
易迅盒子的价值所在
人生没有一帆风顺，我们的发布流程也是几经磨难。由于无法更改处在上游的发布系统设置，我们只能通过类似 FTP 手工上传的方式发布代码至生产环境，所以每一次的构建都是和 CI 脱离的——本地构建任务后将产出文件手工上传。盒子的出发点是整合零碎的构建任务于一处，但是在一套理想的发布流程中，本地构建这一步应该是不需要存在的。
我眼中的理想发布流程
一套理想的发布流程，绝不是手工发布的。
在易迅盒子出产之际，我想有必要勾勒一下我心中的理想构建流程。
理想构建流程
一套理想的构建流程，从三个方面看就是：
一，版本管理相关联的代码部署
首先是版本管理。每一个需求对应一个代码分支，上线之前将各业务（前端、后端等）分支合并到一个提测分支上，测试通过后将代码合并至主干上。这时候通过 CI 部署到对应服务器的是合并主干后的一个版本，回滚则使用主干上的前一个版本。
当然以上是默认主干版本就是每个 release 的版本。
二，通过 CI 执行构建任务
CI 是可以跑一些脚本的，构建自然也不在话下。这也就意味着我们仅仅需要配置服务器端的构建任务即可，不需要将构建任务分布在各客户端（开发人员）下。
三，发布
从一个环境发布至更上一级的环境，也是通过 CI 自动完成。这对于我们开发人员就像是个黑盒子，只需要知道它会产生怎么样的内容就好，不需要关心其中的实现与流程。
如果有以上这三步，那么一个发布流程就只需要我们两步操作，提交代码至主干和点击发布。如果在 CI 上设置自动发布，即自动拉取主干的更新并发布，那么我们就只剩下一步操作了，提交代码至主干。
易迅盒子的价值所在
人生没有一帆风顺，我们的发布流程也是几经磨难。由于无法更改处在上游的发布系统设置，我们只能通过类似 FTP 手工上传的方式发布代码至生产环境，所以每一次的构建都是和 CI 脱离的——本地构建任务后将产出文件手工上传。盒子的出发点是整合零碎的构建任务于一处，但是在一套理想的发布流程中，本地构建这一步应该是不需要存在的。
而目前来看，盒子的存在可以有效提升我们的工作效率。欲往前更进一步？还需翻山越岭（不便多说了啦）。
如果有人想要加入易迅团队，看到这里可千万别吓着，讲真，还没遇到过在工作中最大痛点在发布流程的，往往在产品，对不对~ :joy:
Thanks