Merge pull request travis-ci#2447 from travis-ci/ph-language-review-lifecycle

Language review of job-lifecycle.md

Author: Pezi777

user/job-lifecycle.md

@@ -9,7 +9,7 @@ Travis CI provides a default build environment and a default set of phases for e
 
 Keep reading to see how you can customize any phase in this process, via your `.travis.yml`.
 
-## The job lifecycle
+## The Job Lifecycle
 
 A job on Travis CI is made up of two main parts:
 
@@ -36,7 +36,7 @@ The complete job lifecycle, including three optional deployment phases and after
 1. OPTIONAL `after_deploy`
 1. `after_script`
 
-A *build* can be composed of many jobs.
+> A *build* can be composed of many jobs.
 
 ## Customizing the Installation Phase
 
@@ -50,7 +50,7 @@ install: ./install-dependencies.sh
 ```
 {: data-file=".travis.yml"}
 
-> When using custom scripts they should be executable (for example, using `chmod +x`) and contain a valid shebang line such as `/usr/bin/env sh`, `/usr/bin/env ruby`, or `/usr/bin/env python`.
+> When using custom scripts, they should be executable (for example, using `chmod +x`) and contain a valid shebang line such as `/usr/bin/env sh`, `/usr/bin/env ruby`, or `/usr/bin/env python`.
 
 You can also provide multiple steps, for instance to install both ruby and node dependencies:
 
@@ -94,7 +94,7 @@ script:
 ```
 {: data-file=".travis.yml"}
 
-When one of the build commands returns a non-zero exit code, the Travis CI build runs the subsequent commands as well, and accumulates the build result.
+When one of the build commands returns a non-zero exit code, the Travis CI build runs the subsequent commands as well and accumulates the build result.
 
 In the example above, if `bundle exec rake build` returns an exit code of 1, the following command `bundle exec rake builddoc` is still run, but the build will result in a failure.
 
@@ -134,7 +134,7 @@ if [ "${TRAVIS_PULL_REQUEST}" = "false" ]; then
 fi
 ```
 
-Note the `set -ev` at the top. The `-e` flag causes the script to exit as soon as one command returns a non-zero exit code. This can be handy if you want whatever script you have to exit early. It also helps in complex installation scripts where one failed command wouldn't otherwise cause the installation to fail.
+> Note the `set -ev` at the top. The `-e` flag causes the script to exit as soon as one command returns a non-zero exit code. This can be handy if you want whatever script you have to exit early. It also helps in complex installation scripts where one failed command wouldn't otherwise cause the installation to fail.
 
 The `-v` flag makes the shell print all lines in the script before executing them, which helps identify which steps failed.
 
@@ -157,7 +157,7 @@ When overriding these steps, do not use `exit` shell built-in command.
 Doing so will run the risk of terminating the build process without giving Travis a chance to
 perform subsequent tasks.
 
-Using `exit` inside a custom script which will be invoked from during a build is fine.
+> Using `exit` inside a custom script which will be invoked from during a build is fine.
 
 
 ## Breaking the Build
@@ -175,7 +175,7 @@ However, if one of these stages times out, the build is marked as **failed**.
 
 An optional phase in the job lifecycle is deployment.
 This phase is defined by using one of our continuous deployment providers to deploy code to Heroku, Amazon, or a different supported platform.
-The deploy steps are skipped if the build is broken.
+The deploy steps are skipped, if the build is broken.
 
 When deploying files to a provider, prevent Travis CI from resetting your
 working directory and deleting all changes made during the build ( `git stash
@@ -189,6 +189,8 @@ deploy:
 
 You can run commands before a deploy by using the `before_deploy` phase. A non-zero exit code in this phase will mark the build as **errored**.
 
-If there are any steps you'd like to run after the deployment, you can use the `after_deploy` phase. Note that `after_deploy` does not affect the status of the build.
+If there are any steps you'd like to run after the deployment, you can use the `after_deploy` phase. 
 
-Note that `before_deploy` and `after_deploy` are run before and after every deploy provider, so will run multiple times if there are multiple providers.
+> Note that `after_deploy` does not affect the status of the build.
+
+> Note that `before_deploy` and `after_deploy` are run before and after every deploy provider, so they will run multiple times, if there are multiple providers.