Multiple development tracks for single proxy

We have a scenario where a single proxy may have 10 or 20 resources. As per the development and deployment model of apigee we can have a single foot print of code active in a deployed revision on edge. At first I thought of using different branches on SCM, but again at the time of deployment only one revision will be active, which will be overwritten by next revision if someone else tries to deploy and test his branch changes.

Can someone please give some pointers on parallel development tracks on single proxy? What should be approach for unit testing and delivery of individual resources?

1 1 239
1 REPLY 1

Not applicable

Hi @Mohammed Zuber here are a couple of suggestions. Also check out this post on Apigee Tools & Plugins by @Anil Sagar, there might be some further ideas you can take from seeing the tools and plugins.

1. Use multiple environments:

  • You can have different revisions of the same proxy deployed into different environments at the same time
  • workflow with three environments (dev, test & prod) could be:
    • dev is shared, each change in SCM is saved as a new revision in the dev environment in your org. Developers keep track of the mapping of SCM changes to proxy revisions and collaborate on which revision to deploy.
    • after some iterations, test candidate is defined and saved as new revision, deployed into test environment for wider/more thorough testing.
    • after testing completes, new revision is saved for prod and deployed
  • This model requires you to also use something like Maven (see Apigee Deploy Maven Plugin and Apigee Config Maven Plugin for some ideas) to control deployments and create an additional config layer where you define environment specific variables that get applied into the proxy code when new revisions are saved.
  • There is a scalability issue because you can't have too many separate environments, and each separate environment will require separate configs making it progressively more complicated.

2. Use API Proxy Chaining and/or Reusable Shared Flows:

  • This would require you to break your single API proxy into more than one.
  • Each then becomes separately deployable and could allow some amount of parallel tracks.

I know in both cases this isn't the same as having truly parallel development and both would require some changes in order to implement. Hopefully others will be able to offer additional options. There may also be some combination of the above two that would give sufficient permutations to enable multiple parallel dev streams without getting too complicated.

If this has helped answer your question, please click the Accept link or let us know where we might be able to provide more help.