livraison : grammaire et syntaxe

documentation/05.livraison-continue.md

@@ -100,7 +100,7 @@ L'intérêt des variables d'environnement est de créer des fichiers de déploie
 >
 > - La syntaxe est la même que pour les variables shell : `${<VAR_NAME>:-<DEFAULT_VALUE>}`
 > - Si un fichier `.env` existe dans le répertoire courant, il est chargé automatiquement par Docker
-> - Les variables d'environnement peuvent également être appelée dans les fichiers Dockerfile avec la syntaxe `$VAR_NAME` et passé via les options `-e VAR_NAME=VAR_VALUE` ou `--env-file /path/to/env-file` de la commande de construction d'image ou via le fichier Docker Compose.
+> - Les variables d'environnement peuvent également être accédées dans les fichiers Dockerfile avec la syntaxe `$VAR_NAME` et passé via les options `-e VAR_NAME=VAR_VALUE` ou `--env-file /path/to/env-file` de la commande de construction d'image ou via le fichier Docker Compose.
 
 ### Docker Secrets and Docker Config
 
@@ -161,7 +161,7 @@ secrets:
 
 ### Exemples
 
-Voici deux exemples qui illustrent l'utilisation des ces mécanismes pour le déploiement de piles applicatives.
+Voici deux exemples qui illustrent l'utilisation de ces mécanismes pour le déploiement de piles applicatives.
 
 #### Déploiement d'une pile Wordpress
 
@@ -676,7 +676,7 @@ services:
 
 ##### Playbook Ansible pour un déploiement local
 
-Le playbook de déploiement via Ansible est assez simple dans le cas de cettes application. Il est responsable des actions suivantes :
+Le playbook de déploiement via Ansible est assez simple dans le cas de cette application. Il est responsable des actions suivantes :
 
 - récupérer le code de l’application depuis son dépôt gitlab
 - lancement de la stack avec les fichiers de configuration `docker-compose` disponibles
@@ -914,18 +914,18 @@ Le mécanisme contient deux parties :
 - Un service gitlab-runner doit être déployé sur la machine qui exécutera les tâches de déploiement
 - Ce service doit être configuré dans les runners disponibles sur Gitlab. Un runner peut être soit `shared` pour l'ensemble des projets héberger sur l'instance Gitlab, soit dédié à un groupe de projets ou à un projet spécifique.
 
-L'enregistrement d'un runner se fait via l'interface de Gitlab, chaque runner se voit associé un token qui l'identifie et un autre qui permet au service gitlab-runner de s'enregistré auprès de gitlab.
+L'enregistrement d'un runner se fait via l'interface de Gitlab, chaque runner se voit associé un token qui l'identifie et un autre qui permet au service gitlab-runner de s'enregistrer auprès de gitlab.
 
-Les opérations à exécuter sont définie dans une pipeline. Les différents tâches (jobs) seront exécutées par le runner. Les jobs d'une pipeline peuvent traités  en parrallèles et exécutés par des runners différents (par exemple un runner chargé de construire l'application, un autre chargé de son déploiement). Les pipelines sont définis dans un fichier YAML nommé `.gitlab-ci.yml`.
+Les opérations à exécuter sont définies dans une pipeline. Les différentes tâches (jobs) seront exécutées par le runner. Les jobs d'une pipeline peuvent être traités  en parallèles et exécutés par des runners différents (par exemple un runner chargé de construire l'application, un autre chargé de son déploiement). Les pipelines sont définis dans un fichier YAML nommé `.gitlab-ci.yml`.
 
-L'exécution d'une pipeline peut être déclencher par différents événements :
+L'exécution d'une pipeline peut être déclenchée par différents événements :
 
 - Opération push sur un dépôt qui peut-être systématique ou avec des conditions (filtrage par branche, push sur un tag...)
 - A la main via un click dans l'interface de gitlab
 - De manière planifiée via un scheduler intégré à gitlab
 - Via l'API de gitlab
 
-La mise en place du mécanisme est relativement simple et est détaillée dans [la documentation de Gitlab](https://docs.gitlab.com/ee/ci/). Toutefois, le nombre d'options disponibles pour les pipelines est assez gigantesques et la consultation d'exemples peut s'avérer rapidement nécessaire.
+La mise en place du mécanisme est relativement simple et est détaillée dans [la documentation de Gitlab](https://docs.gitlab.com/ee/ci/). Toutefois, le nombre d'options disponibles pour les pipelines est assez élévé et la consultation d'exemples peut s'avérer rapidement nécessaire.
 
 Dans le cadre d'une infrastructure Docker, l'idéal est de déployer les services gitlab-runner sous la forme de conteneurs Docker afin de lui donner facilement accès aux opérations sur les services déployés dans le Swarm.
 
@@ -992,7 +992,7 @@ RUNNER_TAG_LIST=deploy
 ```
 Les commandes qui seront exécutées par le runner sont définies dans un fichier `.gitlab-ci.yml` situé à la racine du projet concerné. Il suffit alors de déclarer un pipeline dans le projet Gitlab et de configurer ses conditions d'exécution, sa fréquence d'exécution et des variables additionelles. Si ce n'est pas fait, le runner devra être exécuté à la main via "Run pipeline".
 
-> **Note** : Des exemples plus complet peuvent être trouvés en ligne, par exemple sur https://gitlab.actilis.net/formation/gitlab/deploy-runner
+> **Note** : Des exemples plus complets peuvent être trouvés en ligne, par exemple sur https://gitlab.actilis.net/formation/gitlab/deploy-runner
 
 Chaque Pipeline se caractérise par des "étages" (stages) qui seront exécutés dans l'odre de leur déclaration. Par exemple :
 
@@ -1000,7 +1000,7 @@ Chaque Pipeline se caractérise par des "étages" (stages) qui seront exécutés
 stages:
 - prebuild
 - build
-- deploy
+- depls 
 - postdeploy
 ```
 
@@ -1019,7 +1019,7 @@ deploy-on-swarm
 
 Il y a également des directives prédéfinies comme `before_script` ou `after_script` qui seront exécutées respectivement avant et après chaque exécution d'une commande `script`. Chaque job peut lui-mème déclarer ses propres directives `before_script` ou `after_script`.
 
-Gitlab CI constitue donc un outil extrèmement flexible et complet pour mettre en place la livraison continue avec Docker Swarm. Les pipelines et le runner sont relativement simple à mettre en place et à configurer. 
+Gitlab CI constitue donc un outil extrêmement flexible et complet pour mettre en place la livraison continue avec Docker Swarm. Les pipelines et le runner sont relativement simples à mettre en place et à configurer. 
 
 <!-- REFS -->
 
@@ -1027,8 +1027,8 @@ Gitlab CI constitue donc un outil extrèmement flexible et complet pour mettre e
 
 [^dockerextend]: « Share Compose configurations between files and projects » https://docs.docker.com/compose/extends/
 
-[^composeextend]: "Share Compose configurations between files and projects" https://docs.docker.com/compose/extends/ 
+[^composeextend]: « Share Compose configurations between files and projects » https://docs.docker.com/compose/extends/ 
 
-[^swarmconfig]: "Store configuration data using Docker Configs" https://docs.docker.com/engine/swarm/configs/
+[^swarmconfig]: « Store configuration data using Docker Configs » https://docs.docker.com/engine/swarm/configs/
 
-[^swarmsecret]: "Manage sensitive data with Docker secrets" https://docs.docker.com/engine/swarm/secrets/
+[^swarmsecret]: « Manage sensitive data with Docker secrets » https://docs.docker.com/engine/swarm/secrets/
\ No newline at end of file