Documentation for Task Continuous Deployment

This commit adds documentation for how the continuous deployment process
works for 2.3.

Updates per code review

Author: mminella

spring-cloud-dataflow-docs/src/main/asciidoc/images/dataflow-task-application-versions.png

@@ -23,7 +23,8 @@ Sabby Anandan; Marius Bogoevici; Eric Bottard; Mark Fisher; Ilayaperumal Gopinat
 :github-code: https://github.com/{github-repo}
 :microsite-version: master
 
-:dataflow-asciidoc: https://raw.githubusercontent.com/spring-cloud/spring-cloud-dataflow/master/spring-cloud-dataflow-docs/src/main/asciidoc
+//:dataflow-asciidoc: https://raw.githubusercontent.com/spring-cloud/spring-cloud-dataflow/master/spring-cloud-dataflow-docs/src/main/asciidoc
+:dataflow-asciidoc: http://localhost:8000/src/main/asciidoc
 
 :docker-http-source-rabbit-version: 2.1.0.RELEASE
 :docker-time-source-rabbit-version: 2.1.0.RELEASE

spring-cloud-dataflow-docs/src/main/asciidoc/images/dataflow-task-default-version.png

@@ -15,7 +15,7 @@ A task application is short lived, meaning it stops running on purpose, and can
 A use case might be to scrape a web page and write to the database.
 The https://cloud.spring.io/spring-cloud-task/[Spring Cloud Task] framework is based on Spring Boot and adds the capability for Boot applications to record the lifecycle events of a short lived application such as when it starts, when it ends and the exit status.
 The https://docs.spring.io/spring-cloud-task/docs/{spring-cloud-task-version}/reference/htmlsingle/#features-task-execution-details[TaskExecution] documentation shows which information is stored in the database.
-The entry point for code execution in a Spring Cloud Task application is most often an implementation of Boot's CommandLineRunner interface as shown in this https://docs.spring.io/spring-cloud-task/docs/{spring-cloud-task-version}/reference/htmlsingle/#getting-started-writing-the-code[example].
+The entry point for code execution in a Spring Cloud Task application is most often an implementation of Boot's `CommandLineRunner` interface, as shown in this https://docs.spring.io/spring-cloud-task/docs/{spring-cloud-task-version}/reference/htmlsingle/#getting-started-writing-the-code[example].
 
 The Spring Batch project is probably what comes to mind for Spring developers writing short lived applications.
 Spring Batch provides a much richer set of functionality than Spring Cloud Task and is recommended when processing large volumes of data.
@@ -36,6 +36,7 @@ Before we dive deeper into the details of creating Tasks, we need to understand
 . <<spring-cloud-dataflow-task-launch>>
 . <<spring-cloud-dataflow-task-review-executions>>
 . <<spring-cloud-dataflow-task-definition-destroying>>
+. <<spring-cloud-dataflow-task-cd>>
 
 [[spring-cloud-dataflow-create-task-apps]]
 === Creating a Task Application
