摘要：所以在此給大家分享一下不使用構(gòu)建工具實(shí)現(xiàn)項(xiàng)目自動(dòng)化打包發(fā)布的思路。對于一個(gè)前端項(xiàng)目來說，自動(dòng)化的構(gòu)建是很有必要的，同時(shí)我們也可以通過實(shí)現(xiàn)更多的功能比如代碼檢測，單元測試等等。另外這種思路同樣適用于其他項(xiàng)目等前端項(xiàng)目，等移動(dòng)端項(xiàng)目。

今天這篇文章的目的是在rn項(xiàng)目的構(gòu)建，并不會(huì)涉及到rn框架或者使用的講解，說起構(gòu)建，特別是前端構(gòu)建大家應(yīng)該很快會(huì)想到webpack、Grunt、 Gulp等。而這些工具在rn項(xiàng)目中就顯得有些雞肋。所以在此給大家分享一下不使用構(gòu)建工具實(shí)現(xiàn)rn項(xiàng)目自動(dòng)化打包發(fā)布的思路。

涉及到的工具

gitlab

docker

相關(guān)概念

1.GitLab CI是 GitLab 提供的持續(xù)集成服務(wù)，只要在你的倉庫根目錄 創(chuàng)建一個(gè).gitlab-ci.yml 文件， 并為該項(xiàng)目指派一個(gè)Runner，當(dāng)有合并請求或者 push的時(shí)候就會(huì)觸發(fā)build。
這個(gè).gitlab-ci.yml 文件定義GitLab runner要做哪些操作。 默認(rèn)有3個(gè)[stages(階段)]: build、test、deploy。
更詳細(xì)的可以查看官方文檔

2.GitLab-Runner是配合GitLab-CI進(jìn)行使用的。一般地，GitLab里面的每一個(gè)工程都會(huì)定義一個(gè)屬于這個(gè)工程的軟件集成腳本，用來自動(dòng)化地完成一些軟件集成工作。當(dāng)這個(gè)工程的倉庫代碼發(fā)生變動(dòng)時(shí)，比如有人push了代碼，GitLab就會(huì)將這個(gè)變動(dòng)通知GitLab-CI。這時(shí)GitLab-CI會(huì)找出與這個(gè)工程相關(guān)聯(lián)的Runner，并通知這些Runner把代碼更新到本地并執(zhí)行預(yù)定義好的執(zhí)行腳本。

所以，GitLab-Runner就是一個(gè)用來執(zhí)行軟件集成腳本的東西。你可以想象一下：Runner就像一個(gè)個(gè)的工人，而GitLab-CI就是這些工人的一個(gè)管理中心，所有工人都要在GitLab-CI里面登記注冊，并且表明自己是為哪個(gè)工程服務(wù)的。當(dāng)相應(yīng)的工程發(fā)生變化時(shí)，GitLab-CI就會(huì)通知相應(yīng)的工人執(zhí)行軟件集成腳本。如下圖所示：

3.Pipelines是定義于.gitlab-ci.yml中的不同階段的不同任務(wù)。
我把Pipelines理解為流水線，流水線包含有多個(gè)階段（stages），每個(gè)階段包含有一個(gè)或多個(gè)工序（jobs），比如先購料、組裝、測試、包裝再上線銷售，每一次push或者M(jìn)R都要經(jīng)過流水線之后才可以合格出廠。而.gitlab-ci.yml正是定義了這條流水線有哪些階段，每個(gè)階段要做什么事

編寫gitlab—ci (以Android打包為例)

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/

關(guān)鍵代碼script，其實(shí)就是指向我們真正的打包腳本build.sh

編寫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

找到對應(yīng)的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進(jìn)行打包，通過最后一段代碼上傳至蒲公英
這樣一個(gè)自動(dòng)打包上傳腳本編寫完成。ios可參照。

接下來我們來看看如何利用ci實(shí)現(xiàn)rn的熱更打包，自動(dòng)上傳（這里使用code-push來實(shí)現(xiàn)熱更，服務(wù)端是小編自己搭建的，后期可以分享給大家）

編寫gitlab—ci 實(shí)現(xiàn)打包入口

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/

同樣還是找重點(diǎn)，script中進(jìn)行了3個(gè)步驟(npm/yarn)

設(shè)置淘寶鏡像源

安裝依賴

執(zhí)行autoppk.sh腳本

編寫打包腳本 autoppk.sh

#!/bin/bash
#read env
echo "正在準(zhǔn)備發(fā)布熱更新..."
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

packppk.js

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("開始打包雙平臺(tái)")
      codepushReleaseReact({
        ...updateConfig.ios,
        deploymentName
      }, "ios", appName)
      codepushReleaseReact({
        ...updateConfig.android,
        deploymentName
      }, "android", appName)
      break
    default:
  }
}

bundle()

codepushReleaseReact

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熱更打包，自動(dòng)上傳就已經(jīng)完成了，相信了解過code-push的同學(xué)應(yīng)該很容易理解腳本的含義，在實(shí)際項(xiàng)目中寫完腳本并不算真正的結(jié)束，我們要利用腳本實(shí)現(xiàn)自動(dòng)化，解放雙手

說到腳本的部署其實(shí)gitlab已經(jīng)幫我們做好了，當(dāng)我們在項(xiàng)目中創(chuàng)建gitlab-ci.yml時(shí)，部署工作就算完成，剩下的就是編寫具體的job，而我們編寫好的job具體實(shí)現(xiàn)就得靠文章一開始所提到的Runner。

當(dāng)我們push項(xiàng)目，或者創(chuàng)建merge request的時(shí)候會(huì)觸發(fā)對應(yīng)的CI pipeline，從而開始讓runner執(zhí)行我們提前編寫好的job。

對于一個(gè)前端項(xiàng)目來說，自動(dòng)化的構(gòu)建是很有必要的，同時(shí)我們也可以通過gitlab實(shí)現(xiàn)更多的功能比如eslint/Flow代碼檢測，單元測試等等。利用腳本實(shí)現(xiàn)一些機(jī)械工作，提高工作效率。

另外這種思路同樣適用于其他項(xiàng)目vue、react等前端項(xiàng)目，Android、ios等移動(dòng)端項(xiàng)目。區(qū)別只是在于如何利用各自的資源。

文章可能有很多不足的地方，希望大家指正，同時(shí)也希望大家可以多多交流，分享出更多的技術(shù)方案，謝謝～～

技術(shù)交流群:581621024
關(guān)注小編 公眾號(hào)：LearningTech
每日更新前端技術(shù)