はじめに
継続的デプロイ（CD）とは、検証済みのソフトウェアを実行可能な環境へ届ける段階です。
ソフトウェア工場の例をもう一度考えてみましょう。
- CI：ロボットが不具合をチェックします。
- Artifact：ロボットが製品を箱に詰めます。
- CD：配送トラックが箱を店舗（サーバー）へ運び、お客様が使えるようにします。
実際のデプロイでは、SSH、API、またはプラットフォーム固有のリリース機能を使って、稼働中のシステムを更新することがよくあります。この実験では、そのプロセスをシミュレーションします。ただし、ここで重要なのは、テスト済みのコードを実行環境へ届ける流れです。
CI と CD の中心的な違いはここにあります。CI は、ソフトウェアの変更がリリースを検討できるほど健全であることを確認します。一方、CD は、検証済みの変更を環境へ制御された形で移動させます。
この実験では、次のことを行います。
- Manual Triggers（クリックしてデプロイ）の概念を学びます。
- 実際のプロセスをシミュレーションするデプロイワークフローを作成します。
- 「配送トラック」（CD）を「品質管理」（CI）につなげます。
前提条件
引き続き github-actions-basics リポジトリを使用します。
手動デプロイを作成する
コードを push するたびに、必ずデプロイしたいとは限りません。承認を待ったり、準備が整ったときだけデプロイしたりする場合があります。
そのため、手動トリガーと段階的な環境がよく使われます。デリバリーパイプラインでは、成功したビルドをすぐに本番環境へデプロイするのではなく、速度と運用上の慎重さのバランスを取ることがよくあります。
GitHub Actions では、ボタンをクリックしたときだけ実行されるワークフローを作成できます。これは workflow_dispatch トリガーを使用して設定します。
プロジェクトのワークフローディレクトリへ移動します。
cd ~/project
git clone https://github.com/your-username/github-actions-basics.git
cd github-actions-basics
注：your-username を実際の GitHub ユーザー名に置き換えてください。
deploy.yml という新しいファイルを作成します。
touch .github/workflows/deploy.yml
nano でファイルを開きます。
nano .github/workflows/deploy.yml
次の内容を追加します。
name: Deploy to Production
on: workflow_dispatch
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Deploying
run: echo "Starting deployment..."
on: workflow_dispatch に注目してください。これが手動実行用のボタンになります。
nano でファイルを保存して終了し、その後このファイルを GitHub へ push します。
git add .
git commit -m "Add manual deployment workflow"
git push
次に、GitHub の Actions タブを開きます。
- 左側のサイドバーで Deploy to Production をクリックします。
- 「This workflow has a dispatch event trigger.」と表示された青いバナーを確認します。
- Run workflow ボタンをクリックし、ドロップダウンに表示される緑色の Run workflow ボタンをクリックします。
これで、デプロイパイプラインを手動で実行できました。
デプロイ手順をシミュレーションする
実際のデプロイスクリプトは複雑になることがありますが、通常は次のような単純な流れに従います。
- サーバーに接続する。
- ソフトウェアの新しいバージョンを取得する。
- アプリケーションを再起動する。
実装の詳細が異なっていても、多くのデプロイパイプラインは、認証し、目的のアーティファクトを取得し、実行中の環境でそのアーティファクトを使用するという基本的な構成になります。
この流れをシミュレーションするため、deploy.yml を更新します。echo コマンドを使って、実際に行われる処理を表示します。
もう一度ファイルを開きます。
nano .github/workflows/deploy.yml
jobs セクションを、次の詳細なシミュレーション内容に置き換えます。
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Mock SSH Connection
run: echo "Connecting to production server at 192.168.1.1..."
- name: Pull New Image
run: |
echo "Logging into Registry..."
echo "Pulling image ghcr.io/myname/app:latest..."
- name: Restart Application
run: |
echo "Stopping old container..."
echo "Starting new container..."
echo "Deployment Successful!"
保存して終了し、変更を push します。
git add .
git commit -m "Update deployment steps"
git push
GitHub Actions に戻り、Deploy to Production ワークフローをもう一度手動で実行します。ログを確認してください。実際のデプロイと同じように見えるはずです。
この「Mock」手法は、実際にとても役立ちます。実務では、複雑なコードを書く前に、プロセスについて合意するため、まずこのような「Skeleton」ワークフローを作成することがよくあります。
安全性チェックを追加する
現在、「Deploy」ワークフローは「Test」（CI）ワークフローから完全に独立しています。しかし実際には、壊れたコードをデプロイしてはいけません。品質チェックに合格した場合だけ、配送トラックを出発させます。
needs キーワードを使うとワークフローを連携できます。ただし、needs は 1 つのファイル内で使用する場合に最も適しています。別々のファイルを使う場合は、通常、CI を Push で実行し、CD を Release または手動で実行するという運用で管理します。
ここでは、手動デプロイにも安全性チェックを追加する方法を学びます。確実に問題がないと判断した場合だけデプロイすることにします。
deploy.yml を開きます。
nano .github/workflows/deploy.yml
steps に確認処理を追加するため、内容を変更します。
steps:
- name: Safety Check
run: echo " verifying that CI passed..."
- name: Mock SSH Connection
run: echo "Connecting to production server at 192.168.1.1..."
## ... rest of the file
（注：実際の Enterprise 環境では、GitHub Environments という機能を使って、このジョブを実行する前に「CI に合格していること」を必須にできます。ただし、その設定にはこのファイル以外の構成が必要です。）
今はファイルを保存して終了し、変更を push します。
git add .
git commit -m "Add safety check"
git push
最後に、ワークフローをもう一度手動で実行します。
まとめ
おめでとうございます。GitHub Actions CICD モジュールを完了しました。
この最後の実験では、次のことを学びました。
- Manual Triggers：
workflow_dispatchを使って、制御されたデプロイを行う方法。 - Simulation：Mock ステップを使って、デプロイプロセスを試作する方法。
- 全体像：CI、Artifacts、Security、CD がどのように連携するか。
GitHub Actions の知識がない状態から始めましたが、今では自動テスト、パッケージ化、デプロイスクリプトを備えた、完全に機能するリポジトリができました。これで、自分のプロジェクトの自動化を始める準備が整いました。
