Ubuntu 16.04でWebhookとSlackを使用してReactアプリケーションをデプロイする

著者は、Write for DOnationsプログラムの一部として寄付を受け取るためにTech Education Fundを選択しました。

前書き

開発者がアプリケーションを継続的に変更している場合、webhookを備えた展開システムは、特にチーム向けに開発を効率化できます。 チームの一部がAPIなどのバックエンドソフトウェアに依存している場合、コードの変更に関するSlack通知をチームのワークフローに統合することも役立ちます。

このチュートリアルでは、create-react-app npm packageを使用してReactアプリケーションを構築します。 このパッケージは、構文を変換し、依存関係および前提条件ツールを使用して作業を合理化することにより、Reactプロジェクトのブートストラップ作業を簡素化します。 アプリケーションコードをGitHubリポジトリに追加した後、更新されたプロジェクトファイルを提供するようにNginxを構成します。 次に、webhookサーバーをダウンロードしてセットアップし、コードが変更されたときにGitHubと通信するように構成します。 最後に、Slackを別のwebhookサーバーとして機能するように設定します。これは、展開が正常にトリガーされたときに通知を受け取ります。

最終的に、この記事で構築する展開システムは次のようになります。

Sample deployment

この短いビデオでは、空のコミットとGitHubリポジトリへのプッシュが示され、Slackでアプリケーションのビルドと通知がトリガーされます。

前提条件

このチュートリアルを完了するには、次のものが必要です。

  • Initial Server Setup with Ubuntu 16.04 tutorialに従ってセットアップできるUbuntu16.04サーバー。 このガイドに従うと、sudo特権を持つ非rootユーザーアカウントが必要になります。

  • How To Install Nginx on Ubuntu 16.04の最初の2つの手順に従って、サーバーにNginxをインストールします。

  • ローカルマシンとサーバーの両方で構成されたGit。 Gitのインストールと構成の手順については、このチュートリアルのgetting started with Gitを参照してください。

  • Node.js and npm installed on your local machine and server. サーバーの場合は、PPAからHow To Install Node.js on Ubuntu 16.04でNode.jsをインストールする手順に従います。 ローカルマシンでは、project’s installation directionsを追跡できます。

  • installing yarnの公式ガイドに従って、サーバーにインストールされたYarn。

  • Slackおよび通知用の個々のチャネルを構成する権限。 役割と権限の詳細については、Slack permissions docsを参照してください。

[[step-1 -—- creating-a-react-application-using-create-react-app]] ==ステップ1—create-react-appを使用してReactアプリケーションを作成する

まず、create-react-appを使用してWebhookをテストするために使用するアプリケーションを作成しましょう。 次に、GitHubリポジトリを作成し、プロジェクトコードをプッシュします。

ローカルマシンで、create-react-appノードモジュールをグローバルリポジトリに追加し、create-react-appコマンドをシェル環境で使用できるようにします。

sudo npm install -g create-react-app

次に、create-react-appを実行して、do-react-example-appというプロジェクトを作成します。

create-react-app do-react-example-app

ディレクトリdo-react-example-appに移動します。

cd do-react-example-app

nanoまたはお気に入りのテキストエディタを使用して、package.jsonファイルを開きます。

nano package.json

ファイルは次のようになります。

~/do-react-example-app/package.json

{
  "name": "do-react-example-app",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "react": "^16.2.0",
    "react-dom": "^16.2.0",
    "react-scripts": "1.0.17"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject"
  }
}

package.jsonファイルには、次のスクリプトが含まれています。

  • start:このスクリプトは、アプリケーションの開発バージョンを開始する役割を果たします。 アプリケーションを提供するHTTPサーバーを実行します。

  • build:このスクリプトは、アプリケーションの製品版を作成する役割を果たします。 サーバーでこのスクリプトを使用します。

  • test:このスクリプトは、プロジェクトに関連付けられたデフォルトのテストを実行します。

  • eject:このスクリプトは、create-react-appパッケージの高度な機能です。 開発者がパッケージが提供するビルド環境に満足していない場合、アプリケーションを「イジェクト」することができます。そうしないと使用できないオプション(カスタムCSSトランスパイラーやJS処理ツールなどを含む)が生成されます。

コードの検査が終了したら、ファイルを閉じます。

