ミニプログラム:自動展開スキーム

アプレットにCI / CDを統合することで、リリースプロセスとバージョン管理のエクスペリエンスを向上させることができます。

主に次の利点があります。

  1. アプレットのリリースバージョンは、gitlabのコードバージョンと一致している必要があります
  2. リリース効率を向上させるために、マルチプレイヤー開発中にエクスペリエンスバージョンを頻繁に切り替える必要性を解決します
  3. オンラインの事前レビューバージョンの後に試用版に戻す問題を解決します
  4. 合意された小さなプログラムバージョンの命名規則に従って、特定のコードバージョンを追跡できます

統合されたCI / CDのアイデア

  1. パッケージアプレット
  2. アプレットによって公式に提供されたminiprogram-ciのscriptcallメソッドの助けを借りて、対応するリリーススクリプトを実行するためにgitlabciと組み合わせます。
    a。スクリプトを実行するときは、バージョンパラメータを渡し、リリースロボットを指定し、説明を説明する必要があります(ここでは説明としてコミットメッセージを使用します)

ここに画像の説明を挿入します

統合開発およびリリースモデル

  1. アルファ版のリリース:コードは自動リリースのためにテストブランチに送信されます(リリースの説明としてコミットメッセージが使用されます)。デフォルトでは、このブランチに設定されているロボットはエクスペリエンスバージョンであり、切り替える必要はありません。複数のリリースのエクスペリエンスバージョン。
  2. ベータ版を公開する:テストコードをプレビューブランチにマージし、自動的にパッケージ化して送信します。このブランチに設定されているロボットはベータ版であり、WeChatパブリックプラットフォームでのレビューのために送信する必要があります。レビューに合格したら、管理者は、それがベータ版であり、グレースケールでリリースされていることを確認します。
  3. 公式バージョンのリリース:テスト/プレビューコードをマスターブランチにマージし、自動的にパッケージ化して送信します。このブランチに設定されたロボットは公式バージョンであり、WeChatパブリックプラットフォームでのレビューのために送信する必要があります。レビューに合格した後、管理者はオンラインバージョンを確認し、全額リリースを実行します。
    開発時に、WeChat開発者ツールにコードをアップロードする必要はありません。
    WeChatパブリックプラットフォームのバージョン管理では、ロボットによってリリースされたバージョンのみを表示でき、個人から送信されたバージョンはこれ以上ありません。
    ここに画像の説明を挿入します

統合手順

1.miniprogram-ciをインストールします

npm i miniprogram-ci -D

2.ci.jsリリーススクリプトファイルを準備します

const ci = require('miniprogram-ci')

// gitlab-runner执行脚本时,传进来的参数
var params = process.argv.splice(2)
var version = params[0]
var robot = parseInt(params[1])
var desc = params.splice(2).join(' ')

// appid 和privateKeyPath需要设置下
const project = new ci.Project({
    
    
  appid: '',
  type: 'miniProgram',
  projectPath: './',
  privateKeyPath: './ci-private.key',
  ignores: ['node_modules/**/*', 'src/**/*']
})

/** 上传 */
async function upload({
    
     version = '0.0.0', desc = 'test', robot = 1 }) {
    
    
  await ci.upload({
    
    
    project,
    version,
    desc,
    setting: {
    
    
      es7: true,
      minify: true,
      autoPrefixWXSS: true
    },
    robot,
    onProgressUpdate: console.log
  })
}

upload({
    
     version, desc, robot })

その他のリリース設定については、公式ドキュメントを参照してください

3.キーファイル

特定の場所は、アプレット管理プラットフォーム、開発->開発設定->アプレットコードアップロード->アプレットコードアップロードキーです。
図に示すように、生成されたキーファイルをプロジェクトのルートディレクトリに配置します。
注:アプレットの管理者のみがキーファイルを生成する権限を持っています。
ここに画像の説明を挿入します

4.IPホワイトリスト

ここにIPホワイトリストを追加すると、指定したIPでアップロードスクリプトを実行できます。
ここに画像の説明を挿入します

5..gitlab-ci.ymlリリースファイル

テストブランチはエクスペリエンスバージョンをリリースするブランチであり、プレビューブランチはベータバージョンをリリースするブランチであり、マスターブランチは公式バージョンをリリースするブランチであることに同意します。ベータ版と公式版はどちらもオンライン環境に対応し、アルファ版はテスト環境に対応しているため、パッケージ化コマンドは異なります。npmrunbuildとnpmrun build:testです。パッケージ化コマンドは次のようにする必要があります。 package.jsonでサポートされています。
gitlab-runnerでリリーススクリプトを実行し、必要なパラメーターを渡します。
注:新しいバージョンを開発するたびに、バージョン番号を手動で変更する必要があります。

# test、preview和master分支默认支持线上部署

stages:
  - build
  - deploy

# 小程序版本设置,每次开发新版本需要手动更新
variables:
  PROJECT_VERSION: 1.0.0

# 安装依赖&&构建打包
build test:
  stage: build
  only:
    - test
  tags:
    - f2e
  script:
    - cnpm i
    - npm run build:test
    - node ci.js $PROJECT_VERSION.$CI_COMMIT_SHORT_SHA.alpha 1 $(git log -1 --pretty=%B)

build preview:
  stage: build
  only:
    - preview
  tags:
    - f2e
  script:
    - cnpm i
    - npm run build
    - node ci.js $PROJECT_VERSION.beta 2 $(git log -1 --pretty=%B)

build prd:
  stage: build
  only:
    - master
  tags:
    - f2e
  script:
    - cnpm i
    - npm run build
    - node ci.js $PROJECT_VERSION 3 $(git log -1 --pretty=%B)

package.json

{
    
    
	...
  "scripts": {
    
    
    ...
    "build": "cross-env NODE_ENV=production ./node_modules/.bin/wepy build --no-cache",
    "build:test": "cross-env NODE_ENV=test ./node_modules/.bin/wepy build --no-cache",
		...
  },
  ...
}

おすすめ

転載: blog.csdn.net/weixin_43972437/article/details/113448724