DockerとCoreOSを使用してDigitalOceanでReviewNinjaをセルフホストする方法

前書き

コードレビューは、現代のソフトウェア開発プロセスの不可分な部分となっています。 分散バージョン管理システムの出現により、特にGitHubの誕生以降、プルリクエスト-レビュー-マージモデルがソフトウェア開発コミュニティの間で普及しました。 ただし、GitHubに組み込まれているプルリクエストレビューシステムには、多くの要望が残されています。 その結果、プロセスを改善するために、GitHubと統合する多くのサードパーティコードレビューツールが存在します。 ReviewNinjaはそのようなツールの1つです。

ReviewNinjaは、バニラGitHubプルリクエストレビューエクスペリエンスに加えて、いくつかの機能を追加します。 「忍者の星」を与えることでプルリクエストを明示的に承認することができるため、「:shipit:」、「+ LGTM 」、またはその他の一般的な規則などのコメントは不要になります。 また、プルリクエストが少なくとも2人のチームメンバーによってサインオフされていない場合、または誰かがプルリクエストに「!fix +」などのコメントを追加した場合、マージをブロックするポリシーを設定できます。

ReviewNinjaは、SAPによって開発およびオープンソース化されています。 hosted versionがありますが、独自のサーバーにデプロイして、プライベートGitHubリポジトリに使用できます。

このガイドでは、https://www.docker.com [Docker]およびhttps://coreos.com [CoreOS]を使用して、DigitalOceanにReviewNinjaインスタンスをデプロイします。 実稼働用のReviewNinjaインスタンスにはいくつかの可動部分があるため、 `+ docker-machine `を使用してリモートDockerホストを作成および制御し、 ` docker-compose `を使用してスタックを記述、ビルド、デプロイします。 DockerホストにはCoreOSを使用します。これは、クラウド展開に合わせた最小限のLinuxディストリビューションです。 CoreOSの新規インストールでは、 ` systemd +`とDockerデーモンのみが実行されるため、アプリケーションで使用できるリソースが増えています。

前提条件

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

  • ローカルマシンにDocker、 + docker-machine、および` + docker-compose`がインストールされているため、デプロイするアプリケーションイメージをビルドできます。 https://docs.docker.com/engine/installation/ [公式インストールドキュメント]に従ってDockerを実行し、これらのツールを構成できます。 + docker-machine`と + docker-compose`は両方ともDockerアプリと共にOSXおよびWindowsに自動的にインストールされますが、これらのリンクを使用して手動でインストールすることもできます。

  • Docker Composeインストールガイド

  • Docker Machineインストールガイド

  • Gitがローカルマシンにインストールされているため、ReviewNinjaリポジトリのクローンを作成してコンテナーを作成できます。 この前提条件を満たす必要がある場合は、https://git-scm.com/book/en/v2/Getting-Started-Installing-Git [公式Gitインストールドキュメント]に従ってください。

  • Applications&APIページにアクセスして生成できる読み取りと書き込みの両方のアクセス権を持つDigitalOceanアクセストークン。 ホストを作成するために `+ docker-machine`で使用する必要があるため、このトークンをコピーします。

  • このチュートリアルでは、「+ docker-machine +」を使用して設定する1 GBのCoreOSドロップレット。

  • http://github.com [GitHub]アカウント。

ステップ1-CoreOSベースのDockerホストの作成とアクティブ化

展開用のインフラストラクチャをセットアップしましょう。 `+ docker-machine `ツールを使用すると、リモートマシンをDockerホストとしてプロビジョニングし、ローカルマシンから制御できます。 DigitalOceanを含む多くの一般的なクラウドプロバイダーにドライバーを提供します。 ` docker-machine`を使用して、Dockerホスト用のCoreOSドロップレットを作成します。

端末に切り替え、DigitalOceanアクセストークンを使用して次のコマンドを発行します。

docker-machine create --driver=digitalocean \
--digitalocean-access-token= \
--digitalocean-image= \
--digitalocean-region= \
--digitalocean-size= \
--digitalocean-ssh-user= \

