API 프록시를 배포할 환경을 만듭니다. 서로 다른 환경 간의 차이점은 임의적입니다. 각 환경은 단순히 서로 다른 네트워크 주소(URL)로 식별됩니다. 목표는 API가 외부 개발자에게 노출되기 전에 API 프록시를 빌드하고 확인할 수 있는 도메인을 제공하는 것입니다. 자세한 내용은 환경 및 환경 그룹 정보를 참조하세요.
API를 여러 환경에 배포하면 테스트 환경에서 작업 중인 API 프록시 간 트래픽과 프로덕션 환경에서 런타임 시 외부 앱에서 액세스되는 트래픽을 구분할 수 있습니다.
Apigee는 환경에서 다음 배포 유형을 지원합니다.
유형
설명
프록시
Apigee 개발 환경에서 API 프록시를 개발 및 테스트한 후 이를 Apigee 통합 테스트 및 프로덕션 환경에 배포합니다. API 프록시 배포를 참조하세요.
Apigee를 사용하면 코드를 작성하지 않고 정책을 사용하여 API 동작을 프로그래밍할 수 있습니다.
정책은 특정적으로 제한된 관리 기능을 구현하는 모듈과 같습니다. 정책을 사용하면 API에 일반적인 관리 기능을 쉽게 안정적으로 추가할 수 있습니다.
정책은 보안, 비율 제한, 변환, 중재와 같은 기능을 제공하므로 이러한 기능을 직접 코딩하고 유지할 필요가 없습니다. 또한 커스텀 스크립트와 코드(예: 자바스크립트 애플리케이션)를 작성하여 API 프록시 기능을 확장하고 Apigee 정책에서 지원하는 기본 관리 기능을 기반으로 혁신할 수 있습니다. Apigee 정책에 대한 자세한 내용은 정책이란 무엇인가요?를 참조하세요.
Apigee는 트래픽 관리, 보안, 중재, 확장 정책과 같은 여러 기능을 위해 즉시 사용 가능한 정책을 제공합니다. Apigee에서 사용 가능한 전체 정책 목록을 보려면 정책 참조 개요를 참조하세요.
프로덕션으로 승격
API를 배포할 위치를 선택합니다. 예를 들어 개발자가 API 작업을 시작할 수 있도록 버전을 프로덕션 환경으로 승격할 수 있습니다. 동시에 로컬 또는 테스트 환경에서 여러 버전을 반복할 수 있습니다. 여기에서 기능을 추가하거나 정책을 세부 조정할 수 있습니다. 그런 다음 준비가 되면 새 버전을 프로덕션 환경에 배포하여 해당 환경의 기존 버전을 덮어쓸 수 있습니다. 이 방법을 사용하면 새 기능을 개발 및 테스트할 때 항상 개발자에게 API의 라이브 버전을 제공할 수 있습니다.
Apigee API를 사용하여 배포 스크립팅
Apigee는 API 프록시 배포 및 관리를 조직의 소프트웨어 개발 수명 주기(SDLC)에 통합할 수 있는 RESTful API를 제공합니다. 예를 들어 보안, 안정성, 일관성 요구사항을 충족하기 위해 Apigee API는 프로그래매틱 방식으로 API 프록시를 배포하고 대규모 자동화 프로세스의 일환으로 한 환경에서 다른 환경으로 승격시키는 스크립트 또는 코드를 작성하는 용도로 흔히 쓰입니다.
환경은 데이터와 리소스의 분리를 제공합니다. 예를 들어 해당 환경에서 실행되는 API 프록시에서만 액세스할 수 있는 test 및 production 환경에서 다른 캐시를 설정할 수 있습니다. 또한 테스트 환경에서 발급되는 API 키는 프로덕션 환경에서 유효하지 않으며 그 반대의 경우도 마찬가지입니다.
승격 중에 제어를 강화하려면 테스트 환경에서 API 프록시를 반복하고 프로덕션 환경에 배포된 API 프록시를 가능한 변경하지 않는 것이 좋습니다.
이렇게 하려면 각 환경과 연결된 특정 리소스가 API 프록시 구성에서 정적 상태를 유지할 수 있도록 구성되어 있는지 확인해야 합니다.
키 값 맵(KVM): 환경으로 범위를 지정하는 경우 프로모션 도중 구성을 변경하지 않고 API 프록시를 통해 데이터를 저장할 수 있도록 이름 지정 규칙을 사용해야 합니다. 자세한 내용은 키 값 맵 사용을 참조하세요.
대상 URL: 테스트 및 프로덕션 중에 API 프록시가 다른 백엔드 URL을 호출하는 것이 일반적입니다. TargetServer 구성을 사용하여 환경에 독립적인 TargetEndpoint 구성을 만들 수 있습니다. 자세한 내용은 다음을 참조하세요.
ServiceCallout 대상: 서비스 콜아웃은 환경에 따라 다른 대상을 사용할 수 있습니다. 예를 들어 테스트 환경의 ServiceCallout은 데모 서비스를 사용합니다. ServiceCallout 정책을 참조하세요.
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)."]]