次に、プロジェクトのGitHubリポジトリを作成しましょう。 ガイダンスについては、creating a GitHub repositoryでこのチュートリアルに従うことができます。 リポジトリの起源に注意してください(つまり、 そのGitHub URL)。

do-react-example-appディレクトリに戻り、リポジトリをgitで初期化します。

git init

次に、GitHub URLでリモートオリジンを追加します。

git remote add origin your-github-url

プロジェクトディレクトリ内のすべてのファイルをステージングします。

git add .

それらをコミットします。

git commit -m "initial commit"

そしてそれらをリポジトリにプッシュします:

git push origin master

GitHubリポジトリの作成と、gitを使用した既存のアプリケーションの初期化の詳細については、GitHubのdocumentationを参照してください。

リポジトリのセットアップが完了したら、サーバーの構成の詳細の指定に進みます。

[[step-2 -—- directory-set-up-and-nginx-configuration]] ==ステップ2—ディレクトリのセットアップとNginxの構成

リポジトリを配置したら、GitHubからアプリケーションコードを取得し、アプリケーションを提供するようにNginxを構成できるようになりました。

サーバーにログインし、ホームディレクトリに移動して、リポジトリのクローンを作成します。

cd ~
git clone your-github-url

クローンプロジェクトに移動します。

cd do-react-example-app

Nginxが提供するプロジェクトとファイル内にビルドディレクトリを作成するには、yarn buildコマンドを実行する必要があります。 これにより、プロジェクトのビルドスクリプトが実行され、ビルドディレクトリが作成されます。 このフォルダーには、特に、index.htmlファイル、JavaScriptファイル、およびCSSファイルが含まれます。 yarnコマンドは、プロジェクトに必要なすべてのノードモジュールをダウンロードします。

yarn && yarn build

次に、/var/www/ディレクトリに~/do-react-example-appディレクトリへのシンボリックリンクを作成しましょう。 これにより、アプリケーションはホームディレクトリに保持され、Nginxは/var/wwwディレクトリからサービスを提供できるようになります。

sudo ln -s ~/do-react-example-app /var/www/do-react-example-app

これは、より頻繁に変更されるビルドディレクトリではなく、プロジェクトディレクトリにリンクすることに注意してください。 このリンクの作成は、アプリケーションの新しいバージョンをデプロイするシナリオで特に役立ちます。安定したバージョンへのリンクを作成することにより、追加バージョンをデプロイする際に後でスワップアウトするプロセスを簡素化します。 問題が発生した場合も、同じ方法で以前のバージョンに戻すことができます。

Nginxが適切に提供できるように、シンボリックリンクにいくつかの権限を設定する必要があります。

sudo chmod -R 755 /var/www

次に、ビルドディレクトリを提供するNginxサーバーブロックを構成します。 次のように入力して、新しいサーバー構成を作成します。

sudo nano /etc/nginx/sites-available/test-server

次の構成をコピーし、your_server_ip_or_domainをIPまたはドメイン(該当する場合)に置き換えます。

/etc/nginx/sites-available/test-server

server {
        listen 80;

        root /var/www/do-react-example-app/build;
        index index.html index.htm index.nginx-debian.html;

        server_name your_server_ip_or_domain;

        location / {
                try_files $uri /index.html;
        }
}

このファイルのディレクティブは次のとおりです。

  • listen:サーバーのリスニングポートを構成するプロパティ。

  • root:Ngnixがファイルを提供するフォルダーへのパス。

  • index:サーバーが最初に提供しようとするファイル。 /var/www/do-react-example-app/buildディレクトリから次のファイルのいずれかを提供しようとします:index.htmlindex.htmindex.nginx-debian.html、優先順位は最初から最後まで。

  • server_name:サーバーのドメイン名またはIP。

次に、sites-enabledディレクトリにシンボリックリンクを作成します。

sudo ln -s /etc/nginx/sites-available/test-server /etc/nginx/sites-enabled/test-server

これにより、Nginxは `sites-available`フォルダーからサーバーブロック構成を有効にするように指示されます。

設定が有効かどうかを確認します。

sudo nginx -t

最後に、Nginxを再起動して新しい構成を適用します。

sudo systemctl restart nginx

