@@ -145,21 +145,24 @@ The template processes the following steps:
#### Zero-downtime deployment
Historically Cloud Foundry did not provided any feature for deploying a new version without service interruption. The documentation proposed a [blue-green method](https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html) with was implemented in this template. It is enabled with the `CF_XXX_ZERODOWNTIME`variable and is enabled by default in production.
Historically Cloud Foundry did not provide any feature for deploying a new version without downtime. Therefor template implemented a [blue-green method](https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html). It can be enabled with the `CF_XXX_ZERODOWNTIME`variable and it is enabled by default for production.
Drawbacks:
- This solution is complex, runs a full copy of the application and so requires to double the allocated resources _(cpu, ram and disk)_
Starting with CF CLI v7, a new builtin feature called [rolling startegy](https://docs.cloudfoundry.org/devguide/deploy-apps/rolling-deploy.html) was added. It allow to rotate instances one by one instead of switching all instances at once.
Starting with CF CLI v7, a new built-in feature called [rolling depoyment](https://docs.cloudfoundry.org/devguide/deploy-apps/rolling-deploy.html) was added.
It allows to rollout instances one by one instead of switching all instances at once.
This feature can be enabled with `rolling-strategy` input or `CF_ROLLING_STRATEGY` variable. Enabling it as a few implications:
- All environments will use this strategy. So `$CF_XXX_ZERODOWNTIME` is ignored
- The `cf-pre-start.sh` hook is only called during the first deployment as `--no-start` is incompatible with the strategy
- All environments will use this strategy. So `$CF_XXX_ZERODOWNTIME` is ignored.
- The `cf-pre-start.sh` hook is only called during the first deployment as `--no-start` is incompatible with the strategy.
- During the next deployments, two versions of your application will accept requests concurrently. It may have a impact on:
- Single instance application which will temporarily become concurrent
- Atomic actions like database migrations which might break the previous version
- Single instance application which will temporarily become concurrent,
- Atomic actions like database migrations which might break the previous version.
- Deployment won't stop if `cf-readiness-check.sh` hook fails. So the `health-check-http-endpoint` should check all services availability.
- The `cf-post-bluegreen.sh` hook is not called as it is not a blue-green deployment
- The `cf-post-bluegreen.sh` hook is not called as it is not a blue-green deployment.
