为了这篇文章,我前后写了将近十篇文章铺垫,才将这篇整体重构思想引出。

背景

先说下背景,我们是一家小公司,虽然打着做产品的旗帜,但是每个客户都有大量的个性化功能,这里指各个客户的java端、Android端、ios端(大部分功能代码是相同的,个性化功能代码不同)。我之前是做Android的,实践证明,特殊情况下,只有我们Android组可以随意切换到任意一家客户,任意一版本的代码。并且修复一处公共bug,所有客户的版本都会更新。我也一直在介绍这种开发模式,但并得不到支持,直到年初,我晋升为移动端组长,加上,后来java组组长跳槽,我才有机会全面实施重构计划。

前言

因为我做过很多年的运维(网吧软硬件运维等),对服务器硬件以及软件有较高的认识,加之我对各门语言有一定的开发经验,算是一位全栈工程师,对各端都比较熟悉。这一切,为我的实施带来了很大的帮助。
本人申明以下所有重构思路均出自本人想法,实施上,由我统一安排培训后落实。(虽然落实阻力极大,但最终效果不错)

先说说效果

之前,我们每接入一个客户项目,完成java端、Android端、ios端和部署服务器环境等,需要2周的时间。现在,我们大概需要30分钟。并且每位客户个性化需求再多,我们也能灵活开发及切换到各个客户的代码上。
之前,我们开发流程极为混乱,没有文档,没有各种开发流程,现在我们逐渐规范,至少节约50%的开发成本。当然,我们还在不断改善中。

java项目组

我们的java项目,原来分为接口服务、后台管理服务,但是都在一个git库里,我将它分为:
1. 接口服务
2. 后台服务
3. html5包
4. 公共包服务

因为本次重构,我逐步采用前后端分离方案,所以多出了h5包。

我是如何重构整个研发项目,促进自动化运维DevOps的落地?

每个库分为多个分支,其中定义master为主分支,各个客户为新开的一个分支,通过分支来解决各个客户各种不同需求,(因为客户需求实在过细,有些文字都得改,单纯的插件化开发的话,每个插件都要n多个版本,这样对于我们小公司,做不起来),当然各个客户也应该有个开发分支,但受限于我们人员较少,一期省去了开发分支,把本地暂存区作为开发分支。
关于如何在不同分支开发,可参照我另外一篇文章
《你确定你能记住那么多的git命令吗?快试试Sourcetree吧》

开发流程如下:
我是如何重构整个研发项目,促进自动化运维DevOps的落地?

开发人员只需要本地调试后,提交代码到git库的某个项目分支上,由Jenkins自动编译,关于Jenkins自动编译全端项目可参照我另外一篇文章
某小型公司持续集成工具jenkins实践(JAVA WEB、Android、IOS、html)
如果编译错误会通过邮件反馈到影响代码的开发人员邮箱中,另外测试人员一键部署后,测试出问题,也可以通过jira提单给开发人员。开发人员收到后,继续提交代码,不再像我们之前,必须通知开发人员,开发人员本地打包,这样无法跟踪项目代码。

补充:
因为我们项目比较多,人为维护版本号会费时费力,我决定一期采用Jenkins自动填入版本号到项目中,并在文件名中体现,所以,项目编译出的包可能是1.war、2.war、3.war,我们内部将其(1、2、3)作为版本号,当然war包内部我也写入了版本号。
其次,我们剔除了大量含状态的代码,使得每个war在测试环境和生产环境自动加载不同配置来运行,因为无状态,所以war包、h5包在测试环境和生产环境都是一套代码。这里我们花了几周时间完成抽取无状态代码。

一键部署:
我们做了一套管理平台,可升级tomcat中间件下的各个war和h5,相关介绍见我另外一篇文章
java web项目war包自动升级部署方案
可以看看我们现在的效果:

我是如何重构整个研发项目,促进自动化运维DevOps的落地?

主要功能如下:
1. 升级、显示当前版本
2. 对war包有效期,真实性校验
2. 开发人员将公共sql放入公共.sql里
3. 各个客户定制化需求的sql放入各个客户.sql里

每次只需要点后面的升级按钮,即可升级sql脚本或服务。
文章是之前写的,逻辑上有些变化,这里不做介绍。

客户端组

客户端开发流程,这里ios和Android一起说,我们提交代码后,Jenkins都会同时生产两套连接服务器地址不同的ipa、apk,这里因为很多情况在不同网络环境下需要看测试环境和生产环境,所以,我采用同时发2套包方案。
我是如何重构整个研发项目,促进自动化运维DevOps的落地?
Android的同时2套包方案可参照我之前
Android利用gradle同时编译多包(测试环境地址、生产环境地址)
IOS同时发2套ipa包方案可参照我之前的
IOS利用Xcode同时编译多包(测试环境地址、生产环境地址)
在ios上架appstore流程上,我采用了半自动化发包策略,将其上传到开发者平台后,手动上架。
各个客户,各个版本我们采用多分支的方案,和上文java同理,不同分支处理不同客户项目。

测试组

测试组流程

