著者は、Write for DOnationsプログラムの一部として寄付を受け取るためにTech Education Fundを選択しました。
前書き
開発者がアプリケーションを継続的に変更している場合、webhookを備えた展開システムは、特にチーム向けに開発を効率化できます。 チームの一部がAPIなどのバックエンドソフトウェアに依存している場合、コードの変更に関するSlack通知をチームのワークフローに統合することも役立ちます。
このチュートリアルでは、create-react-app
npm
packageを使用してReactアプリケーションを構築します。 このパッケージは、構文を変換し、依存関係および前提条件ツールを使用して作業を合理化することにより、Reactプロジェクトのブートストラップ作業を簡素化します。 アプリケーションコードをGitHubリポジトリに追加した後、更新されたプロジェクトファイルを提供するようにNginxを構成します。 次に、webhookサーバーをダウンロードしてセットアップし、コードが変更されたときにGitHubと通信するように構成します。 最後に、Slackを別のwebhookサーバーとして機能するように設定します。これは、展開が正常にトリガーされたときに通知を受け取ります。
最終的に、この記事で構築する展開システムは次のようになります。
この短いビデオでは、空のコミットと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.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
これにより、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.message
、pusher.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に表示されます。ここで、id
はhooks.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を参照してください。