CI (Continuous Integration : 継続的インテグレーション) は、ソフトウェア開発において、開発者が自分のコード変更を共有リポジトリに頻繁にマージする（統合する）プラクティスです。
統合に伴う問題を早期に、そして継続的に特定し解決することが目的になります。
頻繁に行われるアップデートで、自動テストを実行することで、時間と心理ストレスを軽減する試作なんですね。
このCIを導入している開発チームと、導入していない開発チームでは、どのくらいの差が生まれるかは、考えなくてもわかりますよね。
なぜ早めに CI を導入すべきなのか？
E2Eテストはローカルだけで回すと、意味が半減するんです。
E2Eテストの価値を最大化するには、デプロイ直前に行うのが、本番影響で不具合を出しづらくする最も適切な場所でもあるんですね。
CI を早期導入するメリット
・テストが「開発フローの一部」になる
・人による実行忘れがゼロになる
・チーム or 未来の自分が勝手に壊さなくなる
・「壊れているのに気づけない」事故を防げる
・追加したテストが 自動で永遠に守ってくれる
Playwrightと相性の良いCI
メジャーなCIサーバー
・GitHub Actions
・GitLab CI
・CircleCI
・Jenkins
構成要素
共有バージョン管理システム
Gitなどのシステムを使用し、すべてのコードを一つの共有リポジトリで管理します。
CIサーバー
Jenkins, GitLab CI, GitHub Actions, CircleCIなどのツールで、以下のプロセスを自動化します。
・コードのチェックアウト
・ビルドの実行（コンパイルなど）
・単体テスト、統合テストなどの自動テストの実行
自動テスト
信頼性の高いテストスイートを用意することが、CIの品質保証の鍵となります。
フィードバックメカニズム
ビルドやテストの結果（成功/失敗）を開発チームに即座に通知する仕組み（チャット、メールなど）が必要です。
サンプルコード
Github Actions
name: Playwright Tests
on:
pull_request:
push:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Install Node
uses: actions/setup-node@v4
with:
node-version: 20
- name: Install dependencies
run: npm ci
- name: Install browsers
run: npx playwright install --with-deps
- name: Run tests
run: npx playwright test --reporter=list
Dockerバージョン
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build Docker image
run: docker build -t my-playwright ./playwright
- name: Run tests in container
run: docker run --rm my-playwright npx playwright test
CIを自作したい人向け
GithubActionsは、privateリポジトリで使う場合は、有料（または制限あり）になり、まあまあな金額が発生するので、自前で準備したいと考える自分みたいな人（チーム）も多いでしょうね。
そんな場合は、Jenkinsか、独自のCIシステム開発をしてみるのも悪くないかもですね。
ちなみに、GitLabやCircleCIは、無料で使えるので、Jenkinsも含めて、検討してみるのも悪くないでしょう。
そして、さらにエンジニアたるもの、CIを自作してみると考えた人に、考えるべきポイントは以下の通りです。
自動ジョブシステム
・ソースが更新されたら
・自動的にテストやビルドを実行し
・結果を通知する
構成要素の三種の神器
1. トリガー（pushやPRなど）
2. ジョブ実行環境（Dockerなど）
3. 結果通知（Slack、メールなど）
Jenkins みたいな巨大ツールじゃなくても、Webhook + Docker + Cron を組み合わせれば CI として成立することができるので、
あとはやる気と根性の世界でしょう。
Git の Webhook で自動実行するミニマル CI
要素
GitHub/GitLab の Webhook
自分のサーバー（VPS など）
Docker（Playwrightテスト用）
流れ
リポジトリの push → GitHub/GitLab が Webhook を叩く
あなたのサーバーのAPIが受信してシェルを実行
Docker内で npx playwright test を実行
結果を Slack や LINE Notify に送信
特徴
軽い
ほぼ無料（サーバー代だけ）
Jenkinsより圧倒的に運用が楽
Cron で定期実行する "スケジュールCI"
「アップデート時 or 毎日朝10時にテストしたい」みたいな用途に最適な構成です。
構成
ローカル or VPS で Cron
定期的に git pull → docker run playwright test → 結果通知
特徴
サーバー 1 台と Docker だけで動く
テスト環境を完全に自分でコントロールできる
安い（無料に近い）
ただし、“PRごとのテスト”などには向かないので、要注意です。
Drone CI
実は Jenkins の代わりに最も人気のある「自ホスト型CI」に "
Drone" と言うのがあります。
Droneについて
Dockerコンテナだけで動く
YAMLで設定するので GitHub Actions そっくり
UIもきれい
GitHub / GitLab と簡単に連携
特徴
Jenkins より圧倒的に軽い（運用量1/10）
構築も簡単
Playwright + Docker との相性が良い
あとがき
Gitの機能であるHook機能も、pushやpull、margeのタイミングをイベント発火して、バッチモジュールを起動させることができるので、
playwrightを実行するということもできますが、実はこれはCIとは違うと認識しましょう。
細かいことを言うと、Playwrightは、処理が非常に重く、頻繁に行うpush,pull,margeなどのタイミングでクソ重い処理を使用ものなら、開発作業が滞って仕方がなくなるでしょう。
と言うことで、GitHookでのPlaywright仕様は、御法度としているのが通常です。
GithubActionsがベストとされているのは、プルリクからのCI起動ができる点だからでしょう。
でも、自作をしてコストメリットも、業務メリットも効率的に行うのもエンジニアの勤めと考えるのも悪くないですよ。
0 件のコメント:
コメントを投稿