Azure DevOps Change nuget.config in CI/CD process

Question

I'm currently working on a project which uses azure function apps, we also create a data access layers for each function app which are built as nuget packages and are then published to a private nuget feed. For the function apps, we have three separate environments, QA, Staging, and Production.

I want to create separate nuget feeds for each of these environments, so that changes are pushed to the appropriate feed rather than polluting one feed with potentially broken code. I am trying to determine the best way to update the nuget.config files in the function apps to point to the appropriate feed during the CI/CD process.

I've set up similar changes to PHP projects in the past, using a "replace in files between text" task in the build pipeline, but I'm wondering if this is the best approach or if there's a different way I should go about this. I've done quite a bit of googling to try and determine what the best way to do this is but have come up empty so far.

What's the best practice in a case like this?

Answer 1

I would like to expand on Ben Cottrell's comment, but present you with a fork in the road when it comes to implementing the build pipelines.

My instinct makes me question the need for a NuGet package for each data access layer. NuGet packages solve two main problems: code reuse and code versioning. If the data access layer is not reused by other components, then there is no need for a NuGet package to begin with. Embed the data access layer in the Azure function app. You can still provide interfaces along with concrete classes to promote testability. I would not consider the need to "version" code enough justification to create NuGet packages, which just complicates the build process. Version control, like Git or SVN should suffice for that, especially since you can configure releases in Azure DevOps.

Assuming you have a need to reuse code, I have another fork in the road. Azure function apps enable an event-driven architecture. Only one Azure function should have direct data access. Any data retrieval should be achieved using direct service calls. Mutation of data should be achieved using events. This reduces coupling between Azure functions, eliminating the need for most code reuse. This should allow you to embed the data access code in one Azure function, eliminating the NuGet package conundrum.

Finally we arrive at the last fork in the road — a legitimate, unavoidable need to reuse code across Azure functions. Part of the build pipeline should be running automated tests against these NuGet packages before code gets deployed. This is what Ben is alluding to in his comment on your question:

My preferred approach would be for testing in ephemeral environments using an entirely separate Azure account away from the fixed environments...

Automated tests can include both unit and integration tests. This should catch most defects in these packages before a new version of an Azure function gets deployed. After deploying the Azure function, you should run yet another suite of integration tests. Failures at this point should be caused by misconfigurations or environmental issues rather than logic defects. You should be able to use the Azure release pipeline to roll back the Azure function to it's last known good state, which should prevent downstream failures in the meantime.

There will always be integration problems. You want to avoid troubleshooting environmental, configuration, and logic defects in the same environment. Catching logic defects in their own build pipeline simplifies cases where integration problems occur. That is the position you want to be in.