Source Control Strategy for APIGEE - API Proxies, Shared flows and other configuration parameters

[navc88]

Hi,

We are planning for developing a complete solution for CICD for APIGEE and we started with the Source code management and Repository Creation.

I was referring to : https://community.apigee.com/articles/34868/source-control-for-api-proxy-development.html.

• I didnt understand whether we need to create SCM project based on each version of the API Proxy?
• How do we go ahead with the shared flows? and configurations source control?

What we thought was having the Repo per API Proxy and maintain all revisions. And we will have a common SCM Repo for Shared flows and one Repo for all Configurations?

@Nagashree B Can you please tell me how we should proceed with the Repo creation and folder structure to be precise ?

And also if there is any good way where we can do revision control for the resources?

Is it the right path we are following?

Thanks,

Naveen

[ssvaidyanathan · Accepted solution]

HI @Naveen Chalageri

This is a great question. The recommendation is to use single repo for a proxy version. For example, if you have an API called "/v1/foo", have a repo called "Foo-v1". Similarly when you have newer versions coming up, you create new repos like "Foo-v2" and so on. With this you get complete control of who gets access to the repo and also work on your pipeline, automation, etc. It also in the future helps you with retiring/deprecating APIs. The other important aspect is to make changes to the APIs without impacting the others and getting complete audit on the changes being done using your SCM tool.

For Shared flow - since they are used across different proxies, I recommend them to be a different repo altogether. For example if you have SF for Security - have a repo called "SF-Security" and use that. SF will have its own pipeline

For Configurations, I recommend having them in the same repo as the proxy/sharedflow. You can use a resources directory and put all your configurations under that folder. If you are using the Maven plugin, you can refer to this sample to get an idea of how this plugin allows you to organize the configurations and use that in your pipeline.

There are configurations that needs to be pushed before the API proxy is deployed like Cache, Target Server, etc and there are some configured after the deployment like API Products, App, etc. All that can be controlled by your pipeline.

I have a sample repo that has the setup (using Jenkinsfile). You can try it out and let me know. Has an example of pushing some configurations (based on env) before deploying the API Proxy. You can enhance it according to your requirements. This repo uses Apigee Maven plugins for deployment and configurations.