【インフラ_8日目】CI/CD_1冊目
こんにちは投資ロウトです。
背景
・CI/ CDをシステムに導入していかなければならない背景があります。
CIのプロセス
【CIを動かす一般の流れ】
①プルリクエストを実施する
②①をきっかけに、CIを動かして、成功したか確認
③②が成功すると、コードレビューを実施する
④③が完了するとマージする
CIで何を動かすべきか
【例】
・自動テスト
・静的解析ツールによるコードの品質チェック
・クレデンシャルの検知
・コンテナイメージの脆弱性検査
・Infrastructure as Codeの設定ミスなどの発見
テストフローのステップについて
①チェックアウトステップ
②言語セットアップステップ
③テストステップ
これらを行っていくことがテストフローの基本形とのこと。
# リポジトリからソースコードを取得
- uses: actions/checkout@v4
# NodeJSのバージョン指定
- name: Set up Node.js
- uses: actions/setup-node@v4
with:
node-version: "20"
cache: npm
# テスト実施
- run: npm install
- run: npm test
# 特定のファイルが来た時にだけテストを流すようにする(React等で使用されるファイルを想定)
on:
pull_request:
paths: ["**/*.js", "**/*.jsx", "**/*.ts", "**/*.tsx", "**/package.json", "**/yarn.lock"]
イベントのフィルター
下記のように、特定のファイルの命名規則の場合のみ、テストワークフローを動かすなどのような条件を設けたいなどの時に使用できる
・paths・・・指定したファイルのみ
・paths-ignore・・・指定したファイルパス以外
※他にもbranchやtagなども指定できる
※pathsとpaths-ignoreは同時に使用できず、代わりにGlobを使う必要があるとのこと。
静的解析
GitHubActiosの利用するツールはactionlintというものがあるとのことですが、使い勝手がいいらしいです。
sonarqubeを使っている現場はありましたが、それよりいいんですかね？
# 10分を超えたら停止する(単位は分)
timeout-miniutes: 10
# パイプラインエラーがキャッチできるようにする
defaults:
run:
shell: bash
# 新しくコミットされると、過去のワークフローをキャンセル
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
GitHub Actionsは使用時間で課金されるとのことで、パイプラインがエラーが起きた時に止められるようにするのは、コスト削減のために重要とのことでした。
またタイムアウトの設定は、あらゆるワークフローに設定させるのが重要とのことでした。そうしないと無限ループや、通信待ちなどが起きてしまうと、最大6時間も動き続けてしまうとのことでした。
→過去のjestで自動テストを導入していた際に、システム自体が巨大になると、テスト実行時間がえげつない時があったので、いつまでも実行をさせないように、タイムアウト設定を入れるのは、重要だなと感じました。
Concurrency
GitHub Actionsはイベントが起きた時にワークフローが動きますが、同時実行されるのが基本挙動となるので、Concureencyというグループを設定すると、同一グループとみなされ、多重起動が抑止されるとのことでした。そのため他のワークフローは実行を待機するとのことです。
自動キャンセル
# 古いワークフローはキャンセル
cancel-in-progress: true
CIは始まり
CIはあくまでスタートにしか過ぎず、運用をするための仕組みが重要とのことでした。
【重要なこと】
・CIなどの実行でエラーが起きた状態でマージはしてはいけない
・CIは素早く実行させないといけないとのこと
※理想は5分以内とのこと。遅くても10分とのことでした。
※CIにチューニングできる要素があるとのことでした。
自動テストのいい方針
・単一テストを中心にすること
※E2Eは軽めとのこと
・テスト実行時の挙動を制御するのがいいとのこと
→具体的には部分実行にすることで、高速化させるのもいいとのこと。
→並列実行が可能であれば、それを実施。
と短いですが、以上で学習を区切りたいと思います。ご精読ありがとうございました。焦らずコツコツ頑張っていきたいと思います。
Discussion