我是如何重构整个研发项目,促进自动化运维DevOps的落地?
测试人员从jira提单后,开发人员解决后,会看到具体解决的版本号,然后进入oss存储,安装Android程序,或者ios程序,一键部署java项目。
而因为安卓和ios均是同时发2个包,java项目、h5项目无状态,所以生产环境和测试环境都可快速部署测试。
图中,以real文件名结尾的是连接生产环境地址。

项目经理

项目经理流程

我是如何重构整个研发项目,促进自动化运维DevOps的落地?
我采用新客户新流程,老客户老流程,并逐步迁移到新流程中。
其中执行数据库脚本已经被省略,由统一部署平台执行。

运维组

我是如何重构整个研发项目,促进自动化运维DevOps的落地?
这张图是以前的逻辑,因为每个时期,每个客户给的服务器和服务器系统各不相同,运维起来极为复杂。我采用docker容器统一方案解决此问题,使得每个客户机器环境均相同。
下图我是我解决后的模型图:

我是如何重构整个研发项目,促进自动化运维DevOps的落地?
我们把各个客户的服务器都整成docker集群,然后通过我们公司统一管理平台管理,然后将各个容器分配给不同的角色,这里我们是用Portainer来解决,并二次开发了一些需求。
详细可看我另外一篇文章
Docker的web端管理平台对比(DockerUI 、Shipyard、Portainer、Daocloud)
这里的管理都不需要linux机器的密码,通过tls证书进行控制,而Windows机器将废弃不用。

该方案优点:
1. 在docker下,所有客户生产环境相同。
2. 易于备份、迁移、恢复。
3. 可建高可用环境,发包时采用灰度发包,蓝绿部署不中断服务。
4. 可支持弹性伸缩设计,支持扩展。
5. 支持负载均衡,域名转发,意外切换容器等。
6. 有利于转型微服务架构。
7. 快速搭建环境

而建立docker集群需要我们自动化完成,这里我采用了Ansible工具来实施,我们可通过指令分发,指令获取所有机器某个包的版本,执行不同的代码。
详细参照我另外一篇文章:
自动化运维工具ansible的实践

然后通过image镜像对客户进行统一部署容器,这里我们建立了私服。

私服篇

这里我建立了各种仓库,方便java开发,我建立了一个私有仓库,一个maven官方代理仓库,一个阿里云代理仓库;
docker上我为了方便开发打包其他环境,我创建了docker私有仓库;
还有一些为了解决统一管理linux服务器而创建npm仓库;
以及安卓所要使用的gradle私有仓库;
未来,我可能还会创建更多仓库,能支持的仓库列表都在下面:

我是如何重构整个研发项目,促进自动化运维DevOps的落地?
详细可参照我另外一篇文章
利用nexus构建maven、docker、npm、gradle私服仓库

大数据篇

大数据一直以来是很多公司核心产品,对于小公司,如何低成本实施呢,我研究了一套强大的大数据框架,并对其做了部分的二次开发。
详细可参照另外一篇文章
https://juejin.im/post/596702f7f265da6c23289373
放心吧,只要你用了这个框架,一定可以轻松解决各种大数据图表问题。

接口篇

我全面统一采用restful风格api开发接口,接口文档自动生成,这里涉及几篇文章,暂时还没来得及写,后续补上。

规范篇

我还制定了一些规范和约定,比如内部开发协作等约定,暂时还没写完,后期我也会补上。

文化篇

之前,我们开发需求完全依靠项目经理分配,现在我安排不断重构项目,带来了很多新的流程,这里征得领导同意,安排每周或每2周分别对各部门,培训后分配账号,实施。这个涉及公司内部业务,不便详说,敬请谅解。

DevOps的落地

DevOps这个词,是我上次在上海CNUTCon全球运维技术大会2017会上所知,我才知道大部分公司都在做自动化运维,缩减运维工作。
关于这方面,我也写了2篇文章,可参照
[Day 1]上海CNUTCon全球运维技术大会2017实录
[Day 2]上海CNUTCon全球运维技术大会2017实录
在文章中,我融入了不少自己的想法。
当然,适合我们公司DevOps的落地方案已经实施一大半了,剩下的我还在努力设计蓝图中。以后一定会和大家分享。

后续

我写了几个月各方面的文章,大部分读者可能以为我是胡写一通。今天,终于把他们汇聚到一起,说实话,心情还是蛮激动的。

我承认我所有的重构对于很多大公司都是提不上台面的,但对于我们小公司,很多东西形成体系,说实话,真的很难。还有些内容,我不方便说,或者是忘记了说。事实上,我们做的远比文章里的内容要多得多。
还有,部分文章可能是几个月前写的,逻辑上和流程上,我们都已经做了很多优化和调整,但是主体思想都没有变,不影响阅读。

其次,我申明,本文中所有介绍,绝对不是最好的解决方案,很多方案是我对公司进行分析后定下的,绝不是每个小公司都适合。但我觉得本文一定能给你带来不少的灵感。

最后,本人能力有限,开发圈子也比较小,难免有考虑不周的地方,如果您有任何高见,欢迎告知,小生在此谢过大家。

觉得好的话,记得关注我哦!
掘金:
https://juejin.im/user/57cd55218ac247006459c40c

分类:

技术点:

相关文章: