This topic provides a quick overview of proxy deployment. You can deploy proxies using the mangement UI, command-line scripts, or with APIs.
A proxy must be deployed before it can be invoked. Generally, it's up to you when you deploy. When you are working in a test environment, you may deploy iteratively many times. On the other hand, the decision to deploy a proxy from the test environment to a production environment usually depends on lifecycle rules established by your development team.
Deploy or redeploy a proxy when you:
- Create a new proxy (deployment happens automatically)
- Modify an existing proxy
- Create a new revision of a proxy
- Create a new version of a proxy
- Push a proxy from one environment to another, such as from a test environment to a production environment.
You deploy a proxy to an environment. All organizations in Apigee Edge, by default, have two environments called test and prod. These environments are merely designed to provide you with one area to work on and test API changes, and another area where APIs are exposed to apps. The following figure shows a proxy that is deployed to the test environment, as indicated by the green dot.
Depending on your role, you may not be able to deploy to all environments. Users can only deploy to the test environment. If you're an administrator you can deploy to any environment.
How you deploy a proxy depends on where you are developing the proxy. If you are working in the UI, you can easily deploy a proxy with just a couple of mouse clicks. A new proxy is automatically deployed when you create it; you don't have to do anything special. The procedure for redeploying an existing proxy is almost as simple. Just select which deployment environment to deploy to, and the management UI takes care of the rest. For more information, see Deploying proxies in the UI.
If you are developing proxies and related components offline (that is, working with proxy XML files and other code directly on your filesystem), Apigee Edge provides a convenient command-line deployment tool that you can use. You can also obtain a sample shell script that you can configure and run to upload and deploy your proxy files. For more information, see Deploying proxies from the command line.
Finally, you can use the Edge management API to deploy proxies. The deployment APIs expose atomic functions that your development team can coordinate to automate and optimize your API development lifecycle. See Deploy API proxies using the management API.
Revisions let you manage API proxy updates as you create and deploy them to an environment. Revisions are sequentially numbered, enabling you to revert a change by deploying a previous revision of your API proxy. Only one revision of an API proxy can be deployed in an environment at a given time.
Typically, an existing revision must be undeployed before a new one can be deployed. Other advanced options include overwriting a deployed revision or opting not to increment a revision at all. For example, sometimes when you make minor changes, you might not want to increment the revision. These advanced options can be accomplished throught direct calls to the Edge management API. See Deploy API proxies using the management API.
While a revision usually represents a relatively minor update, made in the course of a development cycle, the version of an API proxy should change relatively infrequently. Typically, a version reflects a significant change in the signature of an API and requires developers to modify their code accordingly. Versions are usually reflected directly in the API proxy's base URI. For example:
- Never release an API without a version.
- Make the version mandatory.
- Specify the version with a "v" prefix. Place the prefix to the far left in the URL so that it has the highest scope, e.g., /v1/dogs.
- Use a single ordinal number, such as v1, v2, and so on.
- Make the version part of the API base path
- Maintain at least one version back.
- Set up a reasonable deprecation policy. Give developers plenty of time and warning before deprecating features. Depending on your developer's platform, that can be six months or two years. For example, mobile apps take longer to rev than web apps.
Do not use the dot notation, like v1.2 for an API proxy version. This implies a granularity of versioning that doesn't work well with APIs.