Python | DevOps・運用：CD 自動デプロイ

CD 自動デプロイって何？一言でいうと「テストに通ったコードを、人の手を介さず“同じ手順で”本番に届ける仕組み」

CI が「自動テスト」だとしたら、
CD（Continuous Delivery / Deployment）は「自動デプロイ」です。

コードが main にマージされる
CI でテストが全部通る
その“テスト済みの成果物”を、自動でサーバーやクラウドにデプロイする

この流れを、毎回同じ手順で、ボタン一つか、場合によっては完全自動で回す。
それが CD 自動デプロイです。

ポイントは「人間の手作業を減らす」ことではなく、
「毎回同じ手順で、安全に、素早くリリースできる状態を作る」ことです。

まずはイメージ：Python Web アプリを GitHub から自動デプロイする流れ

手作業デプロイと何が違うのか

手作業デプロイだと、よくこうなります。

サーバーに SSH で入る
git pull する
pip install -r requirements.txt する
systemctl restart app する

人によってコマンドが違う
うっかりミスが起きる
どのバージョンが動いているか分からなくなる

CD 自動デプロイでは、これを「スクリプト化＋自動実行」します。

GitHub Actions が main の更新を検知
テストが通ったら、デプロイ用ジョブが走る
サーバーに対して決め打ちの手順でデプロイする

つまり、「人間がやっていたことを、機械にやらせる」だけです。
でも、この“だけ”が運用の安定性を大きく変えます。

例題：FastAPI アプリを Docker で動かし、GitHub Actions から自動デプロイする

前提となる構成イメージ

シンプルな構成を想像します。

FastAPI アプリ（app/main.py）
Docker でコンテナ化
本番サーバーは Docker を使ってアプリを動かしている
GitHub にリポジトリがある

このときの CD 自動デプロイの流れは、ざっくりこうです。

main にマージされる
GitHub Actions が Docker イメージをビルド
イメージをコンテナレジストリ（例：GitHub Container Registry）に push
本番サーバーがそのイメージを pull してコンテナを再起動

ここでは「GitHub Actions が本番サーバーに SSH して docker compose を叩く」パターンを例にします。

重要ポイント1：デプロイ対象を「Docker イメージ」に固定する

「どの環境でも同じものが動く」状態を作る

CD 自動デプロイをやりやすくするために、
アプリを Docker イメージに閉じ込めておくのが定番です。

Dockerfile の例です。

FROM python:3.12-slim

WORKDIR /app

COPY pyproject.toml poetry.lock ./
RUN pip install -U pip && pip install poetry && poetry install --no-dev

COPY app ./app

CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

FROM python:3.12-slim

WORKDIR /app

COPY pyproject.toml poetry.lock ./
RUN pip install -U pip && pip install poetry && poetry install --no-dev

COPY app ./app

CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

これで、

ローカルでも
CI でも
本番でも

同じイメージを動かせます。

CD 自動デプロイでは、「何をデプロイするか」を明確にすることが重要です。
Docker イメージを使うと、それがとても分かりやすくなります。

重要ポイント2：CI（テスト）と CD（デプロイ）をパイプラインとしてつなげる

まずは「テストが全部通ったら、デプロイジョブを走らせる」

GitHub Actions の YAML を、少しだけ CD 寄りにします。

name: CI/CD

on:
  push:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -U pip
      - run: pip install -e .[dev]
      - run: pytest

  deploy:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4

      - name: Set up SSH
        uses: webfactory/ssh-agent@v0.9.0
        with:
          ssh-private-key: ${{ secrets.SSH_KEY }}

      - name: Deploy to server
        run: |
          ssh user@your-server '
            cd /path/to/app &&
            git pull &&
            docker compose pull &&
            docker compose up -d
          '

name: CI/CD

on:
  push:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -U pip
      - run: pip install -e .[dev]
      - run: pytest

  deploy:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4

      - name: Set up SSH
        uses: webfactory/ssh-agent@v0.9.0
        with:
          ssh-private-key: ${{ secrets.SSH_KEY }}

      - name: Deploy to server
        run: |
          ssh user@your-server '
            cd /path/to/app &&
            git pull &&
            docker compose pull &&
            docker compose up -d
          '

ここでのポイントを噛み砕きます。

jobs.test
いつもの CI（pytest）。ここが緑にならないと次に進まない。

jobs.deploy
needs: test で、「テストが成功したらだけ動く」ようにしている。
if: github.ref == 'refs/heads/main' で、「main への push のときだけデプロイ」している。

