1 files changed, 18 insertions, 18 deletions
diff --git a/doc/ci/examples/deployment/composer-npm-deploy.md b/doc/ci/examples/deployment/composer-npm-deploy.md
index 24990264f19..6bc96ae6c30 100644
--- a/doc/ci/examples/deployment/composer-npm-deploy.md
+++ b/doc/ci/examples/deployment/composer-npm-deploy.md
@@ -9,13 +9,13 @@ type: tutorial
 
 This guide covers the building of dependencies of a PHP project while compiling assets via an NPM script using [GitLab CI/CD](../../README.md).
 
-While it is possible to create your own image with custom PHP and Node.js versions, for brevity, we will use an existing [Docker image](https://hub.docker.com/r/tetraweb/php/) that contains both PHP and Node.js installed.
+While it is possible to create your own image with custom PHP and Node.js versions, for brevity we use an existing [Docker image](https://hub.docker.com/r/tetraweb/php/) that contains both PHP and Node.js installed.
 
 ```yaml
 image: tetraweb/php
 ```
 
-The next step is to install zip/unzip packages and make composer available. We will place these in the `before_script` section:
+The next step is to install zip/unzip packages and make composer available. We place these in the `before_script` section:
 
 ```yaml
 before_script:
@@ -26,7 +26,7 @@ before_script:
   - php -r "unlink('composer-setup.php');"
 ```
 
-This will make sure we have all requirements ready. Next, we want to run `composer install` to fetch all PHP dependencies and `npm install` to load Node.js packages, then run the `npm` script. We need to append them into `before_script` section:
+This makes sure we have all requirements ready. Next, run `composer install` to fetch all PHP dependencies and `npm install` to load Node.js packages. Then run the `npm` script. We need to append them into `before_script` section:
 
 ```yaml
 before_script:
@@ -43,19 +43,19 @@ In this particular case, the `npm deploy` script is a Gulp script that does the
 1. Copy various assets (images, fonts) around
 1. Replace some strings
 
-All these operations will put all files into a `build` folder, which is ready to be deployed to a live server.
+All these operations put all files into a `build` folder, which is ready to be deployed to a live server.
 
 ## How to transfer files to a live server
 
-You have multiple options: rsync, SCP, SFTP, and so on. For now, we will use SCP.
+You have multiple options: rsync, SCP, SFTP, and so on. For now, use SCP.
 
-To make this work, you need to add a GitLab CI/CD Variable (accessible on `gitlab.example/your-project-name/variables`). That variable will be called `STAGING_PRIVATE_KEY` and it's the  **private** SSH key of your server.
+To make this work, you must add a GitLab CI/CD Variable (accessible on `gitlab.example/your-project-name/variables`). Name this variable `STAGING_PRIVATE_KEY` and set it to the **private** SSH key of your server.
 
 ### Security tip
 
 Create a user that has access **only** to the folder that needs to be updated.
 
-After you create that variable, you need to make sure that key will be added to the Docker container on run:
+After you create that variable, make sure that key is added to the Docker container on run:
 
 ```yaml
 before_script:
@@ -71,7 +71,7 @@ In order, this means that:
 1. We check if the `ssh-agent` is available and we install it if it's not.
 1. We create the `~/.ssh` folder.
 1. We make sure we're running bash.
-1. We disable host checking (we don't ask for user accept when we first connect to a server and since every job will equal a first connect, we kind of need this).
+1. We disable host checking (we don't ask for user accept when we first connect to a server, and since every job equals a first connect, we need this).
 
 And this is basically all you need in the `before_script` section.
 
@@ -96,14 +96,14 @@ stage_deploy:
 
 Here's the breakdown:
 
-1. `only:dev` means that this build will run only when something is pushed to the `dev` branch. You can remove this block completely and have everything be ran on every push (but probably this is something you don't want)
-1. `ssh-add ...` we will add that private key you added on the web UI to the Docker container
-1. We will connect via `ssh` and create a new `_tmp` folder
-1. We will connect via `scp` and upload the `build` folder (which was generated by a `npm` script) to our previously created `_tmp` folder
-1. We will connect again via `ssh` and move the `live` folder to an `_old` folder, then move `_tmp` to `live`.
-1. We connect to SSH and remove the `_old` folder
+1. `only:dev` means that this build runs only when something is pushed to the `dev` branch. You can remove this block completely and have everything run on every push (but probably this is something you don't want).
+1. `ssh-add ...` we add that private key you added on the web UI to the Docker container.
+1. We connect via `ssh` and create a new `_tmp` folder.
+1. We connect via `scp` and upload the `build` folder (which was generated by a `npm` script) to our previously created `_tmp` folder.
+1. We connect again via `ssh` and move the `live` folder to an `_old` folder, then move `_tmp` to `live`.
+1. We connect to SSH and remove the `_old` folder.
 
-What's the deal with the artifacts? We just tell GitLab CI/CD to keep the `build` directory (later on, you can download that as needed).
+What's the deal with the artifacts? We tell GitLab CI/CD to keep the `build` directory (later on, you can download that as needed).
 
 ### Why we do it this way
 
@@ -114,7 +114,7 @@ If you're using this only for stage server, you could do this in two steps:
 - scp -P22 -r build/* server_user@server_host:htdocs/wp-content/themes/live
 ```
 
-The problem is that there will be a small period of time when you won't have the app on your server.
+The problem is that there's a small period of time when you don't have the app on your server.
 
 Therefore, for a production environment we use additional steps to ensure that at any given time, a functional app is in place.
 
@@ -122,13 +122,13 @@ Therefore, for a production environment we use additional steps to ensure that a
 
 Since this was a WordPress project, I gave real life code snippets. Some further ideas you can pursue:
 
-- Having a slightly different script for `master` branch will allow you to deploy to a production server from that branch and to a stage server from any other branches.
+- Having a slightly different script for `master` branch allows you to deploy to a production server from that branch and to a stage server from any other branches.
 - Instead of pushing it live, you can push it to WordPress official repository (with creating a SVN commit, etc.).
 - You could generate i18n text domains on the fly.
 
 ---
 
-Our final `.gitlab-ci.yml` will look like this:
+Our final `.gitlab-ci.yml` looks like this:
 
 ```yaml
 image: tetraweb/php