TOC

Revue de l’auto-accueil de DigitalOcean à l’aide de Docker et de CoreOS

introduction

La révision du code est devenue un élément indissociable du processus de développement logiciel moderne. Avec l'avènement des systèmes de contrôle de version distribués, et particulièrement depuis la naissance de GitHub, le modèle d'extraction, de requête, d'examen et de fusion a été popularisé auprès de la communauté du développement de logiciels. Cependant, le système intégré d’examen des demandes de tir de GitHub laisse beaucoup à désirer. En conséquence, de nombreux outils de révision de code tiers s’intégrant à GitHub existent pour améliorer le processus. ReviewNinja est l'un de ces outils.

ReviewNinja ajoute quelques fonctionnalités en plus de l'expérience de révision des demandes de tirage GitHub à la vanille. Cela nous donne la possibilité de signer explicitement une pull request en donnant des «étoiles ninja», de sorte que vous n'avez plus besoin de commentaires comme:shipit:,LGTM ou d'autres conventions populaires. Et vous pouvez définir des stratégies pour bloquer la fusion si la demande d'extraction n'est pas approuvée par au moins 2 membres de l'équipe ou si quelqu'un ajoute des commentaires tels que!fix sur la demande d'extraction.

ReviewNinja est développé et ouvert par SAP. Il a unhosted version, mais nous pouvons le déployer sur nos propres serveurs et l'utiliser pour nos référentiels GitHub privés.

Dans ce guide, vous déploierez une instance ReviewNinja sur DigitalOcean à l'aide deDocker etCoreOS. Une instance de production ReviewNinja a quelques pièces mobiles, nous allons donc utiliserdocker-machine pour créer et contrôler un hôte Docker distant, etdocker-compose pour décrire, construire et déployer notre pile. Nous allons utiliser CoreOS pour l’hôte Docker, qui est une distribution Linux minimale adaptée aux déploiements dans le cloud. Une nouvelle installation de CoreOS n'a quesystemd et le démon Docker en cours d'exécution, nous avons donc plus de ressources disponibles pour nos applications.

Conditions préalables

Pour compléter ce tutoriel, vous aurez besoin de:

  • Docker,docker-machine etdocker-compose installés sur votre ordinateur local, afin que vous puissiez créer l'image d'application que nous allons déployer. Vous pouvez suivrethe official installation documentation pour Docker pour configurer ces outils. Lesdocker-machine etdocker-compose sont installés automatiquement avec l'application Docker sur OSX et Windows, ou vous pouvez les installer manuellement en utilisant ces liens:

  • Git est installé sur votre ordinateur local afin que vous puissiez cloner le référentiel ReviewNinja pour créer le conteneur. Suivez lesofficial Git installation documentation si vous devez remplir cette condition préalable.

  • Un jeton d'accès DigitalOcean avec accès en lecture et en écriture, que vous pouvez générer en visitant la pageApplications & API. Copiez ce jeton, car vous devrez l'utiliser avecdocker-machine pour créer des hôtes.

  • Un Droplet CoreOS de 1 Go, que nous allons configurer à l'aide dedocker-machine dans ce didacticiel.

  • Un compteGitHub.

[[step-1 -—- creation-and-activating-a-coreos-based-docker-host]] == Étape 1 - Création et activation d'un hôte Docker basé sur CoreOS

Configurons l’infrastructure pour notre déploiement. L'outildocker-machine vous permet de provisionner des machines distantes en tant qu'hôtes Docker et de les contrôler à partir de votre machine locale. Il fournit des pilotes pour de nombreux fournisseurs de cloud populaires, y compris DigitalOcean. Nous utiliseronsdocker-machine pour créer un Droplet CoreOS pour notre hôte Docker.

Basculez vers votre terminal et lancez la commande suivante à l'aide de votre jeton d'accès 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

