坚持基于 Linux 消费的 Azure 函数的 CI/CD 部署

Question

I made an Azure Function (Python), hosted with a Linux Consumption plan. The App Engine is located into a dev ressource group. I would now like to be able to deploy it (and subsequent changes) to the staging and prod ressource groups. The documentation on the many differents ways to do it has got me confused, especially with the fact that most of the deployment methods (deployment slots...) are not available with the Linux Consumption plan and I have no use for the Premium one. I thought of setting up a version control but I cannot link my Azure Function to an Azure DevOps repo (Deploy Center is disabled, grey).

How would you do it? Ideally with Azure DevOps.

Thanks in advance

Answer 1

First of, you need to make sure that you have access to the subscription in question, with the resource groups and function apps.

Build
On DevOps, for the project containing the repository, go to Pipelines > Pipelines (highlighted with red).
In the top-right corner, you should be able to see and click "New pipeline". I'll be doing an "Azure Repos Git (YAML)" pipeline in this answer, so you might as well go along with. If you have any other particular preferences, then just make sure you change what needs to be changed accordingly. Our goal is basically just to publish an artifact from our build-process, which will in turn be consumed by a "Release pipeline".

Moving along, for the build pipeline, choosing "Azure Repos Git (YAML)" will prompt you to choose which repository in your project, that will 1) contain the YAML file we're about to create, and 2) have the source code available for the pipeline. Without going into too much detail, it is also possible to place all yaml-pipeline files into its own repository, and then include (via resources) the repositories containing the source code.

Next Step is to "Configure your pipeline". There is actually a "Python Function App to Linux on Azure" template available. However, it contains deployment stages as well, and I generally always put all deployment related into my "Release pipeline". For now, though, I went with the "Starter pipeline".
An online editor will actually pop up. Towards the top of the editro, you'll see the repository's name and a "azure-pipelines.yml". Click on the "azure-pipelines.yml" to rename the pipeline, as well as the name of the yaml-file, that'll end up in the repository's root.
I've put up a version of the aforementioned template, boiled down to what is necessary, and it's available here . Simply delete whatever is already in the "starter pipeline", and copy-paste the contents of the pastebin, into the pipeline.

When you save the pipeline, you probably want to put it into a different branch to begin with instead of your master branch (it will prompt you for it), and then create a PR. Accept the PR when the pipeline works (you can run the pipeline using your newly created branch). When the build pipeline successfully runs without errors, you should be able to see an artifact published, if you navigate to your successful run's overview (highlighted with red). You can click and examine the contents to check if they are as expected.

Release
Go to "Releases" (highlighted with green, first picture). From here, you should be able to see and click a "+ New"-button.

It will immediately prompt you to select what type of job you want. Just click "Empty job" to begin with.
First choose an artifact to consume. Click the "Add an artifact"-box to the left. Find the pipeline you just created from the drop-down list. You can configure the version to use (if you have certain preferences), and give the artifact an alias that can be used throughout the release pipeline.
Next is to setup your stages. You want 3 stages: a stage for development, a stage for staging, and lastly, a stage for production. Currently you should have a "Stage 1". If you hover above the stage, you can see a "+"-sign below the box. Click it to add a stage. Choose empty job again. Repeat this for the newly created stage box (hover, click +, add empty job).
You should now have something like this:

Let's start by configuring stage 1. Click the stage (the box itself), and name it "Development" or something of your preference. Then click the "1 job, 0 task"-link. Click the "Agent job"-box, and configure the agent job, as you see fit (make sure the agent downloads your artifact, it can be configured in the "Artifact download").
Next, click the "+"-sign on the agent job you just configured. From the prompt, use the search-bar to find "Azure Functions". Note, there are 3 jobs called this. You want the one that is just called "Azure Functions". Click and configure the newly created job. It should really be straight-forward here. Pick function app on linux and find your "development" function app from the list. The "Package or folder" should be something like $(System.DefaultWorkingDirectory)/**/*.zip by default, and it should suffice, unless you have done some customization to your build pipeline's artifact.
You should have something like this:

From the "Tasks"-dropdown (with the red warning circle), you can move to "Stage 2" (you'll of course rename this as you did with "Stage 1" to "Development"). Since you're not using slots, swapping is unfortunately not possible between 2 function apps, in two different resource groups - at least not by my knowledge. So you'll have to repeat the entire process from the "Development" stage, where you use the artifact to deploy to the function app in the staging resource group. The same goes for your last stage "Stage 3", where you deploy to your function app in your production resource group.

Staging and approval
What we've been waiting for, I imagine. From the picture with the stages overview, you can see that each stage has 2 attached "buttons" on each side of the box. When with a lightning and a user icon (left), and one with just a user icon. The one on the left is "pre-stage actions", while the on the right is "post-stage actions". In your scenario, you probably want to configure "pre-stage actions" for your "Stage 2"/"Staging" and for "Stage 3"/"Production". In both cases, I'd add "Pre-deployment approvals", like this:

You can add specific persons, or entire groups. It will require that someone then goes to the release pipeline overview, and then approves the next stage, before it will be deployed (or rather, the stage won't start before it has been approved).

Phew, that was a long one... I hope this cleared some of the confusion you have had, and that it works out for you.