| 编辑推荐: |
本文主要介绍了一个公司接到客户项目，需要完成java端、Android端、ios端和部署服务器环境的等相关内容。
本文来自于微信 DevOps时代义,由火龙果软件Alice编辑推荐。 |
|
背景
先说下背景，我们是一家小公司，虽然打着做产品的旗帜，但是每个客户都有大量的个性化功能，这里指各个客户的java端、Android端、ios端（大部分功能代码是相同的，个性化功能代码不同）。
我之前是做 Android的，实践证明，特殊情况下，只有我们Android组可以随意切换到任意一家客户，任意一版本的代码。并且修复一处公共bug，所有客户的版本都会更新。我也一直在介绍这种开发模式，但并得不到支持，直到年初，我晋升为移动端组长，加上，后来java组组长跳槽，我才有机会全面实施重构计划。
前言
因为我做过很多年的运维（网吧软硬件运维等），对服务器硬件以及软件有较高的认识，加之我对各门语言有一定的开发经验，算是一位全栈工程师，对各端都比较熟悉。这一切，为我的实施带来了很大的帮助。
本人申明以下所有重构思路均出自本人想法，实施上，由我统一安排培训后落实。（虽然落实阻力极大，但最终效果不错)
先说说效果
之前，我们每接入一个客户项目，完成java端、Android端、ios端和部署服务器环境等，需要2周的时间。现在，我们大概需要30分钟。并且每位客户个性化需求再多，我们也能灵活开发及切换到各个客户的代码上。
之前，我们开发流程极为混乱，没有文档，没有各种开发流程，现在我们逐渐规范，至少节约50%的开发成本。当然，我们还在不断改善中。
Java 项目组
我们的java项目，原来分为接口服务、后台管理服务，但是都在一个git库里，我将它分为：
1.接口服务
2.后台服务
3.html5包
4.公共包服务
因为本次重构，我逐步采用前后端分离方案，所以多出了h5包。
每个库分为多个分支，其中定义master为主分支，各个客户为新开的一个分支，通过分支来解决各个客户各种不同需求，（因为客户需求实在过细，有些文字都得改，单纯的插件化开发的话，每个插件都要n多个版本，这样对于我们小公司，做不起来），当然各个客户也应该有个开发分支，但受限于我们人员较少，一期省去了开发分支，把本地暂存区作为开发分支。
开发流程如下：
开发人员只需要本地调试后，提交代码到git库的某个项目分支上，由Jenkins自动编译。
如果编译错误会通过邮件反馈到影响代码的开发人员邮箱中，另外测试人员一键部署后，测试出问题，也可以通过jira提单给开发人员。开发人员收到后，继续提交代码，不再像我们之前，必须通知开发人员，开发人员本地打包，这样无法跟踪项目代码。
补充：
因为我们项目比较多，人为维护版本号会费时费力，我决定一期采用Jenkins自动填入版本号到项目中，并在文件名中体现，所以，项目编译出的包可能是1.war、2.war、3.war，我们内部将其（1、2、3）作为版本号，当然war包内部我也写入了版本号。
其次，我们剔除了大量含状态的代码，使得每个war在测试环境和生产环境自动加载不同配置来运行，因为无状态，所以war包、h5包在测试环境和生产环境都是一套代码。这里我们花了几周时间完成抽取无状态代码。
一键部署:
我们做了一套管理平台，可升级tomcat中间件下的各个war和h5。可以看看我们现在的效果：
主要功能如下：
1.升级、显示当前版本
2.对war包有效期，真实性校验
3.开发人员将公共sql放入公共.sql里
4.各个客户定制化需求的sql放入各个客户.sql里
每次只需要点后面的升级按钮，即可升级sql脚本或服务。
文章是之前写的，逻辑上有些变化，这里不做介绍。
客户端
客户端开发流程，这里ios和Android一起说，我们提交代码后，Jenkins都会同时生产两套连接服务器地址不同的ipa、apk，这里因为很多情况在不同网络环境下需要看测试环境和生产环境，所以，我采用同时发2套包方案。
Android的同时2套包方案可参照我之前Android利用gradle同时编译多包（测试环境地址、生产环境地址）IOS同时发2套ipa包方案可参照我之前的IOS利用Xcode同时编译多包（测试环境地址、生产环境地址）在ios上架appstore流程上，我采用了半自动化发包策略，将其上传到开发者平台后，手动上架。各个客户，各个版本我们采用多分支的方案，和上文java同理，不同分支处理不同客户项目。
测试组
测试组流程
测试人员从jira提单后，开发人员解决后，会看到具体解决的版本号，然后进入oss存储，安装Android程序，或者ios程序，一键部署java项目。
而因为安卓和ios均是同时发2个包，java项目、h5项目无状态，所以生产环境和测试环境都可快速部署测试。
图中，以real文件名结尾的是连接生产环境地址。
项目经理
项目经理流程
我采用新客户新流程，老客户老流程，并逐步迁移到新流程中。其中执行数据库脚本已经被省略，由统一部署平台执行。
运维组
这张图是以前的逻辑，因为每个时期，每个客户给的服务器和服务器系统各不相同，运维起来极为复杂。我采用docker容器统一方案解决此问题，使得每个客户机器环境均相同。
下图我是我解决后的模型图：
我们把各个客户的服务器都整成docker集群，然后通过我们公司统一管理平台管理，然后将各个容器分配给不同的角色，这里我们是用Portainer来解决，并二次开发了一些需求。
这里的管理都不需要linux机器的密码，通过tls证书进行控制，而Windows机器将废弃不用。
该方案优点：
1.在docker下，所有客户生产环境相同
2.易于备份、迁移、恢复
3.可建高可用环境，发包时采用灰度发包，蓝绿部署不中断服务
4.可支持弹性伸缩设计，支持扩展
5.支持负载均衡，域名转发，意外切换容器等
6.有利于转型微服务架构
7.快速搭建环境
而建立docker集群需要我们自动化完成，这里我采用了Ansible工具来实施，我们可通过指令分发，指令获取所有机器某个包的版本，执行不同的代码。
然后通过image镜像对客户进行统一部署容器，这里我们建立了私服。
私服篇
这里我建立了各种仓库，方便java开发，我建立了一个私有仓库，一个maven官方代理仓库，一个阿里云代理仓库；
docker上我为了方便开发打包其他环境，我创建了docker私有仓库；还有一些为了解决统一管理linux服务器而创建npm仓库；
以及安卓所要使用的gradle私有仓库，未来，我可能还会创建更多仓库，能支持的仓库列表都在下面：
大数据篇
大数据一直以来是很多公司核心产品，对于小公司，如何低成本实施呢，我研究了一套强大的大数据框架，并对其做了部分的二次开发。
接口篇
我全面统一采用restful风格api开发接口，接口文档自动生成，这里涉及几篇文章，暂时还没来得及写，后续补上。
|