Deploy to server
GitHub Actions から本番サーバーに SSH して、決め打ちのコマンドを実行している。
ここでは git pull と docker compose up -d を例にしているが、実際には「レジストリからイメージを pull して再起動」などにすることも多い。

これで、「main に push → テスト → OKなら自動デプロイ」というパイプラインができます。

重要ポイント3：「いつ自動で出すか」と「どこまで自動にするか」を決める

Continuous Delivery と Continuous Deployment の違い

用語として、CD には二つの意味があります。

Continuous Delivery
「いつでもデプロイできる状態まで自動化するが、本番に出すボタンは人が押す」

Continuous Deployment
「テストが通ったら、そのまま自動で本番に出す」

初心者が最初に目指すべきは、
Continuous Delivery の方です。

テストとビルドとステージング環境へのデプロイまでは自動
本番へのデプロイは「手動トリガー」

という形にすると、安全に始められます。

GitHub Actions の「手動トリガー」を使う

例えば、こういう設定もできます。

on:
  workflow_dispatch:

on:
  workflow_dispatch:

これを使うと、「GitHub のボタンを押したときだけデプロイジョブが動く」ようにできます。

CI でテストとビルドまでは自動
本番デプロイは、リリース担当がボタンを押す

という運用にすると、「完全自動はまだ怖い」という段階でも CD の恩恵を受けられます。

重要ポイント4：ロールバック（戻せる仕組み）を必ず考える

「壊れたらどう戻すか」が決まっていない自動デプロイは危険

CD 自動デプロイを入れるときに、絶対にセットで考えるべきなのがロールバックです。

新しいバージョンを出した
本番で問題が起きた
すぐに一つ前のバージョンに戻せるか

これができないと、「自動で壊して、自動で詰む」状態になります。

Docker イメージを使っているなら、

前のタグのイメージを起動し直す
docker compose のバージョンを切り替える

などで戻せます。

Git ベースなら、

前のタグにチェックアウトしてデプロイし直す

といった方法があります。

CD 自動デプロイを設計するときは、

どう出すか
どう戻すか

をセットで決めるのが超重要です。

重要ポイント5：環境ごとに「どこまで自動か」を変える

開発・ステージング・本番で自動化レベルを変える

現実的な運用では、環境が複数あります。

開発環境（dev）
ステージング環境（stg）
本番環境（prod）

CD 自動デプロイのレベルを、環境ごとに変えるのがよくあるパターンです。

開発環境
main にマージされたら自動で dev にデプロイ

ステージング
リリースブランチやタグを作ったら自動で stg にデプロイ

本番
stg で確認したあと、手動トリガーで prod にデプロイ
（慣れてきたらタグ push で自動 prod もアリ）

こうすると、

開発はサクサク回る
本番は慎重に出せる

というバランスが取れます。

初心者が CD 自動デプロイを身につけるためのステップ

ステップ1：まずは「手作業デプロイの手順」を言語化する

今、自分がどうやってデプロイしているかを、全部コマンドに書き出してみる。

どのサーバーに
どのディレクトリで
どのコマンドを
どの順番で

これがそのまま「自動化すべき手順」になります。

ステップ2：その手順をシェルスクリプトや Makefile にまとめる

例えば deploy.sh を作って、
ローカルからでも CI からでも同じスクリプトを叩けるようにする。

これで、「人間の手作業」から「スクリプト実行」に一段階進みます。

ステップ3：GitHub Actions からそのスクリプトを叩く

次に、GitHub Actions のジョブから ssh でサーバーに入り、
その deploy.sh を実行するようにする。

ここまで来ると、「push → テスト → スクリプトでデプロイ」という CD の骨格ができます。

まとめ（CD 自動デプロイは「テスト済みのコードを、毎回同じ手順で安全に届けるためのパイプライン」）

初心者目線で整理すると、Python の CD 自動デプロイはこういうものです。

CI でテストが通ったコードを、GitHub Actions などからサーバーやクラウドに自動でデプロイすることで、「人によって手順が違う」「うっかりミスで本番が壊れる」を減らし、「いつでも同じ手順で、素早く、安全にリリースできる」状態を作る仕組み。
Docker イメージ化・テストとデプロイのパイプライン化・ロールバック手順の用意・環境ごとの自動化レベル調整を組み合わせることで、DevOps 的な「小さく頻繁にリリースする」スタイルが現実的なものになる。
最初は「手作業デプロイの手順をスクリプト化 → GitHub Actions からそのスクリプトを叩く → 本番は手動トリガーにする」という段階的な進め方をすると、怖さを抑えつつ CD 自動デプロイの感覚を自分のものにしていける。