Deploying a pre-existing revision without importing the bundle

[andmig-ilty]

Maybe it's a stupid question but reading the documentation I wasn't able to find a clear answer.

Does the plugin support the deployment operation of an already existing proxy/revision on a new environment within the same target apigee organization?

At the moment we were only able to deploy on two or more environments but importing many time the same bundle thus generating several (useless) revisions.

If this is not supported by the plugin, I guess the only alternative is implement this via rest APIs.

Thanks, Andrea

[ssvaidyanathan]

@andmig-ilty - not at all !!!

The main purpose of the plugin is to package the source code and deploy that package so the source of truth is always your code repo.

Yes - for now, invoking the REST API is the only option.

I am not sure if you are asking this for Apigee Edge or Apigee X/hybrid. If it's for Apigee Edge (v1.x), I would still do different revisions for each environment so that you don't push changes to environments by mistake. For example, let's say Revision 5 is deployed to stage and prod in your prod org. By making a change to the same revision, you end up pushing that to prod too.

This is not possible with Apigee X/ hybrid as the bundles once deployed are immutable and requires a new revision for any change you make.

So do you think this will be a good feature for Apigee X/hybrid?

[andmig-ilty]

Thanks for you feedback!

We are currently on Edge but planning to migrate to Hybrid in the next 6-to-9 months.

Our current workflow starts from the developer working in a "lab" organization and then promoting to others organization, downloading the bundle and importing in the next organization (the "environments" are identical within each organization).

We are now planning to consolidate three (non-production) organizations in a single one while keeping the promotion behaviour through progressive deployment to a sequence of environments within the same organizations. That's the general idea.

The scenario you mentioned is definitivelly unpleasant but in our case the impact is quite low since this "intra-organization" promotion is limited to the very first stages if our promotion pipeline while QA and Production will still be in separate organizations where every deploy will necessary generate a new revision.

Thanks for you advices anyway and I very welcome the new approach on this from Apigee hybrid. Is this going to make the plugin support the "deployment only" scenario eventually?

[ssvaidyanathan]

For hybrid - if you think it will be a good feature, let me know. I am asking my field team too on what they think. If I get a resounding "yes", then I will try and include this feature to the plugin (only for hybrid/Apigee X)

[andmig-ilty]

@ssvaidyanathan yes, this is definitivelly a feature that we would love to have nativelly in the plugin and avoid dealing with custom API-based integrations!

[ssvaidyanathan]

Hi @andmig-ilty - We have released this feature and now its available for Apigee X/hybrid (as of v2.4.0)

[andrea-migliaccio]

That's great to hear @ssvaidyanathan !

Now I just need to adapt my release process to use the new goal and get rid of the rest API invocation, making it much more clear and easy to maintain.

BTW, in the last year we successfully migrated to Apigee Hybrid :-)

[ssvaidyanathan]

Thats awesome! Sorry it took a while but we started seeing more interest. So just went ahead and added this feature