请选择 进入手机版 | 继续访问电脑版
查看: 385|回复: 0

云信UIKit自定义后独立于云信的版本管理方案

[复制链接]

1

主题

1

帖子

11

积分

云客

Rank: 1

积分
11
发表于 2018-7-24 19:52:04 | 显示全部楼层 |阅读模式
本帖最后由 pirate6 于 2018-7-24 19:55 编辑

原文地址:[url]http://blog.pirate6.com/2018/07/23/yx-im-scheme/[/url]
前言读者视角本文以iOS PG为第一视角编辑,默认读者了解CocoaPods的使用、私有库以及私有库如何进行版本控制。
业务复杂度关于业务复杂度的描述,由于涉及到公司业务,在此不会表述公司具体业务,通过其他表述来描述项目复杂度,复杂度主要体现在:
* 群组 —— 分为多种类型,* 群组成员 —— 具有多种角色,不同角色具备不同的操作权限* 自定义消息 —— 多种,并且展示不同,并具备单独的未读状态* 用户 —— 更多的用户信息* 公告 —— 避免使用接口的延迟性,达到时效* ...对于产品大大们能规划、设计出这么多神奇的功能,有种的佩服。但是作为一名搬砖工一定要使用一个易于维护方案,不然以后每天的工作就是挖坑、埋土了…

云信渠道技术调研业务调研在迁移之前做了下技术层面的调研,确保能满足所有业务需求。下图取自云信文档的云信架构图,图中介绍了云信的通信机制。


经过调研,发现云信支持用户信息自定义、群信息自定义、群成员信息自定义以及发送自定义消息,这完全能满足所有需求。同时云信提供了一套IM-UI库,可以直接拿来用(建议使用)。
UI调研UI迁移方案有如下两种,
方案一:直接在云信提供的`IM-UI`基础上增加业务修改;方案二:在原项目的`IM-UI`基础上替换socket的代理;相比之下方案一成本更低,且出错率更低,而且方案二有在测试阶段不易易识别隐藏bug的风险。故决定采用方案二进行迁移。

云信渠道分析云信IM服务渠道,对于自有项目来说算是外部资源。应该考虑其单独版本控制问题,例如:新版本有问题,可以在自有项目中依赖相对老的版本。
云信SDK云信UI都可基于CocoaPods进行版本管理。但是基于业务、UED团队的需求,云信UI这个库一定是要修改,所以版本控制不能直接依赖云信的UI仓库,要通过镜像的方式去管理UI库的版本。

UI仓库开发及版本控制规划什么是镜像什么是镜像?小时候用windows转系统的镜像类比一下,懂了吧。简单理解就是基于模板copy的一个压缩备份。
如何通过镜像的方式去管理UI库的版本通过镜像的方式去管理UI库的版本,首先应建立一个本地两个远端仓库的关系。第一步,通过git clone工具将云信UI仓库克隆到本地;第二步,通过git add remote工具添加自己的git远端仓库。
接下来需要以自己的私有git仓库建立CocoaPods私有库,打包上传的时候依赖该私有库,便可达到控制版本目的,比如实现IM模块单独回滚到上一个minor版本。
实际的代码数据流向如下图。只从云信的UI仓库拉取,获取云信的最新功能的UI支持。在本地进行开发,并上传至私有git仓库。验收通过合并到master分支,并打tag以用于CocoaPods进行控制版本。



总结通过镜像的方式去管理UI库的版本,缺点是体力工作量稍微增多了一些;优点是降低耦合度,提高了风险应对能力。比如产品需求新增IM功能,在开发一段时间后,由于市场及业务原因不需要这个功能了,不需要手动去删除代码,直接版本回滚即可。而且这样做可以利用git workflow的所有优秀特性哟。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表