Deployments↑

This guide shows you how to manage deployments from the CAEPE account portal. The Deployments menu item has two pages:

• Deployment List: all your deployments. See Viewing deployments.
• Deployment Strategies: start a new deployment with a chosen strategy. See Deployment strategies.

Viewing deployments↑

Select Deployments > Deployment List to see the deployments associated with your account.

You can switch the view of the deployments between a "list" and "grid" view and filter the deployments by clicking the Filters button. You can filter by deployment name, status, and strategy type.

Each entry in the list or grid shows the deployment strategy (for example STD for standard, A/B, or SMK for a smoke test deployment), name, status, deployed date & time, deployed application, and the cluster on which the application is deployed. Click the pencil icon to edit the deployment and the wastebasket icon to delete it.

Deployment actions↑

Click the Actions button on a deployment to run one of the following on it, or to get the equivalent CLI command:

Select CLI Command to open the command for that deployment, then select Copy.

Generic CLI commands↑

Click the arrow next to the New Deployment button to see Generic CLI Commands for Deploy An App, Execute Dry-Run, Pre-Flight Test, and Estimate Time & Size. These commands contain placeholder values, such as --name name and --cluster cluster. Replace every placeholder with a real value before you run the command.

Deployment details↑

Click the View link next to any deployment to open its details. The details page has four tabs.

Deployment Info shows the deployment date and time, application, namespace, deployment strategy, schedule, and deployed path.

• The Deploy Differences section shows the percentage of successful resources, and compares the objects the deployment requested with the objects that are actually deployed.
• The Deployed Cluster(s) list shows the clusters on which the application is deployed. Click View Cluster to open a cluster.

Deployment History lists each time the deployment ran, with its status, application, app version, date, cluster, and time and size. Click Filters to filter the list.

Audit Logs lists the changes made to the deployment. You can filter by date or range, action, and user.

Event Logs shows the deployment's log output. You can filter by severity, and turn real-time logs on or off.

You can also edit and delete the deployment from the details page. Click the arrow next to the Delete button to roll back the deployment, or to get the CLI command for deploying the app, rolling back, or running a pre-flight test.

Deployment strategies↑

CAEPE supports six deployment strategies. Select Deployments > Deployment Strategies to see them. Each strategy card has a Create Deployment button, and an information (!) button that shows an illustration of how the strategy works.

Standard deployments↑

Standard strategy deploys an application to a specific environment, with an environment consisting of a cluster and a namespace.

Create a standard deployment by clicking the New Deployment button from the Deployments > Deployment List menu, or the Create Deployment button on the Standard Deployment card from the Deployments > Deployment Strategies menu.

Give the deployment a name and description, select an application to deploy, provide other optional information if required i.e (namespace, branch/tag or chart version).

In the next step, select the cluster or cluster group to deploy the application to.

In the final step, select add-ons for the deployment. These can include:

• Recommended actions:
  • Pre-flight tests

  Prerequisites

  Pod level services need to be install for preflight to work, e.g installed postgres/mysql/mariadb

  Info

  • Results returned from the pre-flight test are a direct output from Kubernetes
  • Nginx version by default is NA as nginx is at the global level and not at the pod level; thus, version is not returned by Kubernetes
  • Executing a dry run of the application deployment.
  • Scan for latest changes in manifests that define the application.
• Deployment arguments: Pass arguments to the deployment through placeholder variables in the application definition.
• Estimate time & size: Estimate the time and size of the application deployment.
• Priority: Set the deployment priority, defining which applications CAEPE deploys in which order.
• Post deployment actions: SSH and Webhook options to configure for post deployment actions.
• Sustainability schedule: Scale the deployment to zero outside working hours to cut cost and energy use. Turn on Sustainability Schedule, then select a sustainability schedule or select New Schedule to create one. Only sustainability schedules are listed. See Add a deployment to a sustainability schedule.

A/B deployments↑

Deploys two versions of an application available to specific users. A/B strategy deploys two versions of an application that are only available to a subset of users. These users are selected based on specific conditions and parameters the engineers choose.

Create an A/B deployment by clicking the Create Deployment button on the A/B Deployment card from the Deployments > Deployment Strategies menu.

First give the deployment a name and description, and select an application to deploy.

In the next step you define the A/B strategy to use. This can be either deploying the two applications to different clusters or to same cluster but different namespaces.

In the next steps, select add-ons for the A and B deployments. These can include:

• Recommended actions:
  • Pre-flight tests

  Prerequisites

  Pod level services need to be install for preflight to work, e.g installed postgres/mysql/mariadb

  Info

  • Results returned from the pre-flight test are a direct output from Kubernetes
  • Nginx version by default is NA as nginx is at the global level and not at the pod level; thus, version is not returned by Kubernetes
  • Executing a dry run of the application deployment.
  • Scan for latest changes in manifests that define the application.
• Deployment arguments: Pass arguments to the deployment through placeholder variables in the application definition.
• Estimate time & size: Estimate the time and size of the application deployment.
• Post deployment actions: SSH and Webhook options to configure for post deployment actions.

In the final step, select the deployment priority for both versions, defining which applications CAEPE deploys in which order.

Blue/Green deployments↑

Blue/Green strategy deploys a new version of the application that runs alongside the old version. Once certified to meet all the requirements, the traffic switches from the older (blue) version to the newer (green) version.