これらの構成の詳細を設定したら、webhookの構成に進むことができます。

[[step-3 -—- installing-and-configuring-webhooks]] ==ステップ3—Webhookのインストールと構成

Webhookは、hooksと呼ばれる構成可能なエンドポイントを持つ単純なHTTPサーバーです。 HTTPリクエストを受信すると、webhookサーバーは、構成可能な一連のルールに準拠するカスタマイズ可能なコードを実行します。 Slackを含む、インターネット上のアプリケーションに統合された多くのwebhookサーバーが既にあります。

Webhookサーバーの最も広く使用されている実装は、Goで記述されたWebhookです。 このツールを使用して、webhookサーバーをセットアップします。

サーバー上のホームディレクトリにいることを確認します。

cd ~

次に、webhookをダウンロードします。

wget https://github.com/adnanh/webhook/releases/download/2.6.6/webhook-linux-amd64.tar.gz

抽出する:

tar -xvf webhook-linux-amd64.tar.gz

バイナリを/usr/local/binに移動して、ご使用の環境で使用できるようにします。

sudo mv webhook-linux-amd64/webhook /usr/local/bin

最後に、ダウンロードしたファイルをクリーンアップします。

rm -rf webhook-linux-amd64*

次のように入力して、環境でのwebhookの可用性をテストします。

webhook -version

出力には、webhookバージョンが表示されます。

Outputwebhook version 2.6.5

次に、/opt+`directory, where files for third-party applications usually go. Since the `+/optディレクトリにhooksフォルダとscriptsフォルダを設定しましょう。通常はrootが所有します。root権限でディレクトリを作成してから、ローカル%に所有権を譲渡できます。 (t4)s。

最初に、ディレクトリを作成します。

sudo mkdir /opt/scripts
sudo mkdir /opt/hooks

次に、所有権を$USERに譲渡します。

sudo chown -R $USER:$USER /opt/scripts
sudo chown -R $USER:$USER /opt/hooks

次に、hooks.jsonファイルを作成して、webhookサーバーを構成しましょう。 nanoまたはお気に入りのエディターを使用して、/opt/hooksディレクトリにhooks.jsonファイルを作成します。

nano /opt/hooks/hooks.json

GitHubがHTTPリクエストを送信するときにwebhookがトリガーされるようにするには、ファイルにルールのJSON配列が必要です。 これらのルールは、次のプロパティで構成されています。

{
    "id": "",
    "execute-command": "",
    "command-working-directory": "",
    "pass-arguments-to-command": [],
    "trigger-rule": {}
}

具体的には、これらのルールは次の情報を定義します。

  • id:Webhookサーバーがサービスを提供するエンドポイントの名前。 これをredeploy-appと呼びます。

  • execute-command:フックがトリガーされたときに実行されるスクリプトへのパス。 この場合、これは/opt/scripts/redeploy.shにあるredeploy.shスクリプトになります。

  • command-working-directory:コマンドの実行時に使用される作業ディレクトリ。 redeploy.shが配置されている場所であるため、/opt/scriptsを使用します。

  • pass-arguments-to-command:HTTPリクエストからスクリプトに渡されるパラメーター。 HTTPリクエストのペイロードからコミットメッセージ、プッシャー名、コミットIDを渡します。 これと同じ情報がSlackメッセージにも含まれます。

/opt/hooks/hooks.jsonファイルには、次の情報が含まれている必要があります。

/opt/hooks/hooks.json

[
  {
    "id": "redeploy-app",
    "execute-command": "/opt/scripts/redeploy.sh",
    "command-working-directory": "/opt/scripts",
    "pass-arguments-to-command":
    [
      {
        "source": "payload",
        "name": "head_commit.message"
      },
      {
        "source": "payload",
        "name": "pusher.name"
      },
      {
        "source": "payload",
        "name": "head_commit.id"
      }
    ],
    "trigger-rule": {}
  }
]

GitHub HTTP POSTリクエストのペイロードには、head_commit.messagepusher.name、およびhead_commit.idプロパティが含まれます。 GitHubリポジトリで設定されたイベント(PUSHなど)が発生すると、GitHubはイベントに関する情報を含むJSON本体を含むPOSTリクエストを送信します。 これらのPOSTペイロードのいくつかの例は、GitHub Event Types docsにあります。

