Ubuntu16.04でのWebhookとSlackを使用したReactアプリケーションのデプロイ
著者は、 Write forDOnationsプログラムの一環として寄付を受け取るためにTechEducationFundを選択しました。
序章
開発者がアプリケーションに継続的な変更を加える場合、Webhookを備えたデプロイメントシステムは、特にチームの開発を合理化できます。 チームの一部がAPIなどのバックエンドソフトウェアに依存している場合は、コード変更のSlack通知をチームのワークフローに統合することも役立ちます。
このチュートリアルでは、create-react-appnpmパッケージを使用してReactアプリケーションをビルドします。 このパッケージは、構文をトランスパイルし、依存関係と前提条件ツールを使用して作業を合理化することにより、Reactプロジェクトのブートストラップ作業を簡素化します。 アプリケーションコードをGitHubリポジトリに追加した後、更新されたプロジェクトファイルを提供するようにNginxを構成します。 次に、Webhookサーバーをダウンロードしてセットアップし、コードが変更されたときにGitHubと通信するように構成します。 最後に、別のWebhookサーバーとして機能するようにSlackを構成します。このサーバーは、デプロイが成功したときに通知を受け取ります。
最終的に、この記事で構築しているデプロイメントシステムは次のようになります。
この短いビデオは、空のコミットとGitHubリポジトリへのプッシュを示しています。これにより、Slackでアプリケーションのビルドと通知がトリガーされます。
前提条件
このチュートリアルを完了するには、次のものが必要です。
- Ubuntu 16.04サーバー。これは、Ubuntu16.04チュートリアルを使用したサーバーの初期設定に従ってセットアップできます。 このガイドに従うと、sudo権限を持つroot以外のユーザーアカウントが必要になります。
- Ubuntu 16.04にNginxをインストールする方法の最初の2つの手順に従って、サーバーにNginxをインストールします。
- ローカルマシンとサーバーの両方でGitが構成されています。 Gitのインストールと構成の手順については、このチュートリアルのGitの使用を開始する方法を参照してください。
- Node.jsと
npm
がローカルマシンとサーバーにインストールされています。 サーバーについては、 Ubuntu16.04にNode.jsをインストールする方法のPPAからNode.jsをインストールする手順に従ってください。 ローカルマシンでは、プロジェクトのインストール手順に従うことができます。 - ヤーンのインストールの公式ガイドに従って、サーバーにヤーンをインストールします。
- 通知用にSlackと個々のチャネルを構成するためのアクセス許可。 役割と権限の詳細については、Slack権限ドキュメントをご覧ください。
ステップ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
ファイルは次のようになります。
{
"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 :このスクリプトは、プロジェクトに関連付けられたデフォルトのテストを実行します。
- subject :このスクリプトは、
create-react-app
パッケージの高度な機能です。 開発者がパッケージが提供するビルド環境に満足していない場合は、アプリケーションを「イジェクト」することができます。これにより、他の方法では利用できないオプション(カスタムCSSトランスパイラーやJS処理ツールなど)が生成されます。
コードの検査が終了したら、ファイルを閉じます。
次に、プロジェクトのGitHubリポジトリを作成しましょう。 ガイダンスとして、GitHubリポジトリの作成に関するこのチュートリアルに従うことができます。 リポジトリの起源に注意してください(つまり そのGitHubURL)。
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のドキュメントを参照してください。
リポジトリのセットアップが完了したら、サーバーでの構成の詳細の指定に進むことができます。
ステップ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またはドメイン(該当する場合)に置き換えます。
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.html
、index.htm
、index.nginx-debian.html
、最初から最後まで優先されます。 - server_name :サーバーのドメイン名またはIP。
次に、sites-enabled
ディレクトリにシンボリックリンクを作成します。
- sudo ln -s /etc/nginx/sites-available/test-server /etc/nginx/sites-enabled/test-server
これにより、sites-available
フォルダーからサーバーブロック構成を有効にするようにNginxに指示されます。
構成が有効かどうかを確認します。
- sudo nginx -t
最後に、Nginxを再起動して、新しい構成を適用します。
- sudo systemctl restart nginx
これらの構成の詳細が整ったら、Webhookの構成に進むことができます。
ステップ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
ディレクトリにhooks
フォルダとscripts
フォルダを設定します。このフォルダには、通常、サードパーティアプリケーションのファイルがあります。 /opt
ディレクトリは通常root
によって所有されているため、root権限でディレクトリを作成してから、所有権をローカルの$USER
に譲渡できます。
まず、ディレクトリを作成します。
- 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
ファイルには、次の情報が含まれている必要があります。
[
{
"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.message
、pusher.name
、およびhead_commit.id
プロパティが含まれています。 構成されたイベント(PUSHなど)がGitHubリポジトリで発生すると、GitHubはイベントに関する情報を含むJSON本文を含むPOSTリクエストを送信します。 これらのPOSTペイロードの例は、GitHubイベントタイプドキュメントにあります。
構成ファイルの最後のプロパティはtrigger-rule
プロパティです。これは、フックがトリガーされる条件をWebhookサーバーに通知します。 空のままにすると、フックは常にトリガーされます。 この例では、GitHubがPOSTリクエストをWebhookサーバーに送信したときにトリガーされるようにフックを構成します。 具体的には、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
は次のようになります。
[
{
"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
の詳細については、この ufwEssentialsの概要を参照してください。
次に、このエンドポイントにHTTPリクエストを送信するようにGitHubリポジトリを設定しましょう。
ステップ4—GitHub通知を構成する
マスターへのコミットが発生したときにHTTPリクエストを送信するようにGitHubリポジトリを構成しましょう。
-
- リポジトリに移動し、設定をクリックします。
-
- 次に、 Webhook に移動し、右上隅にあるWebhookの追加をクリックします。
-
- ペイロードURLの場合、サーバーアドレスを次のように入力します:
http://your_server_ip:9000/hooks/redeploy-app
。 ドメイン名をお持ちの場合は、your_server_ip
の代わりに使用できます。 エンドポイント名は、フック定義のid
プロパティと一致することに注意してください。 これはWebhook実装の詳細です。hooks.json
で定義されたすべてのフックはURLにhttp://your_server_ip:9000/hooks/id
として表示されます。ここで、id
はhooks.json
ファイル。
- ペイロードURLの場合、サーバーアドレスを次のように入力します:
-
- コンテンツタイプには、 application /jsonを選択します。
-
- シークレットには、
hooks.json
定義で設定したシークレット(your-github-secret
)を入力します。
- シークレットには、
-
- このWebhookをトリガーするイベントはどれですか?イベントをプッシュするを選択します。
-
- Webhookの追加ボタンをクリックします。
これで、誰かがコミットをリポジトリにプッシュすると、GitHubはコミットイベントに関する情報を含むペイロードを含むPOSTリクエストを送信します。 他の便利なプロパティの中でも、トリガールールで定義したプロパティが含まれるため、WebhookサーバーはPOSTリクエストが有効かどうかを確認できます。 含まれている場合は、pusher.name
などの他の情報が含まれます。
ペイロードとともに送信されるプロパティの完全なリストは、GitHubWebhookページにあります。
ステップ5—デプロイ/再デプロイスクリプトの作成
この時点で、Webhookにredeploy.sh
スクリプトを指定しましたが、スクリプト自体は作成していません。 リポジトリから最新のマスターブランチをプルし、ノードモジュールをインストールし、ビルドコマンドを実行する作業を行います。
スクリプトを作成します。
- nano /opt/scripts/redeploy.sh
まず、スクリプトの先頭に、作成したファイルをクリーンアップする関数を追加しましょう。 再デプロイが正常に行われなかった場合に、Slackなどのサードパーティソフトウェアに通知する場所としてこれを使用することもできます。
#!/bin/bash -e
function cleanup {
echo "Error occoured"
# !!Placeholder for Slack notification
}
trap cleanup ERR
これは、bash
インタープリターに、スクリプトが突然終了した場合、cleanup
関数でコードを実行する必要があることを通知します。
次に、スクリプトの実行時にwebhook
がスクリプトに渡すパラメーターを抽出します。
...
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
プロパティに対応していることに注意してください。
最後に、アプリケーションの再デプロイに必要なコマンドを呼び出しましょう。
...
cd ~/do-react-example-app/
git pull origin master
yarn && yarn build
# !!Placeholder for Slack notification
完全なスクリプトは次のようになります。
#!/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"
コミットをマスターブランチにプッシュします。
- 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通知を追加し、フックが通知を使用してビルドを成功させたときに何が起こるかを見てみましょう。
ステップ6—Slack通知を追加する
アプリが再デプロイされたときにSlack通知を受信するには、redeploy.sh
スクリプトを変更してHTTPリクエストをSlackに送信します。 また、Slack構成パネルで Webhook統合を有効にして、サーバーから通知を受信するようにSlackを構成する必要があります。 SlackからWebhookURL を取得したら、SlackWebhookサーバーに関する情報をスクリプトに追加できます。
Slackを設定するには、次の手順を実行します。
-
- Slackアプリケーションのメイン画面で、左上にあるドロップダウンメニューをクリックし、Slackのカスタマイズを選択します。
-
- 次に、左側のサイドバーメニューにあるアプリの構成セクションに移動します。
-
- 管理パネルで、左側のオプションリストからカスタム統合を選択します。
-
- 着信WebHooks統合を検索します。
-
- 構成の追加をクリックします。
-
- 既存のチャネルを選択するか、新しいチャネルを作成します。
-
- 着信WebHooks統合の追加をクリックします。
その後、SlackWebhook設定を表示する画面が表示されます。 SlackWebhookサーバーによって生成されるエンドポイントであるWebhookURLをメモします。 このURLのメモやその他の変更が終了したら、必ずページ下部の[設定の保存]ボタンを押してください。
サーバーに戻り、redeploy.sh
スクリプトを開きます。
- nano /opt/scripts/redeploy.sh
前の手順では、!!Placeholder for Slack notification
として示されるSlack通知のスクリプトにプレースホルダーを残しました。 これらを、SlackWebhookサーバーにPOSTHTTPリクエストを行うcurl
呼び出しに置き換えます。 SlackフックはJSON本体を想定しており、JSON本体が解析され、チャネルに適切な通知が表示されます。
!!Placeholder for slack notification
を次のcurl
呼び出しに置き換えます。 your_slack_webhook_url
を前述のWebhookURLに置き換える必要があることに注意してください。
#!/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ボットと統合の詳細については、SlackWebhookのドキュメントをご覧ください。
ここでも、ローカルプロジェクトディレクトリで空のコミットを使用してフックをテストできます。 Webhookサーバーを実行したまま、このディレクトリに戻り、空のコミットを作成します。
- git commit --allow-empty -m "Trigger notification"
コミットをマスターブランチにプッシュして、ビルドをトリガーします。
- 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サーバーをセットアップし、GitHubPOSTリクエストでトリガーするフックを記述します。
- アプリケーションのビルドと通知をトリガーするスクリプトを記述します。
- これらの通知を受信するようにSlackを構成します。
Webhookサーバーはモジュール式であり、 GitLab などの他のアプリケーションと連携するように構成できるため、このチュートリアルのシステムを拡張できます。 JSONを使用してWebhookサーバーを構成するのが多すぎる場合は、Hookdooを使用して同様のセットアップを構築できます。 webhook
のトリガールールを構成する方法の詳細については、webhookプロジェクトサンプルフックページを参照してください。