Nous disons àdocker-machine de créer une goutte appeléereviewninja dans le centre de donnéesNYC3 en utilisant l'imagecoreos-stable avec1GB de mémoire. Notez que nous spécifions--ssh-user=core car l'utilisateur par défaut sur une installation CoreOS estcore.

Lorsque vous exécutez cette commande, vous verrez la sortie suivante: 

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

Voyons si ce nouveau Droplet est reconnu pardocker-machine. Exécutez la commande: 

docker-machine ls

Vous verrez la sortie suivante, indiquant que l'hôte Dockerreviewminja s'exécute sur une adresse IP distante à l'aide du pilotedigitalocean: 

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

Lorsque nous avons créé l'hôte Docker, la dernière ligne de la sortie nous indiquait quoi faire. Ça disait: 

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

Alors exécutons cette commande: 

docker-machine env reviewninja

Vous verrez ce message: 

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)

Alors que se passe-t-il ici? L'architecture Docker utilise un modèle client-serveur. Un client Docker peut communiquer via un socket Unix ou via TCP. Normalement, notre client Docker communique avec le moteur Docker installé localement via un socket Unix. Cependant, vous pouvez définir certaines variables d'environnement pour indiquer au client Docker de communiquer avec un hôte Docker via TCP. La sortie que vous voyez est une série de commandes shell permettant de configurer des variables d’environnement qui ne font que cela.

La dernière partie dit: 

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

Lorsque vous exécutez cette commande, vous dites au shell d'exécuter ces commandes qui définissent les variables d'environnement qui seront utilisées pour les commandesdocker suivantes.

Alors allez-y et exécutez cette commande dans votre shell: 

eval $(docker-machine env reviewninja)

Maintenant, si vous exécutezdocker info, vous verrez des informations sur le démon Docker distant, pas sur votre démon Docker local: 

docker info

Le résultat de cette commande ressemblera à ceci: 

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

[.Remarque]##

Note: vous pouvez obtenir l'erreur suivante lors de l'exécution des commandesdocker: 

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

Cela signifie que la version du client Docker que vous utilisez n'est pas compatible avec la version du serveur. Pour résoudre ce problème, définissez la variable d'environnementDOCKER_API_VERSION sur la même version que le serveur. Par exemple, si le serveur souhaite la version 1.22, exécutez la commande suivante: 

export DOCKER_API_VERSION=1.22

Essayez ensuite d'exécuter à nouveau les commandes Docker.

Notre hôte Docker distant est maintenant configuré et accessible via Docker. Avant de pouvoir créer un conteneur ReviewNinja, nous devons travailler avec GitHub.

[[step-2 -—- register-a-github-oauth-application]] == Étape 2 - Enregistrer une application GitHub OAuth

ReviewNinja doit utiliser l’API de GitHub pour accéder à vos référentiels. Nous allons donc enregistrer notre installation ReviewNinja en tant qu’application GitHub OAuth.

Nous devons d’abord connaître l’adresse IP de notre serveur. Nous pouvons utiliser la commandedocker-machine pour faire cela: 

docker-machine ip reviewninja

Enregistrez l'adresse IP que cette commande affiche. Connectez-vous ensuite à votre compte GitHub, accédez àSettings → OAuth applications → Developer applications et appuyez sur le boutonRegister a new application.

New GitHub OAuth application form

Une fois que vous avez reçu le formulaire pour la nouvelle application, entrez les informations suivantes:

  1. RéglezName surreview-ninja.

  2. RéglezHomepage URL surhttp://your_ip_address.

  3. RéglezAuthorization Callback URL surhttp://your_ip_address/auth/GitHub/callback.

Appuyez ensuite sur le boutonRegister application pour enregistrer les modifications et créer l'application. Ceci affiche la nouvelle application créée à l'écran.

Sauvegardez les valeurs pourClient ID etClient Secret dans un endroit sûr; vous les ajouterez sous peu à la configuration de l'application ReviewNinja.

GitHub app client id and secret

Maintenant que vous avez vos clés, commençons à construire notre instance ReviewNinja.