構成ファイルの最後のプロパティはtrigger-ruleプロパティです。これは、フックがトリガーされる条件をWebhookサーバーに通知します。 空のままにすると、フックが常にトリガーされます。 この例では、GitHubがWebhookサーバーにPOSTリクエストを送信したときにトリガーされるようにフックを設定します。 具体的には、HTTPリクエストのGitHubシークレット(ここではyour-github-secretと表記)がルールのシークレットと一致し、コミットがmasterブランチで発生した場合にのみトリガーされます。

次のコードを追加してtrigger-ruleを定義し、your-github-secretを選択したパスワードに置き換えます。

...
    "trigger-rule":
    {
      "and":
      [
        {
          "match":
          {
            "type": "payload-hash-sha1",
            "secret": "your-github-secret",
            "parameter":
            {
              "source": "header",
              "name": "X-Hub-Signature"
            }
          }
        },
        {
          "match":
          {
            "type": "value",
            "value": "refs/heads/master",
            "parameter":
            {
              "source": "payload",
              "name": "ref"
            }
          }
        }
      ]
    }
  }
]

完全に、/opt/hooks/hooks.jsonは次のようになります。

/opt/hooks/hooks.json

[
  {
    "id": "redeploy-app",
    "execute-command": "/opt/scripts/redeploy.sh",
    "command-working-directory": "/opt/scripts",
    "pass-arguments-to-command":
    [
      {
        "source": "payload",
        "name": "head_commit.message"
      },
      {
        "source": "payload",
        "name": "pusher.name"
      },
      {
        "source": "payload",
        "name": "head_commit.id"
      }
    ],
    "trigger-rule":
    {
      "and":
      [
        {
          "match":
          {
            "type": "payload-hash-sha1",
            "secret": "your-github-secret",
            "parameter":
            {
              "source": "header",
              "name": "X-Hub-Signature"
            }
          }
        },
        {
          "match":
          {
            "type": "value",
            "value": "refs/heads/master",
            "parameter":
            {
              "source": "payload",
              "name": "ref"
            }
          }
        }
      ]
    }
  }
]

確認する最後の構成項目の1つは、サーバーのファイアウォール設定です。 Webhookサーバーはポート9000でリッスンします。 つまり、サーバーでファイアウォールが実行されている場合、このポートへの接続を許可する必要があります。 現在のファイアウォールルールのリストを表示するには、次のように入力します。

sudo ufw status

ポート9000がリストに含まれていない場合は、次のように有効にします。

sudo ufw allow 9000

ufwの詳細については、このufw essentialsの概要を参照してください。

次に、GitHubリポジトリを設定して、このエンドポイントにHTTPリクエストを送信します。

[[step-4 -—- configuring-github-notifications]] ==ステップ4—GitHub通知の構成

マスターへのコミットが発生したときにHTTPリクエストを送信するようにGitHubリポジトリを設定しましょう:

  • 1. リポジトリに移動し、Settingsをクリックします。

  • 2. 次に、Webhooksに移動し、右上隅にあるAdd Webhookをクリックします。

  • 3. Payload URLには、サーバーアドレスを次のように入力します:http://your_server_ip:9000/hooks/redeploy-app。 ドメイン名がある場合は、your_server_ipの代わりにそれを使用できます。 エンドポイント名は、フック定義のidプロパティと一致することに注意してください。 これはWebhook実装の詳細です。hooks.jsonで定義されたすべてのフックはhttp://your_server_ip:9000/hooks/idとしてURLに表示されます。ここで、idhooks.jsonファイルのidです。

  • 4. Content typeには、application/jsonを選択します。

  • 5. Secretには、hooks.json定義で設定したシークレット(your-github-secret)を入力します。

  • 6. Which events would you like to trigger this webhook?には、Just push eventを選択します。

  • 7. Add webhookボタンをクリックします。

これで、誰かがリポジトリにコミットをプッシュすると、GitHubはコミットイベントに関する情報を含むペイロードを含むPOSTリクエストを送信します。 他の便利なプロパティの中でも、トリガールールで定義したプロパティが含まれるため、WebhookサーバーはPOSTリクエストが有効かどうかを確認できます。 そうである場合は、pusher.nameなどの他の情報が含まれます。