Give the deployment a name and description, select an application to deploy, provide other optional information if required i.e (namespace, branch/tag or chart version).

Optionally enable automatic deployment to trigger when any change is made on any of the resources associated with this deployment and enable rollbacks to switch to the previous application version in case of error.

In the next step, select the cluster or cluster group to deploy the application to.

The next step shows the configuration for blue/green deployment strategy. Read more about MaxSurge and MaxUnavailable in the Kubernetes documentation.

In the final step, select add-ons for the deployment. These can include:

• Recommended actions:
  • Pre-flight tests

  Prerequisites

  Pod level services need to be install for preflight to work, e.g installed postgres/mysql/mariadb

  Info

  • Results returned from the pre-flight test are a direct output from Kubernetes
  • Nginx version by default is NA as nginx is at the global level and not at the pod level; thus, version is not returned by Kubernetes
  • Executing a dry run of the application deployment.
  • Scan for latest changes in manifests that define the application.
• Deployment arguments: Pass arguments to the deployment through placeholder variables in the application definition.
• Estimate time & size: Estimate the time and size of the application deployment.
• Priority: Set the deployment priority, defining which applications CAEPE deploys in which order.
• Post deployment actions: SSH and Webhook options to configure for post deployment actions.

Canary deployments↑

Canary strategy deploys a new version that gradually shifts production traffic from the older version to the newer version to test new functionality on a subset of users before releasing it to the entire user base.

First give the deployment a name and description.

In the next step you configure the two versions.

For version one, you select an existing deployment which defines the application, namespace and destination cluster group to use.

In the version one column you set the percentage of traffic split between the versions.

For version two, you set a name along with an optional branch and namespace along with a cluster group to deploy to.

In the final step, select add-ons for the version two deployment. These can include:

• Recommended actions:
  • Pre-flight tests

  Prerequisites

  Pod level services need to be install for preflight to work, e.g installed postgres/mysql/mariadb

  Info

  • Results returned from the pre-flight test are a direct output from Kubernetes
  • Nginx version by default is NA as nginx is at the global level and not at the pod level; thus, version is not returned by Kubernetes
  • Executing a dry run of the application deployment.
  • Scan for latest changes in manifests that define the application.
• Deployment arguments: Pass arguments to the deployment through placeholder variables in the application definition.
• Estimate time & size: Estimate the time and size of the application deployment.
• Priority: Set the deployment priority, defining which applications CAEPE deploys in which order.
• Post deployment actions: SSH and Webhook options to configure for post deployment actions.

Recreate/Highlander deployments↑

Recreate/Highlander strategy deletes the old version of the application entirely and then deploys the new version of the application causing downtime during transition.

Give the deployment a name and description, select an application to deploy, provide other optional information if required i.e (namespace, branch/tag or chart version).

Optionally enable automatic deployment to trigger when any change is made on any of the resources associated with this deployment and enable rollbacks to switch to the previous application version in case of error.

In the next step, select the cluster or cluster group to deploy the application to.

The next step shows the configuration for recreate/highlander deployment strategy. Read more about Recreate in the Kubernetes documentation.

In the final step, select add-ons for the deployment. These can include:

• Recommended actions:
  • Pre-flight tests

  Prerequisites

  Pod level services need to be install for preflight to work, e.g installed postgres/mysql/mariadb

  Info

  • Results returned from the pre-flight test are a direct output from Kubernetes
  • Nginx version by default is NA as nginx is at the global level and not at the pod level; thus, version is not returned by Kubernetes
  • Executing a dry run of the application deployment.
  • Scan for latest changes in manifests that define the application.
• Deployment arguments: Pass arguments to the deployment through placeholder variables in the application definition.
• Estimate time & size: Estimate the time and size of the application deployment.
• Priority: Set the deployment priority, defining which applications CAEPE deploys in which order.
• Post deployment actions: SSH and Webhook options to configure for post deployment actions.

Rolling/Ramped deployments↑

Rolling/Ramped strategy gradually changes the old version of an application with new version causing no downtime with a smooth transition.

Give the deployment a name and description, select an application to deploy, provide other optional information if required i.e (namespace, branch/tag or chart version).

Optionally enable automatic deployment to trigger when any change is made on any of the resources associated with this deployment and enable rollbacks to switch to the previous application version in case of error.

In the next step, select the cluster or cluster group to deploy the application to.

The next step shows the configuration for the deployment strategy. The values in your Kubernetes manifest file define the values you see here. Read more about MaxSurge and MaxUnavailable in the Kubernetes documentation.

In the final step, select add-ons for the deployment. These can include:

• Recommended actions:
  • Pre-flight tests

  Prerequisites

  Pod level services need to be install for preflight to work, e.g installed postgres/mysql/mariadb

  Info

  • Results returned from the pre-flight test are a direct output from Kubernetes
  • Nginx version by default is NA as nginx is at the global level and not at the pod level; thus, version is not returned by Kubernetes
  • Executing a dry run of the application deployment.
  • Scan for latest changes in manifests that define the application.
• Deployment arguments: Pass arguments to the deployment through placeholder variables in the application definition.
• Estimate time & size: Estimate the time and size of the application deployment.
• Priority: Set the deployment priority, defining which applications CAEPE deploys in which order.
• Post deployment actions: SSH and Webhook options to configure for post deployment actions.