Merge pull request #1036 from oracle/rmarano2

minor edits, jenkins-ignore

Author: rjeberhard

docs-source/content/userguide/cicd/_index.md

@@ -2,7 +2,7 @@
 title: "CI/CD considerations"
 date: 2019-04-11T13:01:55-04:00
 weight: 5
-description: "Learn about managing domain images with CI/CD."
+description: "Learn about managing domain images with continuous integration and continuous delivery (CI/CD)."
 draft: false
 ---
 
@@ -44,9 +44,9 @@ you need your domain, that is the configuration.
 
 There is also other information associated with a domain that needs to live
 somewhere, for example leasing tables, message and transaction stores, and so
-on.  We recommend that these be kept in a database to take advantage of built-in 
-database server HA, and the fact that disaster recovery of sites across all 
-but the shortest distances almost always requires using a single database 
+on.  We recommend that these be kept in a database to take advantage of built-in
+database server HA, and the fact that disaster recovery of sites across all
+but the shortest distances almost always requires using a single database
 server to consolidate and replicated data (DataGuard).
 
 There are two common approaches on how to structure these components.  The first,

docs-source/content/userguide/cicd/how-to-copy-domains.md

@@ -1,5 +1,5 @@
 ---
-title: "How to copy domains"
+title: "Copy domains"
 date: 2019-04-11T13:48:15-04:00
 draft: false
 weight: 5
@@ -19,7 +19,7 @@ and to create a ZIP file of this domain before starting any servers.
 > The domain ZIP must be created before starting servers.  
 
 When servers are started the first time, they will encrypt various other data.
-Make sure you create the ZIP file before starting servers for the first time.
+Make sure that you create the ZIP file before starting servers for the first time.
 The primordial domain ZIP file should be stored in a safe place where the CI/CD
 can get it when needed, for example in a secured Artifactory repository (or
 something similar).  

docs-source/content/userguide/cicd/tools.md

@@ -13,8 +13,8 @@ in a CI/CD pipeline. For example, the
 `createDomain` tool creates a new domain based on a simple model, and
 `updateDomain` (and `deployApps`) uses the same model concept to update
 an existing domain (preserving the same domain encryption key). The `deployApps`
-tool is very similar to the updateDomain tool, but limits what can be updated
-to application related configuration attributes such as data sources and
+tool is very similar to the `updateDomain` tool, but limits what can be updated
+to application-related configuration attributes such as data sources and
 application archives.  The model used by these tools is a sparse set of
 attributes needed to create or update the domain. A model can be as sparse
 as providing only the WebLogic Server administrative password, although not very
@@ -24,8 +24,8 @@ interesting.  A good way to get a jumpstart on a model is to use the
 Other than the tools themselves, there are three components to the WDT tools:  
 
 - *The Domain Model* - Metadata model describing the desired domain.  
-  The metadata domain model can be YAML or JSON and is documented [here](https://github.com/oracle/weblogic-deploy-tooling#the-metadata-model).
-- *The Archive Zip* - Binaries to supplement the model.  
+  The metadata domain model can be written in YAML or JSON and is documented [here](https://github.com/oracle/weblogic-deploy-tooling#the-metadata-model).
+- *The Archive ZIP* - Binaries to supplement the model.  
   All binaries needed to supplement the model must be specified in an archive
   file, which is just a ZIP file with a specific directory structure. Optionally,
   the model can be stored inside the ZIP file, if desired. Any binaries not