「+ docos-machine 」に、「 coreos-stable 」イメージと「 1GB 」のメモリを使用して、「 NYC3 」データセンターに「 reviewninja 」というドロップレットを作成するように指示しています。 CoreOSインストールのデフォルトユーザーは ` core `であるため、 `-ssh-user = core +`を指定していることに注意してください。

このコマンドを実行すると、次の出力が表示されます。

OutputRunning pre-create checks...
Creating machine...
(reviewninja) Creating SSH key...
(reviewninja) Creating Digital Ocean droplet...
(reviewninja) Waiting for IP address to be assigned to the Droplet...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with coreOS...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env reviewninja

この新しいドロップレットが「+ docker-machine +」によって認識されるかどうかを見てみましょう。 コマンドを実行します。

docker-machine ls

次の出力が表示されます。これは、Dockerホスト `+ reviewminja `が ` digitalocean +`ドライバーを使用してリモートIPアドレスで実行されていることを示しています。

OutputNAME          ACTIVE   DRIVER         STATE     URL                          SWARM   DOCKER    ERRORS
           digitalocean   Running   tcp://:2376            v1.10.3

Dockerホストを作成したとき、出力の最後の行から次に何をすべきかがわかりました。 と言いました:

OutputTo see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env reviewninja

それで、そのコマンドを実行しましょう:

docker-machine env reviewninja

次のメッセージが表示されます。

Outputexport DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://your_server_ip:2376"
export DOCKER_CERT_PATH="/home/kevin/.docker/machine/machines/reviewninja"
export DOCKER_MACHINE_NAME="reviewninja"
# Run this command to configure your shell:
# eval $(docker-machine env reviewninja)

ここで何が起きているのでしょうか? Dockerアーキテクチャは、クライアントサーバーモデルを使用します。 Dockerクライアントは、UnixソケットまたはTCPを介して通信できます。 通常、Dockerクライアントは、Unixソケットを介してローカルにインストールされたDockerエンジンと通信します。 ただし、TCPを介してDockerホストと通信するようにDockerクライアントに指示するために設定できる環境変数があります。 表示される出力は、まさにそれを行う環境変数を設定するための一連のシェルコマンドです。

最後の部分はこう言います:

Output# Run this command to configure your shell:
# eval $(docker-machine env reviewninja)

そのコマンドを実行するとき、これらのコマンドを実行するようシェルに指示します。これらのコマンドは、後続の `+ docker +`コマンドに使用される環境変数を設定します。

だから、シェルでそのコマンドを実行してください:

eval $(docker-machine env reviewninja)

これで、 `+ docker info +`を実行すると、ローカルDockerデーモンではなく、リモートDockerデーモンに関する情報が表示されます。

docker info

そのコマンドからの出力は次のようになります。

OutputContainers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 1.10.3
[...]
Labels:
provider=digitalocean

リモートDockerホストが構成され、Docker経由でアクセスできるようになりました。 ReviewNinjaコンテナーを作成する前に、GitHubで作業を行う必要があります。

ステップ2-GitHub OAuthアプリケーションを登録する

ReviewNinjaはGitHubのAPIを使用してリポジトリにアクセスする必要があるため、ReviewNinjaのインストールをGitHub OAuthアプリケーションとして登録します。

まず、サーバーのIPアドレスを見つける必要があります。 これを行うには、 `+ docker-machine`コマンドを使用できます。

docker-machine ip reviewninja

このコマンドが表示するIPアドレスを記録します。 次に、GitHubアカウントにログインし、[設定]→ [OAuthアプリケーション]→ [開発者アプリケーション]に移動して、[新しいアプリケーションの登録]ボタンを押します。

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/XwiaZRW.png [新しいGitHub OAuthアプリケーションフォーム]

新しいアプリケーションのフォームが表示されたら、次の情報を入力します。

  1. * Name *を `+ review-ninja +`に設定します。

  2. * Homepage URL *を `+ http:// +`に設定します。

  3. * Authorization Callback URL *を `+ http:/// auth / GitHub / callback +`に設定します。

