メインコンテンツまでスキップ

デプロイの自動化

自動化の重要性と具体的な方法

ここまでで何回か、サーバーのアップロードは自動化することを勧めていますが、つまりデプロイを自動化する重要性と、具体的な方法について少し触れていきます。

手作業は失敗する​

まず、大前提として、手作業を失敗しないようにすることは、不可能であると肝に据えることが大切です。

人の手作業に100%はあり得ません。何％かで失敗をします。

自動化したとしても、トリガーが人である以上、もちろん失敗はあり得るわけですが、議論はそのパーセンテージの数字でするべきです。

「マニュアルを守ってやる」よりも、「自動化する」が失敗の確率をより下げるということは、言うまでもありません。

デプロイそのものをシンプルなものにする​

自動化するにあたって、まず重要なことは、デプロイ作業そのものをシンプルな仕様にしておく。ということが挙げられます。

その一つの解が、ステージングはそのままプロダクションになる という運用なのです。

GitHub Actions を使った自動化​

GitHubには、ブランチのプッシュやコミット、マージのタイミングで設定した処理を走らせる、「GitHub Actions」という機能があります。

FTPのアップロードをGitHub Actionsを使って自動化することが出来ます。

GitHub Actions の設定ファイルを作る​

GitHubのリポジトリ画面から、「Actions」 のタブを選択し、「set up a workflow yourself」をクリックして、ワークフローの作成を開始します。

ワークフローの作成

main.ymlというファイルを作る画面になりますので、staging.ymlという名前に変更して、

ワークフローの作成

以下の内容をコピペします。

name: Staging FTP Upload

on:                       # トリガーの設定
  push:                   # プッシュ時に実行
    branches: [develop]    # ブランチの指定
      
jobs:
  FTP-Deploy-Action:
    name: FTP-Deploy-Action   # 分かりやすいジョブの名前
    runs-on: ubuntu-latest    # 実行環境

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4.0.0   # チェックアウトアクション（https://github.com/actions/checkout）
        
      - name: FTP-Deploy-Action
        uses: SamKirkland/FTP-Deploy-Action@v4.3.4     # FTPアップロードアクション（https://github.com/SamKirkland/FTP-Deploy-Action）
        with:
          server: ${{ secrets.STAGING_SERVER }}       # FTPのサーバーアドレス
          username: ${{ secrets.STAGING_USERNAME }}   # FTPのユーザー名
          password: ${{ secrets.STAGING_PASSWORD }}   # FTPのパスワード
          protocol: ftps
          local-dir: ./dest/                           # アップロードしたいフォルダのパス
          server-dir: /public_html/staging/      # アップロード先のフォルダのパス

ステージングサーバーにアップロードすることを想定しています。

local-dir: ./dest/ 及び server-dir: /public_html/staging/ は、環境に合わせて書き換えてください。

ワークフローの作成

「Commit changes」をクリックして、保存します。

コミットメッセージを求められるので、適宜書き込んでください。（そもままコミットでもOK）

ワークフローファイル（yml）もリポジトリ内に保存される

.github/workflow フォルダ内にymlは保存され、その中のymlファイルがワークフローとして認識されます。

つまり、この設定ファイルは、ローカルリポジトリで編集することもできます。

GitHub Secrets に、パスワードなどを登録​

パスワードなどを、ymlに直接書いてしまうと、機密情報の漏洩になってしまいます。

ymlの中の${{ secrets.STAGING_SERVER }}などの記述は、GitHub Secrets に登録された値を持ってくるという意味ですので、必要なキーと値を登録していきます。

「Setting」タブの「Secrets and variables」→「Actions」の「New repository secret」ボタンをクリックしてください。

シークレットの作成

ここで、キー名と設定値を一つずつ登録します。

シークレットの作成

以下が全部登録し終わったところです。

機密情報なので、値は表示されません。

ワークフローの作成

GitHub Actions を動作させてみる​

今回は、develop ブランチに変更があった場合、FTPアップロードが走るワークフローを登録しましたので、develop ブランチにfeatureブランチをプルリクでマージしてみます。

ワークフローの作成

成功すると、Actionsのページに、緑色のアイコンのついた実行結果が出現します。

赤は失敗です。下のスクリーンショットはymlの設定を試行錯誤したので、エラーの実行結果が映り込んでいます（＾＾；

ワークフローの作成

サーバー側の設定に注意

日本国内のサーバーは、デフォルトの設定では、海外からのFTP接続を遮断している場合があります。

GitHubのサーバーは海外にあるので、拒否されてしまう可能性があるので、注意しましょう。

FTPソフトでアップロード結果を覗いてみます。

アップロードできているようです！

ワークフローの作成

備考

.ftp-deploy-sync-state.jsonは、今回使用したアクションが出してくれるアップロード結果のログファイルです。

GitHub Actions をデバッグする​

実行結果の詳細画面では、ログを確認出来るので、参考にします。

また、再プッシュせずとも再実行が可能です（マルをつけた箇所をクリック）

ワークフローの作成

ワークフローの整備に関してだけ特別に、GitHub上で直接コードを編集し、developにコミットをしてもOKという運用でも問題ないと思います。

ワークフローの作成

プロダクションサーバー用のアクションも作ってみよう

develop -> main

STAGING -> PRODUCTION

と、キーワードを書き換えて、server-dir を変えるだけです。

今回使った GitHub Actions​

アクションの実態は、Nodeで書かれていますが、先人が作ってくれた便利なアクションがマーケットプレイスで公開されています。

今回は以下のアクションを使用しました。

もちろん、アクションをNodeで自分で書くことも出来ます。

ビルドによる成果物（例えばscss->cssのcssファイルのような）をGitで管理しない場合は、ビルドをGitHub Actionsに任せると良いでしょう。

その際には、トリガーを「プルリクエスト時」に設定し、ビルドエラーのあるコードをdevelopブランチにマージされてしまうことを防ぐというようなことも出来ます。

クラウドサービスがActionsを作ってくれていることもある

クラウドサービスによっては、このあたりを自動で構築してくれたり、専用のアクションを用意してくれたりしていることがあるので、承知しておきましょう。