专栏首页DevOps时代的专栏我是这样重构整个研发项目,促进自动化运维DevOps的落地?

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

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

背景

先说下背景,我们是一家小公司,虽然打着做产品的旗帜,但是每个客户都有大量的个性化功能,这里指各个客户的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开发接口,接口文档自动生成,这里涉及几篇文章,暂时还没来得及写,后续补上。

文化篇

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

后续

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

我承认我所有的重构对于很多大公司都是提不上台面的,但对于我们小公司,很多东西形成体系,说实话,真的很难。还有些内容,我不方便说,或者是忘记了说。事实上,我们做的远比文章里的内容要多得多。

还有,部分文章可能是几个月前写的,逻辑上和流程上,我们都已经做了很多优化和调整,但是主体思想都没有变,不影响阅读。

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

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

作者:邵磊 链接:https://juejin.im/post/59e1d92d51882578db27c2e1

本文分享自微信公众号 - DevOps时代(DevOpsTimes),作者:邵磊

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-12-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 基于DevOps、微服务以及k8s的高可用架构探索与实现

    前言 本文给大家分享的题目是《基于DevOps、微服务以及K8S的高可用架构探索与实现》。整个企业的高可用架构面临很多的挑战,面向微服务、容器化以及敏态交付,是...

    DevOps时代
  • 荷兰 ING 银行从敏捷到 DevOps 的进阶之路

    一、ING 介绍 ? ING 是一个总部位于欧洲荷兰的银行。我们有450多个运维开发的团队,全面服务于银行业。 ? 在 ING,IT 的角色从服务转向到战略上,...

    DevOps时代
  • 一篇文章学会使用 gitk,排查 Git 问题就靠它了

    现在软件开发已经离不开版本控制系统。版本控制系统不仅能保留每个文件所有版本的历史信息,还能够方便查找。另外,也能够让团队协作不受空间和时间的限制。

    DevOps时代
  • Web系统权限控制如何设计

    这篇文章的定位,不是宣传某个框架,仅仅之是梳理一下有关权限方面的一些想法和最近项目中的一些探索过程。 我们主要想解决一下问题。

    黄泽杰
  • 权限设计的一些想法和思考

    来源:my.oschina.net/cloudcross/blog/1920706

    Java团长
  • 使用二进制进行权限控制

    使用二进制进行权限控制,可减少程序的逻辑判断以及提升效率,linux系统的777权限原理也是通过2进制进行判断的

    仙士可
  • Mac环境下安装启动Tomcat

    JavaEdge
  • Altium designer 同一个工程中把多个原理图的相同网络编号关联起来

    选择project--project options --options,按下图操作:

    小火柴棒
  • 回溯法思想(剑指Offer 65/66)

    请设计一个函数,用来判断在一个矩阵中是否存在一条包含某字符串所有字符的路径。路径可以从矩阵中的任意一个格子开始,每一步可以在矩阵中向左,向右,向上,向下移动一个...

    算法工程师之路
  • 剑指offer 机器人的运动范围

    版权声明:本文为博主-姜兴琪原创文章,未经博主允许不得转载。 https://blog.cs...

    week

扫码关注云+社区

领取腾讯云代金券