How to manage different API revisions & deploy required changes in production

[meenakshisundar]

Consider the following

1. We have 10 API proxies for one customer & each proxy have more than one API in it, example "API proxy A" contains 10 APIs in it & another "API proxy B" contains 3 APIs in it & so on.
2. Always customer speak in terms of each API & not as "API proxy A" (or) "API proxy B" that contain many API in it.

Its difficult to manage different API proxy revisions & deploy required changes in production on demand, I will try to explain the situation by the following scenario

1. "API proxy A" have revision 1, 2, 3....20 & contains 10 APIs in it.
2. Revision 20 of "API proxy A" is live & same is deployed in all three dev, acp & prd
3. Now customer ask for change in one of the API inside "API proxy A", let say its API #1
4. We make the required changes and deployed the revision "21" in dev & acp
5. Meanwhile customer again asks for change in another API inside the "API proxy A", lets say its API #2
6. We make the required changes and deployed the revision "22" in dev & acp
7. And now the customer ask to release the changes for API #2 in production, i.e. revision "22"
8. Later the customer ask to release the changes for API #1 in production, i.e. revision "21", that doesn't have changes of API #2, which is in revision "22"
9. If we deploy revision "21", it will not have revision "22", how to manage this kind of scenarios.

Could you please let me know if there are any best practice to manage above mentioned situation / scenarios?

Regards,
Meenakshi Sundar.

[hartmann]

Hello,

I think this question encompasses a larger Apigee SDLC/lifecycle best practice set more than anything else. With that, I would recommend the following:

• We had a lunch and learn series where we more or less covered a fair amount of the above (local code development/testing/promotion strategies) in the video linked, which I would recommend reviewing: https://www.googlecloudcommunity.com/gc/Cloud-Events/Spec-Driven-Development-for-Apigee-A-fully-auto...
• The second item I would like to highlight is API versioning (and utilizing API Products to help streamline this process), which could in theory help mitigate this issue (given you can have v1 and v2s of these different API sets - all available via different routes). You could create separate proxies for your versions, which provides isolation and ease of use/access from a rollout POV (think metrics, monitoring, etc).

Hope this helps, if you have any questions and/or concerns on the above please let me know!

[AlexET]

Hi @meenakshisundar, we hope @hartmann's response was helpful!

If so, please consider marking it as the accepted solution. Thanks to Matt for the answer 😉

For more insights, check out our latest articles here and join our weekly office hours, Thursdays at 4:00 PM CET | Register here 🔗. We cover in-depth topics on Apigee and Google Cloud Application Integration.