您可以選擇要部署 API 的位置。舉例來說，您可以將修訂版本升級至正式環境，讓開發人員開始使用您的 API。同時，您可能正在本機或測試環境中疊代多個修訂版本，新增功能或微調政策。準備就緒後，您就可以將新修訂版本部署至正式環境，覆寫該環境中的現有修訂版本。使用這個方法，您在開發及測試新功能時，開發人員隨時都能使用 API 的正式修訂版本。
使用 Apigee API 編寫部署作業指令碼
Apigee 提供 RESTful API，可讓您將 API Proxy 部署和管理作業整合至貴機構的軟體開發生命週期 (SDLC)。舉例來說，為確保符合安全性、可靠性和一致性需求，Apigee API 的常見用途是編寫指令碼或程式碼，以程式輔助方式部署 API Proxy，並將其從一個環境升級至另一個環境，做為較大型自動化程序的一部分。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-08-21 (世界標準時間)。"],[[["\u003cp\u003eThis content details the API development lifecycle using Apigee and Apigee hybrid, focusing on developing, testing, and deploying API proxies.\u003c/p\u003e\n"],["\u003cp\u003eApigee supports both cloud-based development directly within its platform and local development using Apigee in Visual Studio Code (VS Code), enabling flexibility in the development process.\u003c/p\u003e\n"],["\u003cp\u003eAPI proxies in Apigee are versioned through revisions, allowing developers to deploy specific versions and revert to previous ones if necessary, and can be deployed to various environments for testing and production.\u003c/p\u003e\n"],["\u003cp\u003eApigee offers ready to use policies to program API behavior without requiring coding, and can also be expanded with custom scripts and code to add more management capabilities.\u003c/p\u003e\n"],["\u003cp\u003eApigee's RESTful API allows for scripting and automating the deployment and management of API proxies, facilitating integration into an organization's software development lifecycle (SDLC).\u003c/p\u003e\n"]]],[],null,["# API development lifecycle\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\n\nThe following sections summarize the API development lifecycle using Apigee.\n\nDeveloping API proxies\n----------------------\n\n\nApigee supports the following options for iterative API proxy development:\n\n- [Cloud development using Apigee](#cloud-development)\n- [Local development using Apigee in VS Code](#local-development)\n\n\nFor more information about API proxies, see [Understanding APIs and API proxies](/apigee/docs/api-platform/fundamentals/understanding-apis-and-api-proxies).\n\n### Cloud development using Apigee\n\n\nDevelop your API proxies using the API proxy editing and debugging tools provided with Apigee.\nAs you work on an API proxy, Apigee saves iterations of your configuration as *revisions*.\n\n\nWhen you deploy an API proxy, you choose a specific revision to deploy. Typically, you deploy the most recent revision, and,\nif necessary, revert to a previous revision. See [Deploying API proxies](#deploying-api-proxies).\n\n\nTo get started developing your API proxies using Apigee, see [Building a simple API proxy](/apigee/docs/api-platform/fundamentals/build-simple-api-proxy).\n\n### Local development using Apigee in VS Code\n\n| **Note** : This is a limited **preview release** of local development using Apigee in Visual Studio Code (VS Code). To enable and use the features described in this section, contact [Apigee Sales](https://cloud.google.com/contact/?direct=true&pre_product=).\n\n\nUse Apigee in Visual Studio Code (VS Code) to develop your API proxies and verify the functionality through unit and manual testing (for example,\nsend a request and view the results).\n\n\nAfter you complete your local validation, deploy your API proxy configurations as *archives* to your Apigee environments.\nSee [Deploying API proxies](#deploying-api-proxies).\n\n\nTo get started developing your API proxies locally using Apigee in VS Code, see [Building your first API proxy using Apigee in VS Code](/apigee/docs/api-platform/local-development/vscode/get-started).\n\nDeploying API proxies\n---------------------\n\n\nYou create **environments** in which to deploy API proxies. The distinction between different environments is arbitrary --- each environment is simply identified by a different set of network addresses (URLs). The goal is to provide you with a domain in which you can build and verify API proxies before the API is exposed to external developers. For more information, see [About environments and environment groups](https://cloud.google.com/apigee/docs/api-platform/fundamentals/environments-overview).\n\n\nBy deploying your APIs to multiple environments, you can segregate traffic between the API proxies that you are working on in a *test* environment, and those that are being accessed by external apps at runtime in a *production* environment.\n\n\nApigee supports the following deployment types in an environment:\n\nAdding policies\n---------------\n\nApigee enables you to program API behavior without writing any code, by using policies.\nA policy is like a module that implements a specific, limited management function. Policies are\ndesigned to let you add common types of management capabilities to an API easily and reliably.\nPolicies provide features like security, rate-limiting, transformation, and mediation\ncapabilities, saving you from having to code and maintain this functionality on your own. You\ncan also write custom scripts and code (such as JavaScript applications), that extend API proxy\nfunctionality and enable you to innovate on top of the basic management capabilities supported\nby Apigee policies. For more information about Apigee policies,\nsee [What's a policy?](/apigee/docs/api-platform/develop/policy-attachment-and-enforcement)\n\nApigee provides ready to use polices for various features such as traffic management, security,\nmediation, and extension policies. To view the complete list of policies available in\nApigee, see [Policy reference overview](/apigee/docs/api-platform/reference/policies/reference-overview-policy).\n\nPromoting to production\n-----------------------\n\n\nYou choose where to deploy an API. For instance, you can promote a revision to a production environment to allow developers to start\nworking with your API. At the same time, you may be iterating multiple revisions in a local or test environment, where you're adding\nfeatures or fine-tuning policies. Then, when you're ready, you can deploy the new revision to the production environment, overwriting the existing revision in that environment. Using this method, you can always have a live revision of your API available to developers while you're developing and testing new features.\n\n### Scripting deployment using the Apigee API\n\n\nApigee provides a RESTful API that enables you to integrate API proxy deployment and management\ninto your organization's software development lifecycle (SDLC). For example, to ensure that security,\nreliability, and consistency requirements are met, a common usage of the Apigee API is to write scripts or code that\nprogrammatically deploy API proxies and promote them from one environment to another, as part of a larger automated process.\n\n\nFor more information, see [Apigee API](/apigee/docs/reference/apis/apigee/rest).\n\n### Managing environment resources\n\n\nEnvironments provide segregation of data and resources. You can, for example, set up different caches in your `test` and `production`\nenvironments that can be accessed only by API proxies executing in that environment. Additionally, API keys that are issued in a test environment are not valid in a production environment, and vice-versa.\n\n\nFor additional control during promotion, it is recommended that you only iterate on API proxies in a test environment, and make as few changes as\nnecessary to API proxies deployed in a production environment.\n\n\nTo do so, you need to ensure that certain resources associated with each environment are configured in such a way that they can remain static in an API proxy configuration.\n\n- **Key value maps (KVMs)** : If scoped to the environment, you should ensure that naming conventions are used to enable API proxies to store data without requiring configuration changes during promotion. For more information, see [Using key value maps](/apigee/docs/api-platform/cache/key-value-maps).\n- **Target URLs** : It is common for API proxies to call different backend URLs during testing and production. You can use TargetServer configurations to create environment-independent TargetEndpoint configurations. For more information, see\n - [Load balancing across backend servers](/apigee/docs/api-platform/deploy/load-balancing-across-backend-servers) (Cloud development)\n - [Configuring the target servers](/apigee/docs/api-platform/local-development/vscode/deploy-environment#target-servers) (Local development)\n- **ServiceCallout targets** : Service callouts may use different targets depending on the environment, if, for example, a ServiceCallout in the test environment consumes a demo service. See [ServiceCallout policy](https://cloud.google.com/apigee/docs/api-platform/reference/policies/service-callout-policy).\n\n\nTo make API proxy configurations environment-independent, you can also use conditional statements.\nConditional statements built with the `environment.name` variable can be used to evaluate the\ncurrent environment before enforcing a policy or before routing to a URL on the backend. For more information,\nsee [Conditions with flow variables](/apigee/docs/api-platform/fundamentals/flow-variables-and-conditions)."]]