ペイロードとともに送信されるプロパティの完全なリストは、GitHub Webhooks pageにあります。

[[step-5 -—- writing-the-deploy-redeploy-script]] ==ステップ5—デプロイ/再デプロイスクリプトの記述

この時点で、Webhookをredeploy.shスクリプトにポイントしましたが、スクリプト自体は作成していません。 リポジトリから最新のマスターブランチを取得し、ノードモジュールをインストールし、ビルドコマンドを実行します。

スクリプトを作成します。

nano /opt/scripts/redeploy.sh

まず、作成したファイルをクリーンアップする関数をスクリプトの先頭に追加します。 再デプロイが正常に完了しなかった場合、Slackなどのサードパーティソフトウェアに通知する場所としてこれを使用することもできます。

/opt/scripts/redeploy.sh

#!/bin/bash -e

function cleanup {
      echo "Error occoured"
      # !!Placeholder for Slack notification
}
trap cleanup ERR

これは、スクリプトが突然終了した場合、cleanup関数のコードを実行する必要があることをbashインタープリターに通知します。

次に、スクリプトの実行時にwebhookがスクリプトに渡すパラメーターを抽出します。

/opt/scripts/redeploy.sh

...

commit_message=$1 # head_commit.message
pusher_name=$2 # pusher.name
commit_id=$3 # head_commit.id


# !!Placeholder for Slack notification

パラメータの順序は、hooks.jsonファイルのpass-arguments-to-commandプロパティに対応していることに注意してください。

最後に、アプリケーションの再デプロイに必要なコマンドを呼び出しましょう。

/opt/scripts/redeploy.sh

...

cd ~/do-react-example-app/
git pull origin master
yarn && yarn build

# !!Placeholder for Slack notification

完全なスクリプトは次のようになります。

/opt/scripts/redeploy.sh

#!/bin/bash -e

function cleanup {
      echo "Error occoured"
      # !!Placeholder for Slack notification
}
trap cleanup ERR

commit_message=$1 # head_commit.message
pusher_name=$2 # pusher.name
commit_id=$3 # head_commit.id

# !!Placeholder for Slack notification

cd ~/do-react-example-app/
git pull origin master
yarn && yarn build

# !!Placeholder for Slack notification

スクリプトはフォルダーに移動し、最新のマスターブランチからコードを取得し、新しいパッケージをインストールし、アプリケーションの製品バージョンをビルドします。

!!Placeholder for Slack notificationに注意してください。 これは、このチュートリアルの最後のステップのプレースホルダーです。 通知がなければ、スクリプトが適切に実行されたかどうかを知る本当の方法はありません。

フックが実行できるようにスクリプトを実行可能にします。

chmod +x /opt/scripts/redeploy.sh

Nginxは/var/www/do-react-example-app/buildからのファイルを提供するように構成されているため、このスクリプトが実行されると、ビルドディレクトリが更新され、Nginxは自動的に新しいファイルを提供します。

これで、構成をテストする準備が整いました。 webhookサーバーを実行してみましょう。

webhook -hooks /opt/hooks/hooks.json -verbose

-hooksパラメータは、webhookに構成ファイルの場所を通知します。

次の出力が表示されます。

Output[webhook] 2017/12/10 13:32:03 version 2.6.5 starting
[webhook] 2017/12/10 13:32:03 setting up os signal watcher
[webhook] 2017/12/10 13:32:03 attempting to load hooks from /opt/hooks/hooks.json
[webhook] 2017/12/10 13:32:03 os signal watcher ready
[webhook] 2017/12/10 13:32:03 found 1 hook(s) in file
[webhook] 2017/12/10 13:32:03   loaded: redeploy-app
[webhook] 2017/12/10 13:32:03 serving hooks on http://0.0.0.0:9000/hooks/{id}

これは、すべてが正しくロードされ、サーバーがURLhttp://0.0.0.0:9000/hooks/redeploy-appを介してフックredeploy-appを提供していることを示しています。 これにより、実行可能なサーバー上のパスまたはフックが公開されます。 このURLで単純なREST呼び出し(GETなど)を実行すると、フックルールが満たされないため、特別なことは何も起こりません。 フックを正常にトリガーする場合は、hooks.jsonで定義したtrigger-ruleを満たす必要があります。

