2

This probably a weird situation. All the posts I have looked on this topic is the other way around where they want to check this "remove additional files" but in my case I want to have it unchecked but that is giving problems at later stages. To give some context around

We are building around 15 to 20 Azure functions as a wrapper API on top of Dynamics CRM APIs. So the 2 options evaluated are

a) Create each function in it's own function app - this gives us maintenance issue (20 URLs for Dev, SIT,UAT, Stage, Prod, Training is a considerable mess to tackle for along with their managed identities, app registrations etc etc) ,another key reason not to consider this approach is the consumption plan's warm up issues. It is unlikely that all these functions are heavily used but some of them are.

b) the second option, keeping all functions under 1 big function app. This is most preferred way for us as it will take care of most of the above issues. However, the problem with this we observed is - if we have to deploy 1 function, we have to wait for all the functions to be tested and approved and then deploy all functions even if the requirement is to deploy only one function. This is totally a No-No from architectural point of view.

So, we adapted a hybrid approach - in Visual studio, we still maintain multiple function app projects but during the deployment all these functions will be deployed in to Single Function App by using Web Deploy and Unchecking "Remove additional files in target"

The problem now

this is all worked very well for us during our POC, however now when we started deploying using pipe lines in to Staging slot it is becoming problem for us. Let's say when we first deployed function 1 to staging, swap it to production - the stage now has 0 functions and prod has 1 function. Then when we deploy the 2nd azure function, stage now has only 2nd function and if we swap it with production now, the production will get only 2nd azure function and we miss the 1st Azure function totally from production.

enter image description here Logically it sounds correct to me but wondering if any one can give any suggestions for a work around for this.

Plz let me know if any further details required.

Srikanth Alluri
  • 133
  • 1
  • 12
  • Can you sidestep these problems by deploying all N functions to an App Service plan instead of consumption plans? I've never actually tried it. I assume they'd all then have the same base URL. – Rob Reagan Aug 13 '20 at 00:22
  • I don't think, you have a solution for this. The second option is the appropriate one. Even in a normal Web API / Web App world, if there is a change in one controller, you end up deploying the complete .dll file. that's how it works even here. I'm not sure what arch problem you see here? Are you worried about slowness for all other functions if you are deploying a single function? – Prawin Aug 13 '20 at 05:01
  • @rob, the reason to opt for consumption plan is it's dynamic allocation of resources.. this is exactly what we need. It is presumed that at certain point of times in the day the load would be heavy. And I don't know about same URL for all apps part of it let me check once – Srikanth Alluri Aug 13 '20 at 07:41
  • @Prawin, let's say we are done with some key functions Dev, how we can handle the deployment of these APIs all the way to prod while the other functions Dev is happening? Is there any way except to label the code and do take from label I can't think of any solution? Even the labelling is also not a reliable solution I blv. It's considered as crime in our place if we deployed the code to prod with out test even though it is not used..:,-) – Srikanth Alluri Aug 13 '20 at 07:47
  • 1
    @SrikanthAlluri, It's more of branching strategy. You can have a separate main branches for each of the environments. ex: master --> for prod, staging --> for QA and develop --> for development. I assume you would already have them. – Prawin Aug 13 '20 at 09:05
  • Thanks @Prawin, that's an interesting approach. We are using branches but feature wise branches and at the end will be merged to Master when they are ready to ship to next env. I didn't know this branching strategy per environment... interesting to know.. – Srikanth Alluri Aug 13 '20 at 09:34
  • 1
    Yeah. Your strategy (option2 in your question) with All functions in one Function App along with the usage of Slots doesn;t have any flaws. So, if you change your branching strategy you are good to go! – Prawin Aug 13 '20 at 10:44

0 Answers0