| `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
@@ -145,6 +147,7 @@ Here are variables supported to configure review environments:
| `review-retired-app-suffix` / `CF_REVIEW_RETIRED_APP_SUFFIX` | If set, the app old version is not deleted/overriden but renamed with this suffix | _none_ |
Note: By default review `environment.url` will be built as `${CF_REVIEW_ENVIRONMENT_SCHEME}://${$CI_PROJECT_NAME}-${CI_ENVIRONMENT_SLUG}.${CF_REVIEW_ENVIRONMENT_DOMAIN}/${CF_REVIEW_ROUTE_PATH}`
@@ -167,6 +170,7 @@ Here are variables supported to configure the integration environment:
| `integ-app-name` / `CF_INTEG_APP_NAME` | Application name for `integration` env | `"${CF_BASE_APP_NAME}-integration"` |
| `integ-environment-url` / `CF_INTEG_ENVIRONMENT_URL` | The integration environment url **including scheme** (ex: `https://my-application-integration.nonpublic.domain.com`). Do not use variable inside variable definition as it will result in a two level cascade variable and gitlab does not allow that. | _none_ |
@@ -191,6 +195,7 @@ Here are variables supported to configure the staging environment:
| `staging-app-name` / `CF_STAGING_APP_NAME` | Application name for `staging` env | `"${CF_BASE_APP_NAME}-staging"` |
| `staging-environment-url` / `CF_STAGING_ENVIRONMENT_URL` | The staging environment url **including scheme** (ex: `https://my-application-staging.nonpublic.domain.com`). Do not use variable inside variable definition as it will result in a two level cascade variable and gitlab does not allow that. | _none_ |
@@ -214,6 +219,7 @@ Here are variables supported to configure the production environment:
| `prod-app-name` / `CF_PROD_APP_NAME` | Application name for `production` env | `$CF_BASE_APP_NAME` |
| `prod-host-name` / `CF_PROD_HOST_NAME` | Application host name for `production` env | `$CF_DEFAULT_ROUTE_PATH` |
| `prod-deploy-strategy` / `CF_PROD_DEPLOY_STRATEGY` | Defines the deployment to production strategy. One of `manual` (i.e. _one-click_) or `auto`. | `manual` |
@@ -287,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**.