Deployment overview

When you make a change to an API proxy, you can save it as a new revision and deploy it to your cluster.

This section describes how to manage deployments primarily within the hybrid UI. For information about managing deployments using the Apigee APIs, see Manage deployments using the API.

About deployment

Apigee hybrid propagates new revisions of your API proxies via the Synchronizer and MPs. The MPs continually poll the Synchronizer for changes to the API proxy bundles. When they detect one, they fetch it via HTTP and then deploy that bundle.

In Apigee hybrid, MPs act independently of one another and any given MP can be in a different state than the other MPs (such as active or disabled). This is known as an "eventually consistent deployment model" for API proxies.

The following image shows the deployment lifecycle of a new API proxy on hybrid:

Proxy revisions limitations

The following limitations apply to proxy revisions:

  • If you make any changes to an API proxy, you must deploy it as a new revision.
  • After you deploy an API proxy, the revision is read-only. You cannot change an API proxy revision (such as to make incremental changes); the only way to "change" a revision is to create a new revision and deploy it.
  • MPs can only deploy a proxy bundle in its entirety. If you make changes to individual fragments or policies, the MPs will still deploy the entire proxy bundle.

Zero-downtime deployment

All successful API proxy deployments to Apigee hybrid, are zero-downtime deployments. Proxy deployments happens in this order:

  1. Revision 1 of the proxy /hello is deployed and handling traffic.
  2. Revision 2 of /hello is deployed.
  3. Revision 2 is deployed to the message processors in the runtime plane.
  4. Revision 1 is undeployed.

The proxy revision deployment is now complete with no downtime.

View deployment status

MPs communicate the status of proxies to the UDCA, which then sends that status to GCP and the management plane.

Deploying an API proxy on Apigee hybrid does not make it immediately available. It takes time for the proxy to be synchronized across all MPs in the runtime plane. However, Apigee provides tools that can give you some information about the status of your API proxy revisions.

You can get the deployment status of an API proxy in one of the following ways:

Within the hybrid UI, there are several views that provide the deployment status of your API proxies:

Hybrid UI View Steps & Description
Proxies
  1. Select Develop > API Proxies:

The hybrid UI uses the following icons to give a quick status for each proxy:

indicates that the proxy has not been deployed to the selected environment.
indicates that there are no errors or warnings for that proxy in the selected environment.
indicates that there are one or more pods in the selected environment that require your attention.
indicates that there is an error with one or more pods in the selected environment that require your attention.

To view the status icon, click the Develop tab; the icon is displayed next to the Deploy to button:

Alternatively, you can select Develop > API Proxies and click a proxy.

Deployments
  1. Select Develop > API Proxies.
  2. Click a proxy.
  3. Under Deployments, hover over the Details link.

    The following example shows the results of a successful deployment:

    In the event that there are issues encountered during the deployment, the following information will be provided including information about the cause of the issues:

    • n pods reported errors: The number of MPs that reported an error during the latest synchronization process.
    • n pods in unknown status: The number of MPs that hybrid has determined are active (within the last 5 minutes), but have not reported a status that is specific to the latest deployment (either success or failure). Because of the asynchronous nature of the deployment process, hybrid does not currently know which revision is deployed on these pods.

To retrieve deployment status information, the UI polls the Unified Analytics Platform (UAP), which obtains deployment status directly from the MP (runtime) pods. The UI polls the UAP for 5 minutes, hoping to get 100% of pods to report their status, which the UI then updates in this view. After 5 minutes, you can refresh the view to restart polling.

Alternatively, you can click the Develop tab and hover over the Details link to view more details about deployment issues:

During deployment, the UI displays a pod synchronization status bar. Next to this bar, the UI also displays pod status messages.

The pod synchronization status bar also shows the percentage of pods that have reported a status (any status) related to that revision within the last 5 minutes.

If you hover over the Pod synchronization status bar, the UI also displays the Runtime pods popup.

Change default deployment environment

The UI has a number of helpful indicators on the Develop tab that show the revision and status of the default environment. The following images highlight these indicators:

You can change the default environment to any environment in the hybrid organization.

To change the default environment:

  1. On the Develop tab, click the Deploy to drop-down list.

    The drop-down list expands. Each row shows an environment, the revision that is deployed to that environment, and an Undeploy button.

    The following example shows three environments with the default environment listed first:

  2. Click on a different environment’s row—anywhere except the Undeploy or Deploy buttons.

    For example, to change the default environment to the “test-env-42” environment:

    The hybrid UI updates to now display the status of the new default environment. In addition, the default environment in the Deploy to drop-down list is the newly selected environment.