| `default-push-args` / `CF_DEFAULT_PUSH_ARGS` | Additional arguments for cf push command _(only define if you want has a specific need not med by the template)_ | _none_ |
| `scripts-dir` / `CF_SCRIPTS_DIR` | Directory where CF scripts (manifest, hook scripts) are located| `.` _(root project dir)_ |
| `rolling-strategy` / `CF_ROLLING_STRATEGY` | Use Cloud Foundry native zero-downtime deployment [strategy](https://docs.cloudfoundry.org/devguide/deploy-apps/rolling-deploy.html). See [Zero-downtime deployment](#zero-downtime-deployment) | `false` |
### Secrets management
@@ -292,6 +293,24 @@ So, what can be done about that?
* remind to delete your review env **manually before deleting the branch**
* otherwise you'll have to do it afterwards from your computer (using `cf` CLI) or from the Cloud Foundry console.
### 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.
- 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.
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
- 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
- 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
### Manifest processing
Deployment jobs support a versatile way to evaluate the **deployment manifest**.