[[step-3 -—- creation-the-reviewninja-docker-container]] == Étape 3 - Création du conteneur ReviewNinja Docker

ReviewNinja est une application Node.js qui repose sur une couche de stockage protégée par MongoDB. Et puisque nous mettons cela dans un environnement de production, nous allons placer l’application Node.js derrière un serveur proxy afin que le serveur d’applications ne soit pas directement exposé à Internet. Nous utiliserons Nginx à cette fin. C'est beaucoup à configurer, nous allons donc utiliserdocker-compose pour déployer plusieurs conteneurs associés de manière déclarative. Nous définissons la configuration souhaitée, puis utilisons l'outildocker-compose pour créer des conteneurs avec tous les environnements d'exécution spécifiés.

Premièrement, nous devons obtenir le code source ReviewNinja. Clonez le code source sur votre machine locale en utilisant Git: 

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

Puis naviguez dans le dossier du projet: 

cd review.ninja

Ce référentiel contient unDockerfile, qui indique à Docker comment créer l'image de l'application ReviewNinja. Si vous ouvrez ce fichier dans votre éditeur de texte préféré, le contenu suivant s'affichera:

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"]

Ce fichier spécifie la version de Node.js que cette application utilisera. Ensuite, il copie tous les fichiers du dossier actuel dans un dossierapp et installe toutes les dépendances d'application. Il expose ensuite le port5000 et lance l'application. Pour une introduction plus détaillée aux Dockerfiles, consultezthis tutorial.

Le Dockerfile décrit le conteneur d'application ReviewNinja, mais nous pouvons décrire les composants de notre pile, y compris MongoDB et le proxy Nginx, en utilisant un fichier appelédocker-compose.yml, qui est un fichierYAML, un format populaire pour fichiers de configuration.

Le référentiel que vous avez cloné a un fichier appelédocker-compose-example.yml, mais nous allons écrire notre propre fichier à partir de zéro, car celui-ci ne répond pas à nos besoins.

Commençons par définir le stockage pour notre pile. Créez le fichierdocker-compose.yml et entrez la configuration suivante:

docker-compose.yml

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

Le servicedb utilise lesMongoDB image officiels sur Docker Hub, un référentiel central d'images Docker. De par leur conception, les conteneurs Docker perdent leur état d'exécution lorsqu'ils sont arrêtés et supprimés. C'est parfait pour le serviceweb, car il est sans état. Pour notre servicedb, nous devons conserver les données sur un disque afin de ne pas perdre toutes les données de révision de code si nous arrêtons ou redémarrons le service. C'est là qu'intervientvolumes. Au moment de l'exécution, le démon Docker peut exécuter un conteneur qui mappe les volumes du conteneur aux répertoires de l'hôte.

Dans notre configuration, nous avons spécifié ce qui suit:

docker-compose.yml

        volumes:
            - /data:/data/db

Cela mappe le dossier/data de la machine hôte à/data/db dans le conteneur, qui se trouve être le dossier dans lequel MongoDB est configuré pour écrire à l'intérieur du conteneur. En créant ce mappage, les modifications apportées par l'application sont conservées sur la machine hôte dans le dossier/data plutôt que dans le conteneur.

Nous définissons ensuite le conteneur d’application ReviewNinja. Ajoutez ceci dans le fichierdocker-compose.yml, après la configuration existante:

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: assurez-vous queweb s'aligne verticalement avec la définition de servicedb que vous avez précédemment définie en tant que fichiers YAML sont difficiles à indenter.
#

Nous utilisonsbuild . qui indique àdocker-compose que l'image doit être construite à partir desDockerfile que nous venons d'explorer dans le dossier courant. Nous déclarons ensuite un lien vers l'image dedb, donc à l'intérieur du conteneurweb, le nomdb se résoudra à l'adresse IP du conteneurdb. Cela fournit un mécanisme de découverte de service rudimentaire; nous n'avons pas besoin de connaître l'adresse IP du conteneurdb à l'avance et de le coder en dur ou de le transmettre via une variable d'environnement. Ensuite, nous utilisons ce lien pour définir la variable d'environnementMONGODB, en utilisantmongodb://db/reviewninja comme valeur.

