Ubuntu16.04でのWebhookとSlackを使用したReactアプリケーションのデプロイ
序章
開発者がアプリケーションに継続的な変更を加える場合、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アプリケーションを作成する
まず、Webhookのテストに使用するアプリケーションを作成しましょう。 create-react-app
. 次に、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"
}
}
The 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ファイル。 The 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
これにより、Nginxはサーバーブロック構成を有効にするように指示されます。 sites-available
フォルダ。
構成が有効かどうかを確認します。
- 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
次に、設定しましょう hooks
と scripts
内のフォルダ /opt
ディレクトリ。通常、サードパーティアプリケーションのファイルが保存されます。 以来 /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
次に、構成しましょう webhook
サーバーを作成して hooks.json
ファイル。 と nano
またはお気に入りのエディタで、 hooks.json
のファイル /opt/hooks
ディレクトリ:
- nano /opt/hooks/hooks.json
のために webhook
GitHubがHTTPリクエストを送信したときにトリガーされるようにするには、ファイルにルールのJSON配列が必要です。 これらのルールは、次のプロパティで構成されています。
{
"id": "",
"execute-command": "",
"command-working-directory": "",
"pass-arguments-to-command": [],
"trigger-rule": {}
}
具体的には、これらのルールは次の情報を定義します。
- id :Webhookサーバーがサービスを提供するエンドポイントの名前。 これを呼びます
redeploy-app
. - execute-command :フックがトリガーされたときに実行されるスクリプトへのパス。 私たちの場合、これは
redeploy.sh
にあるスクリプト/opt/scripts/redeploy.sh
. - command-working-directory :コマンドの実行時に使用される作業ディレクトリ。 我々は使用するだろう
/opt/scripts
それはどこにあるのでredeploy.sh
位置しています。 - pass-arguments-to-command :HTTPリクエストからスクリプトに渡されるパラメーター。 HTTPリクエストのペイロードからコミットメッセージ、プッシャー名、コミットIDを渡します。 これと同じ情報がSlackメッセージにも含まれます。
The /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サーバーに送信したときにトリガーされるようにフックを構成します。 具体的には、GitHubシークレット(ここでは次のように示されます)の場合にのみトリガーされます your-github-secret
)HTTPリクエストのリクエストはルールのリクエストと一致し、コミットは 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
それはid
のhooks.json
ファイル。
- ペイロードURLの場合、サーバーアドレスを次のように入力します。
-
- コンテンツタイプには、 application /jsonを選択します。
-
- シークレットにシークレット(
your-github-secret
)で設定したhooks.json
意味。
- シークレットにシークレット(
-
- この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
パラメータの順序がに対応していることに注意してください pass-arguments-to-command
からのプロパティ hooks.json
ファイル。
最後に、アプリケーションの再デプロイに必要なコマンドを呼び出しましょう。
...
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
The -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}
これは、すべてが適切にロードされ、サーバーがフックを提供していることを示しています。 redeploy-app
URL経由 http://0.0.0.0:9000/hooks/redeploy-app
. これにより、実行可能なサーバー上のパスまたはフックが公開されます。 このURLを使用して単純なREST呼び出し(GETなど)を実行すると、フックルールが満たされていないため、特別なことは何も起こりません。 フックを正常にトリガーする場合は、 trigger-rule
で定義しました hooks.json
.
ローカルプロジェクトディレクトリの空のコミットでこれをテストしてみましょう。 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
前の手順では、Slack通知のスクリプトにプレースホルダーを残しました。 !!Placeholder for Slack notification
. これらを次のように置き換えます curl
SlackWebhookサーバーに対してPOSTHTTPリクエストを行う呼び出し。 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プロジェクトサンプルフックページにあります。