Android模块化项⽬模块版本控制及持续集成⽅案
分析
在使⽤模块化开发的过程中，模块的复⽤⾯临着同步的问题，既在A项⽬中修改了am模块，如何把修改同步到同样也在使⽤am模块的B项⽬中?在之前的模块化开发中这个问题是没有很好的解决的.在多个项⽬⼯程中通过复制，存在多份同⼀模块的实例.且分布在每个项⽬的svn仓库中，在某⼯程中修改am模块后只能通过拷贝的⽅法，把修改的代码复制到另⼀项⽬⼯程的am模块中,⾮常低效⽽且很容易出错.解决⽅案有2个:
1. 使⽤到am模块的项⽬⼯程不直接引⽤am模块的源代码,am模块的源码只在模块开发项⽬中存在⼀份,(功能模块在单独的项⽬中开发，因
为需要做到同级别的模块间充分解耦，所以这样功能模块的代码隔离是必要且必须的，业务模块?)，开发完成后，上传到maven私服给所有需要使⽤这个模块的项⽬提供依赖.
1. 优点:
1. 功能模块间的代码完全解耦.
2. 不能轻易修改实现代码.这即是优点也是缺点.
3. 使⽤aar格式依赖，编译速度得到很⼤提⾼.
2. 缺点:
1. 在功能模块尚未稳定的情况下，如需要修改功能模块的代码，需要另外到模块开发⼯程中，修改功能实现后，重新上传到maven,
使⽤功能模块的⼯程同步更新.步骤较为冗长，且功能开发⼯程的测试⽤例和实际使⽤⼯程的测试⽤例很⼤可能存在差异.导致
测试结果的不统⼀，提⾼⼆次修改的⼏率.在功能模块的初期版本和功能迭代期间.效率会⽐较低.
这是⽬前使⽤的⽅案.
2. 使⽤git管理功能模块源码及使⽤功能模块的客户⼯程.功能模块仍旧使⽤单独的模块开发，并使⽤单独的git仓库保存.使⽤git的⼦模块功
能引⽤添加该仓库为客户⼯程的⼦模块.功能模块的仓库只存在⼀份.多个客户项⽬共同使⽤，在⼦模块需要变更的时候直接修改客户⼯程中的⼦模块源码.开发完成后上传.⼦模块源码的修改会提交到⼦模块⾃⼰的仓库中，其他引⽤的客户⼯程更新即可.
1. 优点:
1. 功能模块修改效率⾼.⼀次修改多客户同步.
2. 缺点:
1. 客户⼯程仍旧需要编译⼦模块的源码.在模块数过多的时候，编译流程变长.
2. 可以⽅便的修改功能模块的源代码，在不能严格要求的情况下，容易产⽣"不好的修改".封闭性较弱.
3. 多客户⼯程的共同修改，可能会导致功能模块的代码冲突，冗余.虽然可以通过分⽀进⾏管理，但是学习成本和管理复杂度提⾼.解决⽅案
android retrofit以上⽅案各有优缺点.最好的⽅案应该是取其优者⽽从之.功能模块和客户⼯程仍旧使⽤git进⾏管理.但是客户⼯程⼀开始并不直接依赖功能模块的源代码.⽽是依赖现有功能模块的aar，在需要对现有功能模块进⾏修改的时候才动态的导⼊功能模块源码，进⾏修改，测试.⼀旦修改完成，仍旧将功能模块打包上传，修改客户⼯程依赖新版本的功能模块aar.充分保证编译效率的同时，减少功尽量能模块迭代期间造成的⾮预期BUG.在这⼀过程中，还会结合jenkins持续集成系统，在⼦模块修改完成后,push到仓库后触发,jenkins的构建,⾃动提⾼功能模块aar版本，构建完成后⾃动上传到maven私服，客户⼯程刷新依赖，获取到最新版的功能模块aar.
实现细节
搭建本地Git服务器
这⾥使⽤，安装到docker，配置⼀下就好了.有2点需要注意:
1. 端⼝映射：参照www.jianshu/p/d707f70c60d2
2. 添加hook不能使⽤本地地址，报 Url is blocked: Requests to the local network are not allowed ：需要使⽤初始的
admin@example登录,Settings > Outbound requests 将Allow requests to the local network from hooks and services 勾选.
提交现有功能模块到Git
1. 创建功能模块的git仓库，仓库名最好和模块名相同，为了保持包装⼯程的配置不变化.clone到⼀个空⽂件夹.
2. 从现有的svn服务器重新checkout Function Project，删除.svn⽂件夹, cut对应的Function module到clone的git⽂件夹中.修改
module的adle⽂件，包含
3. commit push
4. 所有模块push完成后，创建Function Project的git仓库，同样的⽅法处理Function Project剩余的⽂件.
5. 在Function Project的git版本根⽬录，添加⼦模块.
git submodule add 功能模块仓库地址功能模块相对路径
注意这⾥的路径需要与之前项⽬结构中的路径相同.添加完成后，根⽬录会⽣成.gitmodules⽂件，保存着⼦模块信息，需要添加到版本管理中.like this:
[submodule "otherLib/addresswheel"]
path = otherLib/addresswheel
url = admin@192.168.2.39:8443/r/addresswheel.git
6. 后续⼦模块和外部⼯程的修改都会提交到对应的仓库中,⼦模块也可供多处使⽤.
7. 要实现⼦模块的Jenkins构建的话，需要对模块的adle⽂件进⾏包装.
搭建Jenkins服务器
安装必要插件，需要注意的是，远程触发构建不成功的问题.是权限认证问题,Configure Global Security设置如下:
远程触发使⽤插件:[]，名字相关的都安装.
执⾏组件模块的uploadArchives即可完成构建上传.
安装，安装后可实现SDK⾃动下载.
因为组件模块是⼯程中的⼦模块，需要⼯程级别的adle⽂件的⽀持才能构建，上传后直接使⽤Jenkins构建是⽆法成功的.解决⽅法如下:
1. 在模块级别的adle⽂件中配置buildscript:
buildscript {
ext.kotlin_version = '1.2.60'
ext {
// App dependencies
supportLibraryVersion = '28.0.0'
compileSdkVersion = 28
buildToolsVersion = '28.0.3'
minSdkVersion = 16
targetSdkVersion = 22
guavaVersion = '18.0'
arouterApiVersion = '1.4.0'
arouterCompilerVersion = '1.2.1'
constraintLayoutVersion = '1.1.3'
butterknifeVersion = '8.5.1'
glideVersion = '4.8.0'
retrofitVersion = '2.3.0'
work_version = '1.0.0-alpha08'
}
repositories {
maven { url "192.168.2.39:8908/repository/maven-public/" }
dependencies {
classpath 'ls.build:gradle:3.1.3'
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
}
}
allprojects {
repositories {
maven { url "192.168.2.39:8908/repository/maven-public/" }
}
}
}
缺点是每个模块都需要单独配置，代码冗余且统⼀的依赖版本管理形同虚设.
2. 在Jenkins的服务器先创建Folder类型的项⽬，再在⾥⾯创建模块项⽬，形成层级:
Project addresswheel
Full project name: baseModule/addresswheel
addresswheel
⼿动在Jenkins服务器的/home/jenkins-home/workspace/baseModule⽬录下创建和⼯程⽬录下相同的⼯程级别adle和adle⽂件并在后续保持同步.需要上传的话还要创建adle
3. 配置Jenkins的模块项⽬构建过程如下:
4. 设置构建结果描述和GitLab关联:
1. 安装插件:
2. Configure Global Security->Markup Formatter 选择Safe HTML
3. 项⽬设置如下:
ONEs集成

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。