ローカルプロジェクトディレクトリで空のコミットを使用してこれをテストしてみましょう。 webhookサーバーを実行したまま、ローカルマシンに戻って次を入力します。

git commit --allow-empty -m "Trigger notification"

コミットをmasterブランチにプッシュします。

git push origin master

サーバーに次のような出力が表示されます。

Output[webhook] 2018/06/14 20:05:55 [af35f1] incoming HTTP request from 192.30.252.36:49554
[webhook] 2018/06/14 20:05:55 [af35f1] redeploy-app got matched
[webhook] 2018/06/14 20:05:55 [af35f1] redeploy-app hook triggered successfully
[webhook] 2018/06/14 20:05:55 200 | 726.412µs | 203.0.113.0:9000 | POST /hooks/redeploy-app
[webhook] 2018/06/14 20:05:55 [af35f1] executing /opt/scripts/redeploy.sh (/opt/scripts/redeploy.sh) with arguments ["/opt/scripts/redeploy.sh" "Trigger notification" "sammy" "82438acbf82f04d96c53cd684f8523231a1716d2"] and environment [] using /opt/scripts as cwd

それでは、Slack通知を追加して、フックが通知付きのビルドの成功をトリガーしたときの動作を見てみましょう。

[[step-6 -—- adding-slack-notifications]] ==ステップ6—Slack通知を追加する

アプリが再デプロイされたときにSlack通知を受信するには、redeploy.shスクリプトを変更してHTTPリクエストをSlackに送信します。 また、Slack構成パネルでWebhook Integrationを有効にして、サーバーから通知を受信するようにSlackを構成する必要があります。 SlackからWebhook URLを取得したら、SlackWebhookサーバーに関する情報をスクリプトに追加できます。

Slackを構成するには、次の手順を実行します。

  • 1. Slackアプリケーションのメイン画面で、左上にあるドロップダウンメニューをクリックし、Customize Slackを選択します。

  • 2. 次に、左側のサイドバーMenuにあるConfigure Appsセクションに移動します。

  • 3. Manageパネルで、左側のオプションリストからCustom Integrationを選択します。

  • 4. Incoming WebHooks積分を検索します。

  • 5. Add Configurationをクリックします。

  • 6. 既存のチャネルを選択するか、新しいチャネルを作成します。

  • 7. Add Incoming WebHooks integrationをクリックします。

その後、Slack webhook設定を表示する画面が表示されます。 Slack Webhookサーバーによって生成されたエンドポイントであるWebhook URLをメモします。 このURLのメモとその他の変更が終了したら、必ずページの下部にあるSave Settingsボタンを押してください。

サーバーに戻り、redeploy.shスクリプトを開きます。

nano /opt/scripts/redeploy.sh

前の手順では、!!Placeholder for Slack notificationとして示されるSlack通知のプレースホルダーをスクリプトに残しました。 これらを、SlackWebhookサーバーにPOSTHTTPリクエストを行うcurl呼び出しに置き換えます。 SlackフックはJSONボディを予期し、それを解析して、チャネルに適切な通知を表示します。

!!Placeholder for slack notificationを次のcurl呼び出しに置き換えます。 your_slack_webhook_urlを前にメモしたWebhook URLに置き換える必要があることに注意してください。

/opt/scripts/redeploy.sh

#!/bin/bash -e

function cleanup {
      echo "Error occoured"
      curl -X POST -H 'Content-type: application/json' --data "{
              \"text\": \"Error occoured while building app with changes from ${pusher_name} (${commit_id} -> ${commit_message})\",
              \"username\": \"buildbot\",
              \"icon_url\": \"https://i.imgur.com/JTq5At3.png\"
      }" your_slack_webhook_url
}
trap cleanup ERR

commit_message=$1 # head_commit.message
pusher_name=$2 # pusher.name
commit_id=$3 # head_commit.id

curl -X POST -H 'Content-type: application/json' --data "{
        \"text\": \"Started building app with changes from ${pusher_name} (${commit_id} -> ${commit_message})\",
        \"username\": \"buildbot\",
        \"icon_url\": \"https://i.imgur.com/JTq5At3.png\"
}" your_slack_webhook_url

cd ~/do-react-example-app/
git pull origin master
yarn && yarn build