@@ -1159,4 +1160,69 @@ Spring Cloud Data Flow will have a suffix appended to it consisting of `-scdf-<t
 For example if I create a schedule name of `my-schedule` for a task definition of `tstamp` the
 schedule name will look like `my-schedule-scdf-tstamp`.
 
-NOTE: The `scdf-` separator is configurable by setting the `spring.cloud.dataflow.task.scheduleNamePrefix` property with the value you prefer.
+NOTE: The `scdf-` separator is configurable by setting the `spring.cloud.dataflow.task.scheduleNamePrefix` property with the value you prefer.
+
+[[spring-cloud-dataflow-task-cd]]
+== Continuous Deployment
+As task applications evolve, you want to get your updates to production.  This section walks through the capabilities that Spring Cloud Data Flow provides around being able to update task applications.
+
+When a task application is registered (<<spring-cloud-dataflow-register-task-apps>>), a version is associated with it.  A task application can have multiple versions associated with it, with one selected as the default.  The following image illustrates an application with multiple versions associated with it (see the timestamp entry).
+
+image::{dataflow-asciidoc}/images/dataflow-task-application-versions.png[Task Application Versions, scaledwidth="50%"]
+
+Versions of an application are managed by registering multiple applications with the same name and coordinates, _except_ the version.  For example, if you were to register an application with the following values, you would get one application registered with two versions (2.0.0.RELEASE and 2.1.0.RELEASE):
+
+* Application 1
+** Name: `timestamp`
+** Type: `task`
+** URI: `maven://org.springframework.cloud.task.app:timestamp-task:2.0.0.RELEASE`
+* Application 2
+** Name: `timestamp`
+** Type: `task`
+** URI: `maven://org.springframework.cloud.task.app:timestamp-task:2.1.0.RELEASE`
+
+Besides having multiple versions, Spring Cloud Data Flow needs to know which version to run on the next launch.  This is indicated by setting a version to be the default version.  Whatever version of a task application is configured as the default version is the one to be run on the next launch request.  You can see which version is the default in the UI as this image shows:
+
+image::{dataflow-asciidoc}/images/dataflow-task-default-version.png[Task Application Default Version, scaledwidth="50%"]
+
+=== Task Launch Lifecycle
+In previous versions of Spring Cloud Data Flow, when the request to launch a task was received, Spring Cloud Data Flow would deploy the application (if needed) and run it.  If the application was being run on a platform that did not need to have the application deployed every time (CloudFoundry for example), the previously deployed application was used.  This flow has changed in 2.3.  The following image shows what happens when a task launch request comes in now:
+
+image::{dataflow-asciidoc}/images/dataflow-task-launch-flow.png[Flow For Launching A Task, scaledwidth="50%"]
+
+There are three main flows to consider in the preceding diagram.  Launching the first time or launching with no changes is one. The other is launching when there are changes.  We look at the flow with no changes first.
+
+==== Launch a Task With No Changes
+1. A launch request comes into to Data Flow.  Data Flow determines that an upgrade is not required, since nothing has changed (no properties, deployment properites, or versions have changed since the last execution).
+
+[start=5]
+5. On platforms that cache a deployed artifact (CloudFoundry at the writing of this documentation), Data Flow checks whether the application was previously deployed.
+6. If the application needs to be deployed, Data Flow does the deployment of the task application.
+7. Data Flow launches the application.
+
+That flow is the default behavior and occurs every time a request comes in if nothing has changed.  It is important to note that this is the same flow that Data Flow has always executed for launching of tasks.
+
+==== Launch a Task With Changes That Is Not Currently Running
+The second flow to consider when launching a task is whether there was a change in any of the task application version, application properties, or deployment properties.  In this case, the following flow is executed:
+
+1. A launch request comes into Data Flow.  Data Flow determines that an upgrade is required since there was a change in either task application version, application properties, or deployment properties.
+2. Data Flow checks to see whether another instance of the task definition is currently running.
+
+[start=4]
+4. If there is not another instance of the task definition currently running, the old deployment is deleted.
+5. On platforms that cache a deployed artifact (CloudFoundry at the writing of this documentation), Data Flow checks whether the application was previously deployed (this check is always be no in this flow).
+6. Data Flow does the deployment of the task application with the updated values (new application version, new merged properties, and new merged deployment properties).
+7. Data Flow launches the application.
+
+This flow is what fundementally enables continuous deployment for Spring Cloud Data Flow.
+
+==== Launch a Task With Changes While Another Instance Is Running
+The last main flow is when a launch request comes to Spring Cloud Data Flow to do an upgrade but the task definition is currently running.  In this case, the launch is blocked due to the requirement to delete the current application.  On some platforms (CloudFoundry at the writing of this document), deleting the application causes all currently running applications to be shut down.  This feature prevents that from happening.  The following process describes what happens when a task changes while another instance is running:
+
+1. A launch request comes into to Data Flow.  Data Flow determines that an upgrade is required, since there was a change in either task application version, application properties, or deployment properties.
+2. Data Flow checks to see whether another instance of the task definition is currently running.
+3. Data Flow prevents the launch from happening because other instances of the task definition are running.
+
+NOTE: Any launch that requires an upgrade of a task definition that is running at the time of the request is blocked from executing due to the need to delete any currently running tasks.
+
+