[CI] モジュールリリース方法の設計と実装 │ Find out by JURABI

1. 要件
2. 設計
3. 実装
4. 振り返り

要件

npmモジュールをビルドして、Azureへプッシュする
ビルドツールとして、jenkinsを用いる

設計

Azureは、同バージョンのパッケージをリリースできないので、package.jsonのバージョンの差分を確認して、差分がないときは、リリースしないようにする。
開発と運用を切り離すことを目的として、パッケージが増えてもコードの修正をしなくて済むように、特定のディレクトリ下のパッケージをリリースするようにする。
ディレクトリ構成は、以下を想定。jenkinsfileの実行はrootから行われる。

/root
  - /module1
    - package.json
  - /module2
    - package.json
  ・
　・
　・

実装

実際の実装は、次のようにしました。

stages {

  stage('module build') {
    agent {
            ...
    }
    steps {
      sh 'yarn clean && yarn install && yarn build'
    }
  }

  stage('truncus-frontend release') {
    agent {
            ...
    }
    steps {
      sh ```
        echo "release check"
        diff_results=(git diff --name-only HEAD^ HEAD)　// gitの現在と直前のコミットを比較し、結果を取得
        current_dir=pwd

        for (( i = 0; i < ${#diff_results[@]}; ++i )); do // 変更点ごとにfor文を回す。 <= 設計２への対応

          if [[ ${diff_results[$i]} =~ ^.*/package.json$ ]]; then　// package.jsonに変更があったかを判定

            package_json_diff=git log -1 -p ${diff_results[$i]}
            new_version=echo "$package_json_diff" | grep '+\s*"version":\s*' | grep -o '[0-9].[0-9].[0-9]*'　// package.jsonのversionの差分を取得

            if [ -n "$new_version" ]; then　// versionの変更があったかを判定　<= 設計１への対応
              module_dir=cut -d'/' -f 1 <<<${diff_results[$i]}
              cd "$current_dir/$module_dir"
              yarn deploy
            fi
          fi
        done
      ```
    }
  }
}

振り返り

モジュールのテストを追加するようになった際は、テストをビルドの後に追加する。テストが通った時のみ、リリースを許可するのか。テストが通らずともリリースをしてしまうのかは、状況をみて判断する。
バージョン変更が行われた場合、勝手にリリースされるつくりになっている。これは、開発側がバージョン変更を行った = リリースを要求したと判断して、この実装にしているが、バージョンを上げたとしても、リリース時を決めたいというときは、つくりを変える必要がある。
jenkinsファイルは環境に依存しないつくりにするようにする。
モジュールの修復は速やかに行えるようにできるようにする。ログの取得と通知。
モジュールが増えてきた際、重量ビルドとフィードバックのバランスをとる必要がある。今回のつくりは、ビルドからリリースまでは一貫しているが、分離できるようにしていった方がいい。
頻繁にモジュールの変更が今のところないので、ビルドタイミングは手動にした。