curl -X POST -H 'Content-type: application/json' --data "{
        \"text\": \"Build and deploy finished with changes from ${pusher_name} (${commit_id} -> ${commit_message})\",
        \"username\": \"buildbot\",
        \"icon_url\": \"https://i.imgur.com/JTq5At3.png\"
}" your_slack_webhook_url

各プレースホルダーをわずかに異なるcurl呼び出しに置き換えました。

  • 1つ目は、スクリプトの実行中に発生したエラーの通知を受け取ることを保証します。

  • 2番目は、アプリケーションのビルドが開始されたという通知を送信します。

  • 3番目は、ビルドが正常に終了したという通知を送信します。

Slackボットと統合の詳細については、Slack webhooks documentationを参照してください。

繰り返しますが、ローカルプロジェクトディレクトリで空のコミットを使用してフックをテストできます。 webhookサーバーを実行したまま、このディレクトリに戻って空のコミットを作成します。

git commit --allow-empty -m "Trigger notification"

コミットをmasterブランチにプッシュして、ビルドをトリガーします。

git push origin master

ビルド情報を含む出力は次のようになります。

Output[webhook] 2018/06/14 20:09:55 [1a67a4] incoming HTTP request from 192.30.252.34:62900
[webhook] 2018/06/14 20:09:55 [1a67a4] redeploy-app got matched
[webhook] 2018/06/14 20:09:55 [1a67a4] redeploy-app hook triggered successfully
[webhook] 2018/06/14 20:09:55 200 | 462.533µs | 203.0.113.0:9000 | POST /hooks/redeploy-app
[webhook] 2018/06/14 20:09:55 [1a67a4] executing /opt/scripts/redeploy.sh (/opt/scripts/redeploy.sh) with arguments ["/opt/scripts/redeploy.sh" "Trigger notification" "sammy" "5415869a4f126ccf4bfcf2951bcded69230f85c2"] and environment [] using /opt/scripts as cwd
[webhook] 2018/06/14 20:10:05 [1a67a4] command output:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   228    0     2  100   226     11   1324 --:--:-- --:--:-- --:--:--  1329
okFrom https://github.com/sammy/do-react-example-app
 * branch            master     -> FETCH_HEAD
   82438ac..5415869  master     -> origin/master
Updating 82438ac..5415869
Fast-forward
yarn install v1.7.0
[1/4] Resolving packages...
success Already up-to-date.
Done in 1.16s.
yarn run v1.7.0
$ react-scripts build
Creating an optimized production build...
Compiled successfully.

File sizes after gzip:

  36.94 KB  build/static/js/main.a0b7d8d3.js
  299 B     build/static/css/main.c17080f1.css

The project was built assuming it is hosted at the server root.
You can control this with the homepage field in your package.json.
For example, add this to build it for GitHub Pages:

  "homepage" : "http://myname.github.io/myapp",

The build folder is ready to be deployed.
You may serve it with a static server:

  yarn global add serve
  serve -s build

Find out more about deployment here:

  http://bit.ly/2vY88Kr

Done in 7.72s.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   233    0     2  100   231     10   1165 --:--:-- --:--:-- --:--:--  1166
ok
[webhook] 2018/06/14 20:10:05 [1a67a4] finished handling redeploy-app

Slackでは、選択したチャンネルにメッセージが届き、アプリケーションのビルドが開始したことと終了したことを通知します。

結論

これで、webhook、Nginx、シェルスクリプト、およびSlackを使用した展開システムのセットアップが完了しました。 次のことができるはずです。

  • アプリケーションの動的ビルドで動作するようにNginxを構成します。

  • webhookサーバーをセットアップし、GitHub POSTリクエストでトリガーするフックを作成します。

  • アプリケーションのビルドと通知をトリガーするスクリプトを作成します。

  • これらの通知を受信するようにSlackを構成します。

Webhookサーバーはモジュール式であり、GitLabなどの他のアプリケーションと連携するように構成できるため、このチュートリアルのシステムは拡張できます。 JSONを使用してWebhookサーバーを構成するのが多すぎる場合は、Hookdooを使用して同様のセットアップを構築できます。 webhookのトリガールールを構成する方法の詳細については、Webhookプロジェクトexample hooks pageを参照してください。

Related