RemplissezGITHUB_CLIENT etGITHUB_SECRET avec l'ID client et le secret de l'application GitHub que vous avez créée. L'application ReviewNinja lira ces variables d'environnement lors de l'exécution.

Enfin, définissons le service d'équilibrage de charge qui transférera les requêtes du port80 vers le port utilisé par notre application Node.js. Ajoutez cette configuration au fichier, en l'alignant verticalement avec la déclaration de serviceweb que vous venez de créer:

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

Nous utilisons lesofficial Nginx image de Docker Hub et déclarons un mappage de port de80:80, qui lie le port80 sur l'hôte au port80 dans le conteneur. Nous créons ensuite un mappage de volume qui stocke le fichier de configuration Nginx en dehors du conteneur, et nous déclarons un lien de conteneur vers le conteneurapp afin que nous puissions le localiser par nom et les requêtes proxy.

La déclaration decommand est assez longue, alors décomposons-la. En fait, il exécute deux commandes sur une seule ligne. La première commande estecho -e ... > /etc/nginx/conf.d/default.conf, qui crée le fichier de configuration Nginx pour ReviewNinja, qui ressemble à ceci:

default.conf

upstream backend {
    server web:5000;
}

server {
    listen       80;

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

Ceci définit unbackend en amont et le pointe versweb:5000. La valeurweb provient du fichierdocker-compose.yml dans la sectionlinks, et le port5000 est le port utilisé par le serveur Node.js dans le conteneurweb. Ensuite, nous déclarons que notre serveur Nginx fonctionnera sur le port80 dans le conteneur et devrait transmettre toutes les requêtes àbackend, notre serveur d'applications.

La deuxième partie de la commande,nginx -g 'daemon off', est la commande qui exécute le processus serveur Nginx dans le conteneur. Nous devons spécifierdaemon off car Nginx s'exécute en mode démon par défaut, se détachant du processus en cours. Docker considère tout programme détaché du point d'entrée du conteneur comme étant «abandonné» et termine le conteneur, en récoltant tous les processus. En règle générale, tout processus exécuté dans le conteneur Docker doit être exécuté au premier plan.

Voici l'intégralité du fichierdocker-compose.yml, juste au cas où vous voudriez revérifier votre configuration avant de continuer:

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

Jetez un œil auxdocker-compose documentation si vous voulez en savoir plus sur la syntaxe et les options pourdocker-compose.yml.

Cela prend en charge notre configuration pour cette application. Enregistrez le fichierdocker-compose.yml; il est temps de déployer cette application.

[[step-4 -—- build-and-deploy-the-containers]] == Étape 4 - Construire et déployer les conteneurs

Nous avons configurédocker-compose pour déployer notre application ReviewNinja, une instance MongoDB pour contenir les données et un proxy Nginx. Avant de déployer ces conteneurs, vérifions que la machine Docker dereviewninja est toujours active: 

docker-machine active

Tu devrais voir: 

Outputreviewninja

Si vous ne voyez pas cette sortie, assurez-vous de lancer 

eval $(docker-machine env reviewninja)

à nouveau pour vous assurer que les paramètres de votre environnement sont corrects. Puis réessaye.

Une fois que vous êtes sûr d'avoir une machine active, utilisezdocker-compose pour construire votre pile: 

docker-compose build

Ce processus peut prendre beaucoup de temps car il télécharge et configure toutes les dépendances de l'application ReviewNinja sur l'hôte Docker. Vous verrez le résultat suivant: 

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

Une fois le processus de construction terminé, vérifiez que vous avez une image réussie: 

docker images

Vous verrez la sortie suivante qui indique que l'imagereviewninja_web a été créée avec succès: 

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

Nous pouvons maintenant lancer notre base de données, notre application ReviewNinja et notre proxy Nginx sur notre serveur distant avec une seule commande: 

docker-compose up -d

Cela fait apparaître tous les conteneurs que nous avons définis dans le fichierdocker-compose. Nous utilisons-d (pour «détacher») afin que tous les conteneurs fonctionnent en arrière-plan et nous avons notre terminal à nouveau sous notre contrôle. 

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

Vérifions que les conteneurs sont opérationnels. Exécutez la commande suivante: 

docker ps

Vous verrez une sortie qui ressemble à ceci: 

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

Nous voulons également nous assurer que les services fonctionnent correctement. Pour ce faire, nous utilisons la commandedocker logs pour voir la sortie d'un conteneur. Vérifions les journaux de l’application Web ReviewNinja. Nous pouvons référencer le conteneur soit par son ID, répertorié dans la colonneCONTAINER ID dans la sortie précédente, soit par son nom. Dans notre cas, le nom estreviewninja_web_1, alors regardons les journaux de ce conteneur: 

docker logs reviewninja_web_1

L’application ReviewNinja vous indiquera qu’elle écoute les connexions: 

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

La sortie indique que ReviewNinja écoute sur le port5000.

Pour y accéder depuis le Web, nous devons utiliser l’adresse IP de notre hôte Docker, notre serveur CoreOS. Si vous avez oublié l'adresse IP de votre serveur, utilisezdocker-machine pour le savoir. 

docker-machine ip reviewninja

Pointez votre navigateur surhttp://your_server_ip et vous serez accueilli par le ninja:

ReviewNinja home page

Enfin, nous sommes prêts à utiliser l’application avec notre propre code.

[[step-5 -—- using-reviewninja-with-a-repository]] == Étape 5 - Utilisation de ReviewNinja avec un référentiel

Essayons notre nouvelle instance de ReviewNinja sur un référentiel de test. Nous allons fournir des commentaires sur une demande d'extraction, résoudre le problème, accepter les modifications et fusionner la demande d'extraction.

Nous devons d'abord permettre à l'application Review Ninja d'accéder à votre compte GitHub. Cliquez surSign In, et vous serez redirigé vers GitHub pour vous connecter. On vous demandera si vous autoriserez ReviewNinja à accéder à votre compte GitHub:

Grant app permissions through GitHub

Une fois que vous avez autorisé l'application, vous serez dirigé vers l'interface principale de ReviewNinja. Si vous avez des référentiels privés que vous souhaitez que ReviewNinja utilise, vous pouvez cliquer sur le lienEnable private repos:

Enabling access to private repositories

Vous serez ensuite redirigé vers GitHub pour réviser votre autorisation de l'application ReviewNinja afin d'inclure l'accès à votre dépôt privé:

Authorizing private repositories

Une fois que vous avez accordé à ReviewNinja l'accès que vous souhaitez, vous pouvez ajouter un référentiel afin que vous puissiez utiliser ReviewNinja pour votre flux de travail de demande d'extraction. Lors de votre première utilisation de ReviewNinja, vous avez la possibilité d’ajouter un exemple de référentielReviewNinja-Welcome:

Adding a sample repository

Créez cet exemple de référentiel afin que nous puissions parcourir quelques fonctionnalités de base de ReviewNinja. Cela crée le référentiel sur Github sous votre compte et l'ajoute à ReviewNinja.

L’exemple de référentiel contient un fichierReadMe.md qui est censé décrire certaines des fonctionnalités du flux de révision de code de ReviewNinja. Le référentielReviewNinja-Welcome a déjà une pull request ouverte à partir d'une brancheyour_github_username-patch-1 qui a la copie mise à jour du fichierReadMe.md. Le nom de la succursale variera en fonction de votre nom d'utilisateur.

Pull Requests View

Cliquez sur cette branche et vous verrez l'interface principale de révision du code où vous pourrez parcourir les diffs et ajouter des commentaires. Vous verrez également la zone d'état de la demande d'extraction, qui décrit l'état de la demande d'extraction et des problèmes en suspens.

Pull Request status box

Le boutonMerge pull request est actuellement orange car l'état de la demande d'extraction est «en attente». Le statut changera en fonction des conditions que vous pouvez modifier en cliquant sur le bouton d'engrenage. Par défaut, il faut au moins 1 étoile ninja pour que le bouton devienne vert.

Nous verrons cela plus tard, mais pour le moment, ajoutons un commentaire. Cliquez sur la ligne de code qui dit 

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

Add a line comment

Soyons un peu pédants ici et suggérons que le motdropdown soit changé endrop-down. Ajoutez un commentaire à l'aide de la zone de commentaire sur le côté droit de l'écran et marquez-le comme un problème de blocage en ajoutant!fix à votre commentaire, comme illustré dans la figure suivante:

Flag a line

Un commentaire signalé sera considéré comme un «problème» sur la demande d'extraction que l'auteur de la demande d'extraction doit traiter avant que ReviewNinja ne permette sa fusion.

Actualisez la page et vous verrez maintenant le nouveau problème répertorié au-dessus du boutonMerge pull request:

Our problem

Laissons régler ce problème. Sur votre ordinateur local, utilisez Git pour cloner le référentiel: 

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

Ensuite, vérifiez la branche qui a besoin de travail: 

git checkout your_github_username-patch-1

OuvrezReadMe.md dans votre éditeur de texte préféré et changez la ligne pour diredrop-down au lieu dedropdown: 

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.

Enregistrez le fichier dans votre éditeur, puis ajoutez et validez vos modifications: 

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

Ensuite, envoyez les modifications dans la branche vers Github: 

git push origin your_github_username-patch-1

Maintenant, actualisez l'interface ReviewNinja dans votre navigateur. Vous verrez que le code est mis à jour et si vous cliquez à nouveau sur la ligne, vous pouvez répondre au commentaire existant avec!fixed ou!resolved, comme indiqué dans la figure suivante:

Mark a problem as resolved

Enfin, maintenant que nous sommes satisfaits de la demande de tirage, donnons-lui une étoile ninja en guise d’approbation officielle. Cliquez sur le boutonAdd ninja star:

ninja star

Ensuite, actualisez le navigateur et observez que l'état de la demande d'extraction est mis à jour sur «réussi» et que le boutonMerge pull request est vert:

Ready for merge

Vous pouvez personnaliser la condition de succès d'une demande de tirage en cliquant sur le bouton d'engrenage:

Customize

Allez-y et cliquez sur "Demande de fusion". Une fois la page rechargée (vous devrez peut-être l'actualiser manuellement), vous verrez que l'état de la demande d'extraction est remplacé par «Fusionné».

Merged

Une chose à garder à l'esprit: les demandes d'extraction ReviewNinjaare demandes d'extraction GitHub et vice versa. Les commentaires formulés sur ReviewNinja seront automatiquement répercutés sur la page de demande d'extraction GitHub et inversement. Les demandes d'extraction fusionnées via ReviewNinja seront également répercutées sur GitHub:

GitHub pull requests are synced

Cette synchronisation bidirectionnelle sera très utile pour les équipes qui souhaitent migrer progressivement vers ReviewNinja pour la révision du code.

Conclusion

Dans ce didacticiel, vous avez utilisé Docker,docker-machine etdocker-compose pour déployer ReviewNinja, une application Web à plusieurs niveaux. Vous avez appris à créer une image Docker à partir d'une application existante et à définir et déployer l'intégralité de votre infrastructure dans le confort de votre terminal local.

Vous avez également découvert certaines fonctionnalités puissantes de ReviewNinja et comment utiliser ces fonctionnalités pour ajouter un contrôle de flux de travail au processus de demande d'extraction GitHub.

Bonne révision de code!

Related