次に、[アプリケーションの登録]ボタンを押して変更を保存し、アプリケーションを作成します。 これにより、新しく作成されたアプリケーションが画面に表示されます。

  • Client ID および Client Secret *の値を安全な場所に保存します。 ReviewNinjaアプリケーション構成にすぐに追加します。

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/pV4mht2.png [GitHubアプリのクライアントIDとシークレット]

キーを取得したら、ReviewNinjaインスタンスの作成を始めましょう。

ステップ3-ReviewNinja Dockerコンテナーの作成

ReviewNinjaは、MongoDBがサポートするストレージレイヤーに依存するNode.jsアプリケーションです。 そして、これを実稼働環境に配置するため、Node.jsアプリをプロキシサーバーの背後に配置して、アプリサーバーがインターネットに直接公開されないようにします。 この目的のためにNginxを使用します。 これは多くの設定が必要なため、https://docs.docker.com/compose/ [docker-compose]を使用して、関連する複数のコンテナーを宣言的に展開します。 必要な設定を定義し、 `+ docker-compose +`ツールを使用して、指定されたすべてのランタイム環境でコンテナーを作成します。

まず、ReviewNinjaソースコードを取得する必要があります。 Gitを使用して、ローカルマシンにソースコードを複製します。

git clone https://github.com/reviewninja/review.ninja.git

次に、プロジェクトのフォルダーに移動します。

cd review.ninja

このリポジトリには、 `+ Dockerfile +`が含まれています。これは、DockerにReviewNinjaアプリケーションイメージを構築する方法を指示します。 お気に入りのテキストエディターでこのファイルを開くと、次のコンテンツが表示されます。

Dockerfile

FROM node:0.12.2

COPY . /app

RUN npm install -g bower
RUN cd /app; npm install; bower install --allow-root;

WORKDIR /app

VOLUME ["/certs"]

EXPOSE 5000

CMD ["node", "/app/app.js"]

このファイルは、このアプリが使用するNode.jsのバージョンを指定します。 次に、すべてのファイルを現在のフォルダーから「+ app 」フォルダーにコピーし、すべてのアプリケーションの依存関係をインストールします。 次に、ポート「+5000」を公開し、アプリを起動します。 Dockerfilesの詳細については、https://www.digitalocean.com/community/tutorials/docker-explained-using-dockerfiles-to-automate-building-of-images [このチュートリアル]を参照してください。

