API プロキシをデプロイする環境を作成します。異なる環境の区別は任意です。各環境は、単に異なるネットワーク アドレス（URL）のセットで識別します。その目的は、API を外部のデベロッパーに公開する前に、API プロキシを構築して検証できるドメインを提供することです。詳細については、環境と環境グループについてをご覧ください。
API を複数の環境にデプロイすることで、テスト環境で作業中の API プロキシのトラフィックと、本番環境での実行時に外部アプリによってアクセスされる API プロキシのトラフィックを分離できます。
Apigee では、環境で次のデプロイタイプがサポートされています。
タイプ
説明
プロキシ
Apigee 開発環境で API プロキシを開発してテストし、Apigee Integration のテスト環境と本番環境にデプロイします。API プロキシのデプロイをご覧ください。
API をデプロイする場所を選択します。たとえば、あるリビジョンを本番環境に昇格させて、デベロッパーが API の使用を開始できるようにします。同時に、ローカル環境やテスト環境で複数のリビジョンを反復処理して、機能の追加や、ポリシーの微調整を行えます。その後、準備が整ったら、新しいリビジョンを本番環境にデプロイし、その環境の既存のリビジョンを上書きできます。この方式を使用すると、新しい機能の開発やテストを行いながら、デベロッパーが API のライブ リビジョンをいつでも利用できます。
Apigee API を使用したデプロイのスクリプト作成
Apigee には、API プロキシのデプロイと管理を組織のソフトウェア開発ライフサイクル（SDLC）に統合できる RESTful API が用意されています。たとえば、Apigee API の一般的な用途は、大規模な自動化プロセスの一部としてセキュリティ、信頼性、整合性の要件を確実に満たすために、API プロキシをプログラムでデプロイし、ある環境から別の環境に昇格するスクリプトやコードを記述することです。
API プロキシ構成が環境に依存しないようにするために、条件文を使用することもできます。environment.name 変数を使用して作成した条件ステートメントを使用すると、ポリシーの適用前か、バックエンドで URL にルーティングする前に現在の環境を評価できます。詳細については、フロー変数での条件をご覧ください。
[[["わかりやすい","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-18 UTC。"],[[["\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)."]]
