anchor.diff:  
   Spring Cloud Pipelines will dynamically create the services in the test spaces as per the `sc-pipelines.yml` file we created previously. Optionally, a second section can be added to the `sc-pipelines.yml` file for the stage environment, and these will be created dynamically as well. Prod services, however, must always be created manually.
   
  -For this example, we will create the stage and services manually.
  +For this example, we will create the stage and prod services manually.
   
   Create the services listed in the app manifest files in both `scp-stage` and `scp-prod`.
   
   ===== 1.13 Update Spring Cloud Pipelines credentials file
   Update the `greeting-ui` and `fortune-service` credentials files with Cloud Foundry information. Replace values in the example below as appropriate for your Cloud Foundry environment.
   
  -Notice that the space name specified is a prefix. Spring Cloud Pipelines will append the app name, matching the test space names created previously. The stage and prod space names are not prefixes and will not be altered by Spring Cloud Pipelines.
  +Notice that the test space name specified is a prefix, unlike the stage and prod space names, which are literals. Spring Cloud Pipelines will append the app name to the test space name, thereby matching the test space names we created manually. The stage and prod space names are not prefixes and will not be altered by Spring Cloud Pipelines.
   
   Note also the `paas-hostname-uuid`. The value will be included in each route created. This value is optional, but it is useful in shared/multi-tenant environments such as PWS, as it helps ensure routes are unique. Change it to a unique uuid of your choosing.
   
  
positive.code: * We can count on the pipelines to:
  - automatically provision services in test spaces, and optionally in stage as well
  - dynamically clean up the test spaces between pipeline executions
  - upload the app artifacts to the maven repo (Bintray)
  - tag the GitHub repositories with `dev/<version_number>` and `prod/<version_number>`
  * After each successful pipeline run, we are in a position to roll back to the last deployed version using the `prod-rollback` job, if necessary
  
  These accomplishments are extremely valuable, but in order to derive confidence and reliability from the pipelines, we need to incorporate testing. We do this in Stage 2 of the app migration.
  
negative.code: 
  * Inter-team communication will be simpler
  - Consumer and producer teams can now communicate requirements through codified contracts
  - The inventory of contracts serves as a record and reference of the agreed upon APIs
  * Developer productivity will increase
  - Producers can quickly and easily generate contract-based stubs
  - Consumers no longer have to manually stub out APIs and write tests with arbitrary hard-coded responses - instead they can use the auto-generated stubs and test for contract-based responses
  