摘要:所以在此给大家分享一下不使用构建工具实现项目自动化打包发布的思路。对于一个前端项目来说,自动化的构建是很有必要的,同时我们也可以通过实现更多的功能比如代码检测,单元测试等等。另外这种思路同样适用于其他项目等前端项目,等移动端项目。
今天这篇文章的目的是在rn项目的构建,并不会涉及到rn框架或者使用的讲解,说起构建,特别是前端构建大家应该很快会想到webpack、Grunt、 Gulp等。而这些工具在rn项目中就显得有些鸡肋。所以在此给大家分享一下不使用构建工具实现rn项目自动化打包发布的思路。
gitlab
docker
1.GitLab CI是 GitLab 提供的持续集成服务,只要在你的仓库根目录 创建一个.gitlab-ci.yml 文件, 并为该项目指派一个Runner,当有合并请求或者 push的时候就会触发build。
这个.gitlab-ci.yml 文件定义GitLab runner要做哪些操作。 默认有3个[stages(阶段)]: build、test、deploy。
更详细的可以查看官方文档
2.GitLab-Runner是配合GitLab-CI进行使用的。一般地,GitLab里面的每一个工程都会定义一个属于这个工程的软件集成脚本,用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时,比如有人push了代码,GitLab就会将这个变动通知GitLab-CI。这时GitLab-CI会找出与这个工程相关联的Runner,并通知这些Runner把代码更新到本地并执行预定义好的执行脚本。
所以,GitLab-Runner就是一个用来执行软件集成脚本的东西。你可以想象一下:Runner就像一个个的工人,而GitLab-CI就是这些工人的一个管理中心,所有工人都要在GitLab-CI里面登记注册,并且表明自己是为哪个工程服务的。当相应的工程发生变化时,GitLab-CI就会通知相应的工人执行软件集成脚本。如下图所示:
3.Pipelines是定义于.gitlab-ci.yml中的不同阶段的不同任务。
我把Pipelines理解为流水线,流水线包含有多个阶段(stages),每个阶段包含有一个或多个工序(jobs),比如先购料、组装、测试、包装再上线销售,每一次push或者MR都要经过流水线之后才可以合格出厂。而.gitlab-ci.yml正是定义了这条流水线有哪些阶段,每个阶段要做什么事
build_apk_release: stage: test when: manual variables: GIT_SUBMODULE_STRATEGY: recursive environment: Development script: - zsh build.sh android Release "" artifacts: expire_in: 2 hrs paths: - K*.apk only: - /^master$|^branch/*|^release/*/ tags: - mac-shell cache: paths: - node_modules/
关键代码script,其实就是指向我们真正的打包脚本build.sh
funBundle(){ echo $1 echo $2 echo $3 funWithInit case $1 in "iOS") funWithiOS $2 ;; "android") funWithAndroid $2 $3 ;; "apks") funWithAndroidApks ;; *) echo "not mismatchimg" esac } funBundle $1 $2 $3
找到对应的funWithAndroid代码
funWithAndroidApks(){ apkClear for flavor in kuaibao huawei 360helper yingyongbao aliyun baidu xiaomi meizu uc jifeng sougou oppo vivo yiyonghui chuizi 91helper anzhi wandoujia mumayi yingyonghui anzhuo lianxiang huawei oppo vivo yiyonghui chuizi yiyou; do pushd android && ./gradlew "assemble${flavor}Release" && popd done gradle --stop cp android/app/build/outputs/apk/apk/release/*.apk ~/Documents/Apks/ gitClear }
funWithAndroid(){ apkClear assembleName="assemble$1$2" echo assembleName pushd android && ./gradlew --no-daemon ${assembleName} && popd cp -r android/app/build/outputs/apk/*.apk . assembleApk=`ls *.apk` if [ "$1"x = "Release"x ]; then pushApp ${assembleApk} fi gitClear } }
pushApp(){ apiKey="cd61f47742ae6d80****************" uKey="21607fc*********************" curl -F "file=@$1" -F "uKey=$uKey" -F "_api_key=$apiKey" https://www.pgyer.com/apiv1/**** }
脚本代码很简单,利用gradlew进行打包,通过最后一段代码上传至蒲公英
这样一个自动打包上传脚本编写完成。ios可参照。
build_hot_fix_stag: stage: test when: manual script: - yarn config set registry https://registry.npm.taobao.org - yarn config set disturl https://npm.taobao.org/dist - yarn install - zsh autoppk.sh both Staging only: - /^master$|^branch/*|^release/*/ tags: - mac-shell cache: paths: - node_modules/
同样还是找重点,script中进行了3个步骤(npm/yarn)
设置淘宝镜像源
安装依赖
执行autoppk.sh脚本
#!/bin/bash #read env echo "正在准备发布热更新..." bundle(){ node packppk.js "****" $1 $2 } clean(){ echo "delete react-native-packager-cache" rm -rf ./react-native-packager-cache-* } funBundle(){ bundle $1 $2 } funBundle $1 $2 #clean
var codepushReleaseReact = require("./release-react") var updateConfig = require("./update") function bundle() { console.log("玩命打包中 ......") const appName = process.argv[2] || "app" const platform = process.argv[3] || "both" const deploymentName = process.argv[4] || "Staging" console.log("platform:" + platform) console.log("deploymentName:" + deploymentName) switch (platform) { case "both": console.log("开始打包双平台") codepushReleaseReact({ ...updateConfig.ios, deploymentName }, "ios", appName) codepushReleaseReact({ ...updateConfig.android, deploymentName }, "android", appName) break default: } } bundle()
function reactNativeRelease (argv, platform, name) { return [ "code-push", "release-react", appName(name, platform), platform, `-d "${argv.deploymentName}"`, `--des "${argv.description}"`, `--dev ${argv.development}`, `-m ${argv.mandatory}`, targetBinary(argv.targetBinary) ].join(" ") }
至此rn热更打包,自动上传就已经完成了,相信了解过code-push的同学应该很容易理解脚本的含义,在实际项目中写完脚本并不算真正的结束,我们要利用脚本实现自动化,解放双手
将我们写好的脚本部署到gitlab说到脚本的部署其实gitlab已经帮我们做好了,当我们在项目中创建gitlab-ci.yml时,部署工作就算完成,剩下的就是编写具体的job,而我们编写好的job具体实现就得靠文章一开始所提到的Runner。
当我们push项目,或者创建merge request的时候会触发对应的CI pipeline,从而开始让runner执行我们提前编写好的job。
对于一个前端项目来说,自动化的构建是很有必要的,同时我们也可以通过gitlab实现更多的功能比如eslint/Flow代码检测,单元测试等等。利用脚本实现一些机械工作,提高工作效率。
另外这种思路同样适用于其他项目vue、react等前端项目,Android、ios等移动端项目。区别只是在于如何利用各自的资源。
文章可能有很多不足的地方,希望大家指正,同时也希望大家可以多多交流,分享出更多的技术方案,谢谢~~
技术交流群:581621024
关注小编 公众号:LearningTech
每日更新前端技术
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/95487.html
阅读 2571·2023-04-26 00:07
阅读 2379·2021-11-15 11:37
阅读 614·2021-10-19 11:44
阅读 2136·2021-09-22 15:56
阅读 1690·2021-09-10 10:50
阅读 1479·2021-08-18 10:21
阅读 2547·2019-08-30 15:53
阅读 1608·2019-08-30 11:11