Prefer app over application except in product names [#161632866]

README.md

@@ -1,6 +1,6 @@
 # Guide for Developers Pushing Apps to Cloud Foundry
 
-This is a guide for developers on deploying and troubleshooting applications running in Cloud Foundry.
+This is a guide for developers on deploying and troubleshooting apps running in Cloud Foundry.
 
 This is one of several repositories that go into a complete documentation set.
 
@@ -12,8 +12,8 @@ See the [docs-book-cloudfoundry](http://github.com/cloudfoundry/docs-book-cloudf
 repository for the complete list of open source documentation repositories, as well as information about the publishing process.
 
 docs-dev-guide/deploy-apps subdirectory:
-Develop and Manage Applications
-Develop and run applications in the cloud.
+Develop and Manage Apps
+Develop and run apps in the cloud.
 
 docs-dev-guide/capi subdirectory:
 Manage resources via the Cloud Foundry API
@@ -24,4 +24,3 @@ Create and publish free or metered services for Cloud Foundry apps.
 
 
 This repository used to contain the subdirectory docs-dev-guide/cf-cli, documenting the Cloud Foundry Command Line Interface (cf CLI). The content from this subdirectory has been moved to its own repository, [docs-cf-cli](http://github.com/cloudfoundry/docs-cf-cli).
-

deploy-apps/_link-configure-trusted-certificates.html.md.erb

@@ -1 +1 @@
-For information about providing trusted certificates to applications running on Cloud Foundry, see [Configuring Trusted System Certificates for Applications](../../running/trusted-system-certificates.html).
+For information about providing trusted certificates to apps running on Cloud Foundry, see [Configuring Trusted System Certificates for Apps](../../running/trusted-system-certificates.html).

deploy-apps/app-lifecycle.html.md.erb

@@ -1,23 +1,23 @@
 ---
-title: Application Container Lifecycle
+title: App Container Lifecycle
 owner: Diego
 ---
 
 <strong><%= modified_date %></strong>
 
-This topic describes the lifecycle of an application container for Cloud Foundry (CF) deployments running on the Diego architecture.
+This topic describes the lifecycle of an app container for Cloud Foundry (CF) deployments running on the Diego architecture.
 
 ##<a id="deployment"></a> Deployment
 
-The application deployment process involves uploading, staging, and starting the app in a container. Your app must successfully complete each of these phases within certain time limits. The default time limits for the phases are as follows:
+The app deployment process involves uploading, staging, and starting the app in a container. Your app must successfully complete each of these phases within certain time limits. The default time limits for the phases are as follows:
 
 * Upload: 15 minutes
 * Stage: 15 minutes
 * Start: 60 seconds
 
 <p class="note"><strong>Note</strong>: Your administrator can change these defaults. Check with your administrator for the actual time limits set for app deployment.</p>
 
-Developers can change the time limit for starting apps through an application manifest or on the command line. For more information, see [The timeout attribute](manifest.html#timeout) section of the Deploying with Application Manifests topic and [Using Application Health Checks](./healthchecks.html).
+Developers can change the time limit for starting apps through an app manifest or on the command line. For more information, see [The timeout attribute](manifest.html#timeout) section of the Deploying with App Manifests topic and [Using Application Health Checks](./healthchecks.html).
 
 ##<a id="crash-events"></a>Crash Events
 
@@ -31,4 +31,4 @@ Certain operator actions require restarting VMs with containers hosting app inst
 
 When <%=vars.product_name%> requests a shutdown of your app instance, either in response to the command `cf scale APPNAME -i NUMBER-OF-INSTANCES` or because of a system event, CF sends the app process in the container a SIGTERM. The process has ten seconds to shut down gracefully. If the process has not exited after ten seconds, CF sends a SIGKILL.
 
-Apps must finish their in-flight jobs within ten seconds of receiving the SIGTERM before CF terminates the app with a SIGKILL. For instance, a web app must finish processing existing requests and stop accepting new requests. 
+Apps must finish their in-flight jobs within ten seconds of receiving the SIGTERM before CF terminates the app with a SIGKILL. For instance, a web app must finish processing existing requests and stop accepting new requests.

deploy-apps/app-ssh-overview.html.md.erb

@@ -1,5 +1,5 @@
 ---
-title: Application SSH Overview
+title: App SSH Overview
 owner: Diego
 ---
 
@@ -33,16 +33,16 @@ Operators, space managers, and space developers can configure SSH access for <%=
     <td>cf CLI <a href="http://cli.cloudfoundry.org/en-US/cf/allow-space-ssh.html">allow-space-ssh</a> and <a href="http://cli.cloudfoundry.org/en-US/cf/disallow-space-ssh.html">disallow-space-ssh</a> commands</td>
   </tr><tr>
     <td>Space Developer</td>
-    <td>Application</td>
+    <td>App</td>
     <td>cf CLI <a href="http://cli.cloudfoundry.org/en-US/cf/enable-ssh.html">enable-ssh</a> and <a href="http://cli.cloudfoundry.org/en-US/cf/disable-ssh.html">disable-ssh</a> commands</td>
   </tr>
 </table>
 
-An application is SSH-accessible only if operators, space managers, and space developers all grant SSH access at their respective levels. For example, the image below shows a deployment where:
+An app is SSH-accessible only if operators, space managers, and space developers all grant SSH access at their respective levels. For example, the image below shows a deployment where:
 
 * An operator allowed SSH access at the deployment level.
-* A space manager allowed SSH access for applications running in spaces "A" and "B" but not "C."
-* A space developer enabled SSH access for applications that include "Foo," "Bar," and "Baz."
+* A space manager allowed SSH access for apps running in spaces "A" and "B" but not "C."
+* A space developer enabled SSH access for apps that include "Foo," "Bar," and "Baz."
 
 As a result, apps "Foo," "Bar," and "Baz" accept SSH requests.
 
@@ -51,7 +51,7 @@ As a result, apps "Foo," "Bar," and "Baz" accept SSH requests.
 
 ## <a id='app-ssh-config'></a> SSH Access for Apps and Spaces
 
-Space managers and space developers can configure SSH access from the command line. The Cloud Foundry Command Line Interface (cf CLI) also includes commands to return the value of the SSH access setting. See the [Accessing Apps with Diego SSH](./ssh-apps.html) topic to use and configure SSH at both the application level and the space level.
+Space managers and space developers can configure SSH access from the command line. The Cloud Foundry Command Line Interface (cf CLI) also includes commands to return the value of the SSH access setting. See the [Accessing Apps with Diego SSH](./ssh-apps.html) topic to use and configure SSH at both the app level and the space level.
 
 
 ## <a id="platform-ssh-config"></a> Configuring SSH Access for <%= vars.product_full %>

deploy-apps/blue-green.html.md.erb

@@ -5,7 +5,7 @@ owner: Routing
 
 <strong><%= modified_date %></strong>
 
-Blue-green deployment is a technique that reduces downtime and risk by running 
+Blue-green deployment is a technique that reduces downtime and risk by running
 two identical production environments called Blue and Green.
 
 At any time, only one of the environments is live, with the live environment
@@ -19,7 +19,7 @@ Once you have deployed and fully tested the software in Green, you switch the
 router so all incoming requests now go to Green instead of Blue.
 Green is now live, and Blue is idle.
 
-This technique can eliminate downtime due to application deployment.
+This technique can eliminate downtime due to app deployment.
 In addition, blue-green deployment reduces risk: if something unexpected happens
 with your new version on Green, you can immediately roll back to the last
 version by switching back to Blue.
@@ -31,13 +31,13 @@ version by switching back to Blue.
 
 ## <a id='blue-green-deployment'></a>Blue-Green Deployment with Cloud Foundry Example ##
 
-For this example, we’ll start with a simple application: "demo-time."
+For this example, we’ll start with a simple app: "demo-time."
 This app is a web page that displays the words "Blue time" and the date/time on
 the server.
 
 ### <a id='push-an-app'></a>Step 1: Push an App ###
-Use the Cloud Foundry Command Line Interface (cf CLI) to push the application.
-Name the application "Blue" with the subdomain "demo-time."
+Use the Cloud Foundry Command Line Interface (cf CLI) to push the app.
+Name the app "Blue" with the subdomain "demo-time."
 
 <pre class="terminal">
 $ cf push Blue -n demo-time
@@ -52,9 +52,9 @@ As shown in the graphic below:
 
 ### <a id='update-and-push'></a>Step 2: Update App and Push ###
 
-Now make a change to the application.
-First, replace the word "Blue" on the web page with "Green," then rebuild the source file for the application.
-Run `cf push` again, but use the name "Green" for the application and provide a
+Now make a change to the app.
+First, replace the word "Blue" on the web page with "Green," then rebuild the source file for the app.
+Run `cf push` again, but use the name "Green" for the app and provide a
 different subdomain to create a temporary route:
 
 <pre class="terminal">
@@ -63,7 +63,7 @@ $ cf push Green -n demo-time-temp
 
 After this push:
 
-* Two instances of our application are now running on Cloud Foundry: the
+* Two instances of our app are now running on Cloud Foundry: the
 original Blue and the updated Green.
 * The CF Router continues sending all traffic for `demo-time.example.com` to
 Blue.
@@ -76,7 +76,7 @@ The router now also sends any traffic for `demo-time-temp.example.com` to Green.
 Now that both apps are up and running, switch the router so all incoming
 requests go to the Green app *and* the Blue app.
 Do this by mapping the original URL route (`demo-time.example.com`) to the Green
-application using the [cf map-route](http://cli.cloudfoundry.org/en-US/cf/map-route.html) command.
+app using the [cf map-route](http://cli.cloudfoundry.org/en-US/cf/map-route.html) command.
 
 <pre class="terminal">
 $ cf map-route Green example.com -n demo-time
@@ -119,5 +119,5 @@ You can now use `cf unmap-route` to remove the route `demo-time-temp.example.com
 Cloud Foundry community members have written plugins to automate the blue-green
 deployment process. These include:
 
-* [Autopilot](https://github.com/contraband/autopilot): Autopilot is a Cloud Foundry Go plugin that provides a subcommand, `zero-downtime-push`, for hands-off, zero-downtime application deploys.
+* [Autopilot](https://github.com/contraband/autopilot): Autopilot is a Cloud Foundry Go plugin that provides a subcommand, `zero-downtime-push`, for hands-off, zero-downtime app deploys.
 * [BlueGreenDeploy](https://github.com/bluemixgaragelondon/cf-blue-green-deploy): cf-blue-green-deploy is a plugin, written in Go, for the Cloud Foundry Command Line Interface (cf CLI) that automates a few steps involved in zero-downtime deploys.

deploy-apps/cf-scale.html.md.erb

@@ -1,46 +1,46 @@
 ---
-title: Scaling an Application Using cf scale
+title: Scaling an App Using cf scale
 owner: CAPI
 ---
 
 <strong><%= modified_date %></strong>
 
-Factors such as user load, or the number and nature of tasks performed by an application, can change the disk space and memory the application uses.
-For many applications, increasing the available disk space or memory can improve
+Factors such as user load, or the number and nature of tasks performed by an app, can change the disk space and memory the app uses.
+For many apps, increasing the available disk space or memory can improve
 overall performance.
-Similarly, running additional instances of an application can allow the
-application to handle increases in user load and concurrent requests.
-These adjustments are called **scaling** an application.
+Similarly, running additional instances of an app can allow the
+app to handle increases in user load and concurrent requests.
+These adjustments are called **scaling** an app.
 
-Use [cf scale](http://cli.cloudfoundry.org/en-US/cf/scale.html) to scale your application up or down to meet changes in traffic
+Use [cf scale](http://cli.cloudfoundry.org/en-US/cf/scale.html) to scale your app up or down to meet changes in traffic
 or demand.
 
 <%=vars.autoscaler_note_dev_guide%>
 
 ## <a id="horizontal"></a>Scaling Horizontally ##
 
-Horizontally scaling an application creates or destroys instances of your application.
+Horizontally scaling an app creates or destroys instances of your app.
 
-Incoming requests to your application are automatically load balanced across all
-instances of your application, and each instance handles tasks in parallel with
+Incoming requests to your app are automatically load balanced across all
+instances of your app, and each instance handles tasks in parallel with
 every other instance.
-Adding more instances allows your application to handle increased traffic and
+Adding more instances allows your app to handle increased traffic and
 demand.
 
-Use `cf scale APP -i INSTANCES` to horizontally scale your application.
-Cloud Foundry will increase or decrease the number of instances of your application to match `INSTANCES`.
+Use `cf scale APP -i INSTANCES` to horizontally scale your app.
+Cloud Foundry will increase or decrease the number of instances of your app to match `INSTANCES`.
 
 <pre class='terminal'>
 $ cf scale myApp -i 5
 </pre>
 
 ## <a id="vertical"></a>Scaling Vertically ##
 
-Vertically scaling an application changes the disk space limit or memory limit
-that Cloud Foundry applies to all instances of the application.
+Vertically scaling an app changes the disk space limit or memory limit
+that Cloud Foundry app to all instances of the app.
 
 Use `cf scale APP -k DISK` to change the disk space limit applied to all
-instances of your application.
+instances of your app.
 `DISK` must be an integer followed by either an **M**, for megabytes, or **G**,
 for gigabytes.
 
@@ -49,7 +49,7 @@ $ cf scale myApp -k 512M
 </pre>
 
 Use `cf scale APP -m MEMORY` to change the memory limit applied to all instances
-of your application.
+of your app.
 `MEMORY` must be an integer followed by either an **M**, for megabytes, or
 **G**, for gigabytes.
 

deploy-apps/deploy-app.html.md.erb

@@ -1,5 +1,5 @@
 ---
-title: Deploy an Application
+title: Deploy an App
 owner: CAPI
 ---
 
@@ -19,7 +19,7 @@ Between the time that you run `cf push` and the time that the app is available,
 * Selects an appropriate Diego [cell](../../concepts/architecture/index.html#diego-cell) to run the droplet
 * Starts the app
 
-For more information about the lifecycle of an app, see the <a href="app-lifecycle.html">Application Container Lifecycle</a> topic.
+For more information about the lifecycle of an app, see the <a href="app-lifecycle.html">App Container Lifecycle</a> topic.
 
 An app that uses services, such as a database, messaging, or email
 server, is not fully functional until you provision the service and, if
@@ -49,7 +49,7 @@ the app.
 
 For help preparing to deploy your app, see:
 
-* [Considerations for Designing and Running an Application in the Cloud](./prepare-to-deploy.html)
+* [Considerations for Designing and Running an App in the Cloud](./prepare-to-deploy.html)
 * [Buildpacks](../../buildpacks/index.html)
 
 
@@ -129,7 +129,7 @@ target app space.
 
 You can define deployment options on the command line, in a manifest file, or
 both together.
-See [Deploying with Application Manifests](./manifest.html) to learn how
+See [Deploying with App Manifests](./manifest.html) to learn how
 app settings change from push to push, and how command-line options,
 manifests, and commands like `cf scale` interact.
 
@@ -144,24 +144,24 @@ Cloud Foundry uploads all app files except version control files and
 folders with names such as `.svn`, `.git`, and `_darcs`.
 To exclude other files from upload, specify them in a `.cfignore` file in the
 directory where you run the push command.
-For more information, see the [Ignore Unnecessary Files When Pushing](./prepare-to-deploy.html#exclude) section of the [Considerations for Designing and Running an Application in the Cloud](./prepare-to-deploy.html) topic.
+For more information, see the [Ignore Unnecessary Files When Pushing](./prepare-to-deploy.html#exclude) section of the [Considerations for Designing and Running an App in the Cloud](./prepare-to-deploy.html) topic.
 
-For more information about the manifest file, see the [Deploying with Application Manifests](./manifest.html) topic.
+For more information about the manifest file, see the [Deploying with App Manifests](./manifest.html) topic.
 
 ### <a id='profile'></a>Configure Pre-Runtime Hooks ###
 
 <p class="note"><strong>Note</strong>: The Java buildpack does not support pre-runtime hooks.</p>
 
-To configure pre-runtime hooks, create a file named `.profile` and place it in the root of your app directory. 
-If the directory includes a `.profile` script, then Cloud Foundry executes it immediately before each instance of your app starts. 
+To configure pre-runtime hooks, create a file named `.profile` and place it in the root of your app directory.
+If the directory includes a `.profile` script, then Cloud Foundry executes it immediately before each instance of your app starts.
 Because the `.profile` script executes after the buildpack, the script has access to the language runtime environment created by the buildpack.
 
-<p class="note"><strong>Note</strong>: Your app root directory may also include a <code>.profile.d</code> directory that contains bash scripts that perform initialization tasks for the buildpack. 
+<p class="note"><strong>Note</strong>: Your app root directory may also include a <code>.profile.d</code> directory that contains bash scripts that perform initialization tasks for the buildpack.
 Developers should not edit these scripts unless they are using a <a href="../../buildpacks/custom.html">custom buildpack</a>.</p>
 
-You can use the `.profile` script to perform app-specific initialization tasks, such as setting custom environment variables. 
-Environment variables are key-value pairs defined at the operating system level. 
-These key-value pairs provide a way to configure the apps running on a system. 
+You can use the `.profile` script to perform app-specific initialization tasks, such as setting custom environment variables.
+Environment variables are key-value pairs defined at the operating system level.
+These key-value pairs provide a way to configure the apps running on a system.
 For example, any app can access the LANG environment variable to determine which language to use for error messages and instructions, collating sequences, and date formats.
 
 To set an environment variable, add the appropriate bash commands to your `.profile` file. See the example below.
@@ -171,7 +171,7 @@ To set an environment variable, add the appropriate bash commands to your `.prof
 export LANG=en_US.UTF-8
 ~~~
 
-<p class="note"><strong>Note</strong>: If you are using a PHP buildpack version prior to v4.3.18, the buildpack does not execute your PHP app's <code>.profile</code> script. Your PHP app will host the <code>.profile</code> script's contents. 
+<p class="note"><strong>Note</strong>: If you are using a PHP buildpack version prior to v4.3.18, the buildpack does not execute your PHP app's <code>.profile</code> script. Your PHP app will host the <code>.profile</code> script's contents.
 This means that any PHP app staged using the affected PHP buildpack versions can leak credentials placed in the <code>.profile</code> script.</p>
 
 ## <a id='push'></a>Step 5: Push the App ##
@@ -182,7 +182,7 @@ Run the following command to deploy an app without a manifest:
 
 If you provide the app name in a manifest, you can reduce the command to
 `cf push`.
-See [Deploying with Application Manifests](./manifest.html).
+See [Deploying with App Manifests](./manifest.html).
 
 Because all you have provided is the name of your app, `cf push` sets the
 number of instances, amount of memory, and other attributes of your app
@@ -262,4 +262,4 @@ If your app does not start on Cloud Foundry, first ensure that your
 app can run locally.
 
 You can troubleshoot your app in the cloud using the cf CLI.
-See [Troubleshoot Application Deployment and Health](./troubleshoot-app-health.html).
+See [Troubleshoot App Deployment and Health](./troubleshoot-app-health.html).