DockerfileはReviewNinjaアプリケーションコンテナーを記述しますが、 `+ docker-compose.yml +`と呼ばれるファイル(https://en.wikipedia)を使用して、MongoDBやNginxプロキシを含むスタックのコンポーネントを記述できます。 org / wiki / YAML [YAML]ファイル。設定ファイルの一般的な形式です。

クローンを作成したリポジトリには「+ docker-compose-example.yml +」というファイルがありますが、サンプルがニーズを満たしていないため、独自のファイルをゼロから作成します。

まず、スタックのストレージを定義しましょう。 ファイル `+ docker-compose.yml +`を作成し、次の設定を入力します:

docker-compose.yml

version: "2"
services:
   db:
       image: mongo
       volumes:
           - /data:/data/db

`+ db `サービスは、Dockerイメージの中央リポジトリであるDocker Hubの公式https://hub.docker.com/_/mongo/[MongoDB image]を使用します。 設計上、Dockerコンテナは停止および削除されるとランタイム状態を失います。 「 web 」サービスでは、ステートレスなので問題ありません。 「 db 」サービスでは、サービスを停止または再起動してもコードレビューデータがすべて失われないように、データをディスクに保持する必要があります。 これが ` volumes +`の出番です。 実行時に、Dockerデーモンは、コンテナ内のボリュームをホスト上のディレクトリにマップするコンテナを実行できます。

この構成では、次を指定しました。

docker-compose.yml

       volumes:
           -

これにより、ホストマシンの `+ / data `フォルダーがコンテナー内の ` / data / db `にマッピングされます。これは、コンテナー内に書き込むようにMongoDBが構成されているフォルダーです。 このマッピングを作成することで、アプリによって行われた変更は、コンテナーではなく、 ` / data +`フォルダーのホストマシンに保持されます。

次に、ReviewNinjaアプリケーションコンテナーを定義します。 既存の設定の後に、これを `+ docker-compose.yml +`ファイルに追加します:

docker-compose.yml

services:
   db:
   [...]


       build: .
       working_dir: /app/
       links:
           - db
       environment:
           MONGODB: mongodb://db/reviewninja
           GITHUB_CLIENT:
           GITHUB_SECRET:

`+ build。`を使用します。これは、現在のフォルダーで調べたばかりの ` Dockerfile `からイメージをビルドする必要があることを ` docker-compose `に伝えます。 次に、「 db 」イメージへのリンクを宣言します。そのため、「 web 」コンテナ内で、「 db 」という名前は「 db 」コンテナのIPアドレスに解決されます。 これにより、基本的なサービス検出メカニズムが提供されます。事前に ` db `コンテナのIPアドレスを知り、それをハードコーディングしたり、環境変数を介して渡したりする必要はありません。 次に、そのリンクを使用して、値として ` mongodb:// db / reviewninja `を使用して、 ` MONGODB +`環境変数を定義します。

「+ GITHUB_CLIENT 」と「 GITHUB_SECRET +」に、作成したGitHubアプリのクライアントIDとシークレットを入力します。 ReviewNinjaアプリケーションは、実行時にこれらの環境変数を読み取ります。

最後に、リクエストをポート `+ 80 `からNode.jsアプリが使用するポートに転送する負荷分散サービスを定義しましょう。 この設定をファイルに追加し、作成したばかりの ` web +`サービス宣言で垂直に並べます:

docker-compose.yml

services:
   web:
   [...]

       image: nginx
       ports:
           - "80:80"
       volumes:
           - ./reviewninja.conf:/etc/nginx/conf.d/default
       command: /bin/bash -c "echo -e 'upstream backend { server web:5000; }\nserver { listen 80; location / { proxy_pass http://backend; }}' > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'"
       links:
           - web

Docker Hubのhttps://hub.docker.com/_/nginx/[official Nginx image]を使用し、ホストのポート「80」をバインドする「80:80」のポートマッピングを宣言しますコンテナに「80」を移植します。 次に、コンテナの外部にNginx設定ファイルを保存するボリュームマッピングを作成し、 `+ app +`コンテナへのコンテナリンケージを宣言して、名前とプロキシリクエストで検索できるようにします。

+ command +`宣言は非常に長いので、分解してみましょう。 実際には1行で2つのコマンドを実行しています。 最初のコマンドは `+ echo -e …​ >/etc/nginx/conf.d/default.conf+。ReviewNinja用のNginx構成ファイルを作成します。これは次のようになります。

default.conf

upstream backend {
   server web:5000;
}

server {
   listen       80;

   location / {
       proxy_pass http://backend;
   }
}

これは上流の `+ backend `を定義し、 ` web:5000 `を指します。 値「 web 」は「 links 」セクションの「 docker-compose.yml」ファイルから取得され、ポート「5000」はNode.jsサーバーが「+ web 」コンテナで使用するポートです。 次に、Nginxサーバーがコンテナーのポート「+80」で実行され、すべてのリクエストをアプリサーバーの「+ backend +」にプロキシする必要があることを宣言します。

コマンドの2番目の部分である `+ nginx -g 'daemon off' `は、コンテナでNginxサーバープロセスを実行するコマンドです。 Nginxはデフォルトでデーモンモードで実行され、実行中のプロセスから自身を切り離すため、「 daemon off +」を指定する必要があります。 Dockerは、コンテナエントリポイントから切り離されたプログラムを「終了」したと見なし、コンテナを終了して、すべてのプロセスを取得します。 経験則として、Dockerコンテナー内で実行されるプロセスはすべてフォアグラウンドで実行する必要があります。

次に進む前に設定を再確認したい場合のために、 `+ docker-compose.yml +`ファイル全体を以下に示します。

docker-compose.yml

version: "2"
services:
   db:
       image: mongo
       volumes:
           - /data:/data/db
   web:
       build: .
       working_dir: /app/
       links:
           - db
       environment:
           MONGODB: mongodb://db/reviewninja
           GITHUB_CLIENT:
           GITHUB_SECRET:
   nginx:
       image: nginx
       ports:
           - "80:80"
       volumes:
           - ./reviewninja.conf:/etc/nginx/conf.d/default
       command: /bin/bash -c "echo -e 'upstream backend { server web:5000; }\nserver { listen 80; location / { proxy_pass http://backend; }}' > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'"
       links:
           - web

`+ docker-compose.yml +`の構文とオプションについて詳しく知りたい場合は、https://docs.docker.com/compose/compose-file/ [docker-compose documentation]をご覧ください。

これで、このアプリケーションの構成が処理されます。 `+ docker-compose.yml +`ファイルを保存します。このアプリを展開する時が来ました。

ステップ4-コンテナのビルドとデプロイ

ReviewNinjaアプリ、データを保持するMongoDBインスタンス、およびNginxプロキシをデプロイするように + docker-compose +`を設定しました。 これらのコンテナをデプロイする前に、 `+ reviewninja + Dockerマシンがまだアクティブであることを確認しましょう。

docker-machine active

君は見るべきだ:

Outputreviewninja

その出力が表示されない場合は、必ず実行してください

eval $(docker-machine env reviewninja)

もう一度環境設定が正しいことを確認してください。 それからもう一度やり直してください。

アクティブなマシンがあることを確認したら、 `+ docker-compose +`を使用してスタックを構築します。

docker-compose build

このプロセスは、Dockerホスト上のReviewNinjaアプリケーションのすべての依存関係をダウンロードして構成するため、非常に時間がかかる場合があります。 次の出力が表示されます。

Outputdb uses an image, skipping
Building web
Step 1 : FROM node:0.12.2
0.12.2: Pulling from library/node
[...]
Successfully built 106a1992d538

ビルドプロセスが完了したら、成功したイメージがあることを確認します。

docker images

画像 `+ reviewninja_web +`が正常に作成されたことを示す次の出力が表示されます。

OutputREPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
    latest              106a1992d538        3 minutes ago       946.6 MB

これで、単一のコマンドでデータベース、ReviewNinjaアプリケーション、およびリモートサーバー上のNginxプロキシを起動できます。

docker-compose up -d

これにより、 `+ docker-compose `ファイルで定義したすべてのコンテナが表示されます。 「 -d +」(「デタッチ」)を使用して、すべてのコンテナをバックグラウンドで実行し、ターミナルをコントロールに戻します。

OutputCreating network "reviewninja_default" with the default driver
Pulling db (mongo:latest)...
latest: Pulling from library/mongo
[...]
Digest: sha256:d3f19457c816bb91c5639e3b1b50f67370e3b3a58b812d73446d7b966469c65e
Status: Downloaded newer image for mongo:latest
Creating reviewninja_db_1
Creating reviewninja_web_1
Creating reviewninja_nginx_1

コンテナが稼働していることを確認しましょう。 次のコマンドを実行してください。

docker ps

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

OutputCONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                         NAMES
29f8e6f770d3                       "nginx -g 'daemon off"   43 seconds ago      Up 41 seconds       0.0.0.0:80->80/tcp, 443/tcp   reviewninja_nginx_1
164564dd450a             "node /app/app.js"       45 seconds ago      Up 43 seconds       5000/tcp                      reviewninja_web_1
7cd9d03eb3b9                       "/entrypoint.sh mongo"   46 seconds ago      Up 44 seconds       27017/tcp                     reviewninja_db_1

また、サービスが適切に実行されていることを確認したいです。 そのためには、 `+ docker logs `コマンドを使用して、コンテナーの出力を確認します。 ReviewNinja Webアプリケーションのログを確認しましょう。 コンテナは、前の出力の「 CONTAINER ID 」列にリストされているIDまたは名前で参照できます。 この場合、名前は ` reviewninja_web_1 +`なので、そのコンテナのログを見てみましょう。

docker logs reviewninja_web_1

ReviewNinjaアプリから、接続をリッスンしていることを示す出力が表示されます。

OutputIn server/app.js
checking configs
✓ configs seem ok
Host:        http://localhost:5000
GitHub:      https://GitHub.com
GitHub-Api:  https://api.GitHub.com
bootstrap certificates
bootstrap static files
apply migrations
[...]
bootstrap mongoose
[...]
bootstrap passport
[...]
bootstrap controller
[...]
bootstrap api
[...]
bootstrap webhooks
[...]
bootstrap monkey patch

✓ bootstrapped, app listening on localhost:5000

出力は、ReviewNinjaがポート `+ 5000 +`でリッスンしていることを示しています。

Webからアクセスするには、CoreOSサーバーであるDockerホストのIPを使用する必要があります。 サーバーのIPアドレスを忘れた場合は、 `+ docker-machine`を使用して確認してください。

docker-machine ip reviewninja

ブラウザで「+ http:// +」を指定すると、忍者に挨拶されます。

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/u0XaI6c2.png [Review Ninja home page]

最後に、独自のコードでアプリケーションを使用する準備が整いました。

ステップ5-リポジトリでReviewNinjaを使用する

テストリポジトリでReviewNinjaの新しいインスタンスを試してみましょう。 プルリクエストに関するフィードバックを提供し、問題に対処し、変更を受け入れ、プルリクエストをマージします。

最初に、Review NinjaアプリがGitHubアカウントにアクセスできるようにする必要があります。 *サインイン*をクリックすると、GitHubにリダイレクトされてサインインします。 ReviewNinjaがGitHubアカウントにアクセスできるようにするかどうかを尋ねられます。

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/MTkYvlV.png [GitHubを通じてアプリの許可を付与]

アプリケーションを承認すると、ReviewNinjaのメインインターフェースが表示されます。 ReviewNinjaで使用するプライベートリポジトリがある場合は、[プライベートリポジトリを有効にする]リンクをクリックします。

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/PIKpsR4.png [プライベートリポジトリへのアクセスを有効にする]

その後、GitHubにリダイレクトされ、ReviewNinjaアプリの承認を修正して、プライベートリポジトリへのアクセスを含めます。

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/XE19ZNH.png [プライベートリポジトリの認証]

ReviewNinjaに必要なアクセス権を付与したら、プルリクエストワークフローにReviewNinjaを使用できるようにリポジトリを追加できます。 ReviewNinjaを初めて使用するときは、サンプルの `+ ReviewNinja-Welcome +`リポジトリを追加できます。

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/NYEEt1I.png [サンプルリポジトリの追加]

このサンプルリポジトリを作成して、ReviewNinjaの基本的な機能をいくつか見ていきましょう。 これにより、アカウントの下のGithubにリポジトリが作成され、ReviewNinjaに追加されます。

サンプルリポジトリには、Review Ninjaのコードレビューフローの機能の一部の概要を示す「+ ReadMe.md」ファイルが含まれています。 `+ ReviewNinja-Welcome `リポジトリには、 ` ReadMe.md `ファイルの更新されたコピーを持つブランチ ` -patch-1 +`からのプルリクエストが既に開かれています。 ブランチの名前は、ユーザー名によって異なります。

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/x3UtL1D.png [プルリクエストビュー]

そのブランチをクリックすると、メインのコードレビューインターフェイスが表示され、差分を参照してコメントを追加できます。 また、プルリクエストのステータスと未解決の問題の概要を示すプルリクエストステータスボックスが表示されます。

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/Vya96ZR.png [プルリクエストステータスボックス]

プルリクエストのステータスが「pending」であるため、* Mull pull request *ボタンは現在オレンジです。 状態は、ギアボタンをクリックして微調整できる条件に基づいて変化します。 デフォルトでは、ボタンが緑色に変わるには少なくとも1つの忍者の星が必要です。

これについては後で説明しますが、今のところは行コメントを追加しましょう。 というコード行をクリックします

+ convenience we also have a dropdown menu to add these comments

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/HxPuLqp.png [行コメントを追加]

ここで少し物足りになり、「+ dropdown 」という単語を「 drop-down 」に変更することを提案しましょう。 次の図に示すように、画面の右側にあるコメントボックスを使用してコメントを追加し、コメントに `!fix +`を追加して、ブロックの問題としてこれにフラグを付けます。

画像:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/8TR7A1C.png [フラグを立てる]

フラグの付いたコメントは、プルリクエストの「問題」と見なされます。プルリクエストの作成者は、ReviewNinjaがマージを許可する前に対処する必要があります。

ページを更新すると、[プルリクエストの統合]ボタンの上に新しい問題が表示されます。

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/Blj02xW.png [私たちの問題]

その問題を修正しましょう。 ローカルマシンで、Gitを使用してリポジトリを複製します。

git clone [email protected]:/ReviewNinja-Welcome.git
cd ReviewNinja-Welcome

次に、作業が必要なブランチを確認します。

git checkout -patch-1

お気に入りのテキストエディタで「+ ReadMe.md 」を開き、「 dropdown 」ではなく「 drop-down +」と言うように行を変更します。

label ReadMe.md
To add a flag simply leave a comment with your desired flag. For
convenience we also have a  menu to add these comments
automatically.

エディターでファイルを保存してから、変更を追加してコミットします。

git add ReadMe.md
git commit -m "Address code review feedback"

次に、ブランチへの変更をGithubにプッシュします。

git push origin -patch-1

次に、ブラウザでReviewNinjaインターフェイスを更新します。 コードが更新されていることがわかります。もう一度行をクリックすると、次の図に示すように、既存のコメントに「!fixed +」または「!resolved +」で返信できます。

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/WQlqJRc.png [問題を解決済みとしてマーク]

最後に、プルリクエストに満足したので、正式なサインオフとして忍者スターを付けましょう。 [忍者スターを追加]ボタンをクリックします。

画像:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/5nM6gCY.png [忍者スター]

次に、ブラウザを更新し、プルリクエストのステータスが「成功」に更新され、*プルリクエストのマージ*ボタンが緑色になっていることを確認します。

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/80ZBcpI.png [マージ準備完了]

ギアボタンをクリックして、プルリクエストの成功条件をカスタマイズできます。

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/ZJqFERE.png [カスタマイズ]

先に進み、「プルリクエストの統合」をクリックします。 ページをリロードした後(手動で更新する必要がある場合があります)、プルリクエストのステータスが「マージ済み」に変更されていることがわかります。

画像:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/MYFNC0G.png [Merged]

念頭に置いておくべきことの1つは、ReviewNinjaプルリクエストはGitHubプルリクエストであり、その逆も同様です。 ReviewNinjaに対するコメントはGitHubプルリクエストページに自動的に反映され、その逆も同様です。 ReviewNinjaを介してマージされたプルリクエストもGitHubに反映されます。

image:https://assets.digitalocean.com/articles/reviewninja_coreos_docker/J4MkNC7.png [GitHubプルリクエストが同期されます]

この双方向の同期は、コードレビューのためにReviewNinjaに徐々に移行したいチームにとって非常に便利です。

結論

このチュートリアルでは、Docker、 + docker-machine、および` + docker-compose`を使用して、多層WebアプリケーションであるReview Ninjaをデプロイしました。 既存のアプリからDockerイメージを作成する方法と、ローカル端末で快適にインフラストラクチャ全体を定義および展開する方法を学びました。

また、ReviewNinjaのいくつかの強力な機能と、それらの機能を使用してGitHubプルリクエストプロセスにワークフローコントロールを追加する方法についても学びました。

ハッピーコードレビュー!

前の投稿:Ubuntu 16.04でLAMPを使用してWordPressをインストールする方法
次の投稿:CentOS 7にPostgreSQLをインストールして使用する方法