之前我们的开发流程为在本地进行webpack打包编译，然后svn提交源代码和编译后的代码。同时每次提交前也会从svn更新源代码和编译后的代码。这样做有几个缺点：
1. svn 更新和提交编译后的代码造成大量冲突文件
2. 由于我们使用非覆盖式发布的命名方式，在经过小组多人多次优化提交测试之后，在整理需要发布的文件列表时，很容易遗漏一些文件
3. 在涉及到多人开发同一功能时容易产生代码被覆盖、人工安排发布优先级、手动注释他人未上线代码等情况
4. svn的分支开发繁琐不友好，加重工作量
最不能容忍的是第一第二点，于是我们改成服务端打包编码，本地只提交和更新源代码，这样就会大大减少冲突。同时，利用jenkins自动把服务端打包编译后的代码部署到测试和线上环境，省去了手动整理待发布文件列表的麻烦，也避免了发布文件遗漏的情况。为了提高开发流程质量，科学友好的规范开发流程，我们选择gitlab作为新的代码仓库，通过分支管理和代码review来提高开发效率，减少发布错误。
二. 自动化部署架构 完成功能：
1. 代码仓库用gitlab托管，使用AoneFlow分支管理模式（阿里命名的一种分支管理模式，借鉴于gitflow, githubflow和gitlabflow）。
2. 源代码合并到测试分支后，jenkins自动打包编译并将编译后的代码部署到测试环境。
3. 源代码合并到发布分支后，jenkins自动打包编译并将编译后的代码部署到线上环境。
4. 给Master稳定分支打版本tag，同时增加tag版本说明。
5. 脚手架和代码分离，保留一个脚手架仓库，提供给各个环境编译。
A. jenkins合并代码并编译，ssh发送编译后代码到测试环境
缺点：发送代码量大，耗时严重
B. jenkins合并代码并编译，编译结果提交到gitlab，ssh连接测试环境从gitlab更新代码
缺点：编译后代码合并到gitlab冲突多，麻烦
C. jenkins合并代码，ssh连接测试环境更新gitlab代码，然后运行编译命令
优点：速度快，冲突少
综上，我们选择方案C进行部署代码。
发布到线上，不能通过merge到release/prop发布分支后自动触发jenkins构建，因为我可能同时有多个feature分支需要一次性发布到线上，这个时候需要多个feature分支挨个合并到发布分支，然后才能执行构建操作。所以合并到发布分支和构建部署到线上应该分为两个独立部分，分别执行。
一图胜千言，结合我司的实际开发环境，目前整体架构如下：
三. jenkins 配置实战
关于jenkins安装的方案网上有很多，可以另行查询。
1. 首先安装插件：Gitlab Hook Plugin
GitLab Plugin
Publish Over SSH
系统管理--管理插件--可选插件
3. 配置git源码
点击新建的job，点击配置--源码管理
Repository URL ： 填写git仓库地址
点击add--jenkins
选择 ssh username with private key (需要提前在jenkins服务器生成ssh keys)
username: root
enter directly: 私钥内容 或者 From a file on Jenkins master ： 私钥的存放路径比如/home/role/.ssh/id_rsa
passphrase: 生成ssh keys时填的密码，如果当时没设置则不填
如果选择私钥内容，那就需要在gitlab上把你的公钥填到gitlab ssh keys: