API プロキシと共有フローは、リビジョンに基づいて管理（作成、更新、デプロイ）されます。リビジョンには連続番号が割り当てられるので、新たな変更を加えて新リビジョンとしてそれを保存できます。また、以前のリビジョンの API プロキシまたは共有フローをデプロイすることで、加えた変更を元に戻すこともできます。リビジョンのベースパスの異なる場合を除き、1 つの環境にデプロイされる API プロキシまたは共有フローは、どの時点においても常に 1 つのリビジョンのみが存在します。
API プロキシと共有フローはリビジョンによって管理されますが、既存のリビジョンになんらかの変更を加えた場合、過去の変更は単純に上書きされるので、ロールバックする手段はありません。
既存のリビジョンで API プロキシが削除された、または変更がデプロイされたときは、以前のコードは復元できません。この API プロキシに、Apigee の外部のソース コントロール管理（SCM）システムで管理されていない Java、JavaScript、または Python コードが含まれている場合、膨大な開発の作業と労力がすべて失われる可能性があります。
例 2: 特定の仮想ホストを使用する API プロキシの識別
ある仮想ホスト上の証明書が有効期限切れ間近であり、この仮想ホストを更新しなければならないとします。多数の API プロキシが存在する場合、この仮想ホストをどの API プロキシが使用しているのか、テスト目的で特定することは容易ではありません。Apigee 外部の SCM システムで各 API プロキシが管理されていれば、リポジトリを簡単に検索できます。
[[["わかりやすい","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 UTC。"],[[["\u003cp\u003eApigee resources, such as API proxies, shared flows, and KVMs, can only be modified by authorized users through the Apigee UI, APIs, or related tools, and not through developer portals or other means.\u003c/p\u003e\n"],["\u003cp\u003eWhile API proxies and shared flows are managed through revisions, modifications to existing revisions overwrite old changes without a rollback option, and other resources simply update the current data without historical retention.\u003c/p\u003e\n"],["\u003cp\u003eApigee's Audits feature provides information on who performed operations and when, but it does not store older data if resources are updated or deleted, making a separate source control necessary.\u003c/p\u003e\n"],["\u003cp\u003eManaging all Apigee resources, including API proxies and shared flows, in a source control system (SCM) is crucial for data recovery and to avoid potential loss of development work, API request failures, and difficulties in identifying resource interdependencies.\u003c/p\u003e\n"],["\u003cp\u003eThe recommended best practice is to utilize an SCM, often coupled with a CI/CD pipeline, for managing API proxies, shared flows, and other Apigee resources, utilizing Apigee APIs to initially get and subsequently update configurations.\u003c/p\u003e\n"]]],[],null,["*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/no-source-control) documentation.*\n\nApigee provides many different types of resources and each of them serve a different\npurpose. There are certain resources that can be configured (i.e., created, updated, and/or\ndeleted) only through the Apigee UI, Apigee APIs, or tools that use APIs, and by\nusers with the prerequisite roles and permissions. For example, only org admins belonging to a\nspecific organization can configure these resources. That means, these resources cannot be\nconfigured by end users through developer portals, nor by any other means. These resources\ninclude:\n\n- API proxies\n- Shared flows\n- API products\n- Caches\n- KVMs\n- Keystores and truststores\n- Virtual hosts\n- Target servers\n- Resource files\n\nWhile these resources do have restricted access, if any modifications are made to them even by\nthe authorized users, then the historic data simply gets overwritten with the new data. This is\ndue to the fact that these resources are stored in Apigee only as per their current state.\nThe main exceptions to this rule are API proxies and shared flows.\n\nAPI Proxies and Shared Flows under Revision Control\n\nAPI proxies and shared flows are managed -- in other words, created, updated and deployed --\nthrough revisions. Revisions are sequentially numbered, which enables you to add new changes and\nsave it as a new revision or revert a change by deploying a previous revision of the API\nproxy/shared flow. At any point in time, there can be only one revision of an API proxy/shared\nflow deployed in an environment unless the revisions have a different base path.\n\nAlthough the API proxies and shared flows are managed through revisions, if any modifications\nare made to an existing revision, there is no way to roll back since the old changes are simply\noverwritten.\n\nAudits and History\n\nApigee provides the Audits feature that\ncan be helpful in troubleshooting scenarios. These features enable you\nto view information like who performed specific operations (create, read, update, delete, deploy,\nand undeploy) and when the operations were performed on the Apigee resources. However, if any update\nor delete operations are performed on any of the Apigee resources, the audits cannot provide you the\nolder data.\n\nAntipattern\n\nManaging the Apigee resources (listed above) directly through Apigee UI or APIs without\nusing source control system\n\nThere's a misconception that Apigee will be able to restore resources to their previous\nstate following modifications or deletes. However, Apigee does not provide restoration of\nresources to their previous state. Therefore, it is the user's responsibility to ensure that all\nthe data related to Apigee resources is managed through source control management, so that old data\ncan be restored back quickly in case of accidental deletion or situations where any change needs\nto be rolled back. This is particularly important for production environments where this data is\nrequired for runtime traffic.\n\nLet's explain this with the help of a few examples and the kind of impact that can be caused if\nthe data in not managed through a source control system and is modified/deleted knowingly or\nunknowingly:\n\nExample 1: Deletion or modification of API proxy\n\nWhen an API proxy is deleted, or a change is deployed on an existing revision, the previous code\nwon't be recoverable. If the API proxy contains Java, JavaScript, or Python code that is\nnot managed in a source control management (SCM) system outside Apigee, a lot of development work\nand effort could be lost.\n\nExample 2: Determination of API proxies using specific virtual hosts\n\nA certificate on a virtual host is expiring and that virtual host needs updating. Identifying\nwhich API proxies use that virtual host for testing purposes may be difficult if there are many\nAPI proxies. If the API proxies are managed in an SCM system outside Apigee, then it would be easy\nto search the repository.\n\nExample 3: Deletion of keystore/truststore\n\nIf a keystore/truststore that is used by a virtual host or target server configuration is\ndeleted, it will not be possible to restore it back unless the configuration details of the\nkeystore/truststore, including certificates and/or private keys, are stored in source control.\n\nImpact\n\n- If any of the Apigee resources are deleted, then it's not possible to recover the resource and its contents from Apigee.\n- API requests may fail with unexpected errors leading to outage until the resource is restored back to its previous state.\n- It is difficult to search for inter-dependencies between API proxies and other resources in Apigee.\n\nBest Practice\n\n- Use any standard SCM coupled with a continuous integration and continuous deployment (CICD) pipeline for managing API proxies and shared flows.\n- Use any standard SCM for managing the other Apigee resources, including API products, caches, KVMs, target servers, virtual hosts, and keystores.\n - If there are any existing Apigee resources, then use Apigee APIs to get the configuration details for them as a JSON/XML payload and store them in source control management.\n - Manage any new updates to these resources in source control management.\n - If there's a need to create new Apigee resources or update existing resources, then use the appropriate JSON/XML payload stored in source control management and update the configuration in Apigee using APIs.\n\n\\* Encrypted KVMs cannot be exported in plain text from the API. It is the user's responsibility\nto keep a record of what values are put into encrypted KVMs.\n\nFurther reading\n\n- [Source Control for API Proxy Development](https://community.apigee.com/articles/34868/source-control-for-api-proxy-development.html)\n- [Guide to implementing CI on Apigee](https://community.apigee.com/articles/35173/continuous-integration-for-api-proxies.html)\n- [Maven Deploy Plugin for API\n Proxies](https://github.com/apigee/apigee-deploy-maven-plugin)\n- [Maven Config Plugin to manage\n Resources](https://github.com/apigee/apigee-config-maven-plugin)\n- [Apigee APIs (for automating\n backups)](https://apidocs.apigee.com/management/apis)"]]
