TOC

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

前書き

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

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

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

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

前提条件

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

  • Docker、docker-machine、およびdocker-composeがローカルマシンにインストールされているため、デプロイするアプリケーションイメージを構築できます。 Dockerのthe official installation documentationをたどって、これらのツールを構成できます。 docker-machineとdocker-composeはどちらも、OSXとWindowsのDockerアプリで自動的にインストールされます。または、次のリンクを使用して手動でインストールすることもできます。

  • Gitがローカルマシンにインストールされているため、ReviewNinjaリポジトリのクローンを作成してコンテナーを作成できます。 この前提条件を満たす必要がある場合は、official Git installation documentationに従ってください。

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

  • このチュートリアルではdocker-machineを使用して構成する1GBのCoreOSドロップレット。

  • GitHubアカウント。

[[step-1 -—- creating-and-activating-a-coreos-based-docker-host]] ==ステップ1—CoreOSベースのDockerホストの作成とアクティブ化

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

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

docker-machine create --driver=digitalocean \
--digitalocean-access-token=DIGITAL_OCEAN_ACCESS_TOKEN \
--digitalocean-image=coreos-stable \
--digitalocean-region=nyc3 \
--digitalocean-size=1GB \
--digitalocean-ssh-user=core \
reviewninja

1GBのメモリを備えたcoreos-stableイメージを使用して、NYC3データセンターにreviewninjaというドロップレットを作成するようにdocker-machineに指示しています。 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
reviewninja            digitalocean   Running   tcp://your_ip_address: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

[。注意]＃＃

Note：dockerコマンドの実行中に次のエラーが発生する場合があります。 

Error response from daemon: client is newer than server (client API version: 1.24, server API version: 1.22)

これは、使用しているDockerクライアントのバージョンがサーバーのバージョンと互換性がないことを意味します。 これを修正するには、環境変数DOCKER_API_VERSIONをサーバーと同じバージョンに設定します。 たとえば、サーバーでバージョン1.22が必要な場合は、次のコマンドを実行します。 

export DOCKER_API_VERSION=1.22

次に、Dockerコマンドを再度実行してみてください。

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

[[step-2 -—- register-a-github-oauth-application]] ==ステップ2— GitHubOAuthアプリケーションを登録します

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

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

docker-machine ip reviewninja

このコマンドが表示するIPアドレスを記録します。 次に、GitHubアカウントにログインし、Settings → OAuth applications → Developer applicationsに移動して、Register a new applicationボタンを押します。

New GitHub OAuth application form

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

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

  2. Homepage URLをhttp://your_ip_addressに設定します。

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

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

Client IDとClient Secretの値を安全な場所に保存します。間もなくそれらをReviewNinjaアプリケーション構成に追加します。

GitHub app client id and secret

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

[[step-3 -—- creating-the-reviewninja-docker-container]] ==ステップ3— ReviewNinjaDockerコンテナーの作成

ReviewNinjaは、MongoDBがサポートするストレージレイヤーに依存するNode.jsアプリケーションです。 そして、これを実稼働環境に配置するため、Node.jsアプリをプロキシサーバーの背後に配置して、アプリサーバーがインターネットに直接公開されないようにします。 この目的のためにNginxを使用します。 構成するのは大変なので、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を公開し、アプリを起動します。 Dockerfileの詳細については、this tutorialを参照してください。

DockerfileはReviewNinjaアプリケーションコンテナーを記述しますが、MongoDBやNginxプロキシなどのスタックのコンポーネントは、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の公式MongoDB imageを使用します。 設計上、Dockerコンテナーは停止および削除されるとランタイム状態を失います。 ステートレスなので、webサービスには問題ありません。 dbサービスの場合、サービスを停止または再起動してもすべてのコードレビューデータが失われないように、データをディスクに永続化する必要があります。 これがvolumesの出番です。 実行時に、Dockerデーモンは、コンテナ内のボリュームをホスト上のディレクトリにマップするコンテナを実行できます。

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

docker-compose.yml

        volumes:
            - /data:/data/db

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

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

docker-compose.yml

services:
    db:
    [...]

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

[.note]＃Note：webが以前にYAMLファイルとして定義したdbサービス定義と垂直に並んでいることを確認してください。
＃

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

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

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

docker-compose.yml

services:
    web:
    [...]
    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 Hubの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: YOUR_GITHUB_APP_ID
            GITHUB_SECRET: YOUR_GITHUB_APP_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の構文とオプションについて詳しく知りたい場合は、docker-compose documentationを参照してください。

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

[[step-4 -—- build-and-deploy-the-containers]] ==ステップ4—コンテナをビルドしてデプロイする

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

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
reviewninja_web     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               "nginx -g 'daemon off"   43 seconds ago      Up 41 seconds       0.0.0.0:80->80/tcp, 443/tcp   reviewninja_nginx_1
164564dd450a        reviewninja_web     "node /app/app.js"       45 seconds ago      Up 43 seconds       5000/tcp                      reviewninja_web_1
7cd9d03eb3b9        mongo               "/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://your_server_ipを指定すると、忍者が出迎えてくれます。

ReviewNinja home page

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

[[step-5 --- using-reviewninja-with-a-repository]] ==ステップ5—リポジトリでReviewNinjaを使用する

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

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

Grant app permissions through GitHub

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

Enabling access to private repositories

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

Authorizing private repositories

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

Adding a sample repository

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

サンプルリポジトリには、ReviewNinjaのコードレビューフローの機能の一部を概説することになっているReadMe.mdファイルが含まれています。 ReviewNinja-Welcomeリポジトリには、ReadMe.mdファイルの更新されたコピーがあるブランチyour_github_username-patch-1から開かれたプル要求がすでにあります。 ブランチの名前は、ユーザー名によって異なります。

Pull Requests View

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

Pull Request status box

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

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

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

Add a line comment

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

Flag a line

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

ページを更新すると、Merge pull requestボタンの上に新しい問題が表示されます。

Our problem

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

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

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

git checkout your_github_username-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 drop-down menu to add these comments
automatically.

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

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

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

git push origin your_github_username-patch-1

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

Mark a problem as resolved

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

ninja star

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

Ready for merge

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

Customize

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

Merged

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

GitHub pull requests are synced

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

結論

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

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

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

Related