Stuck with CI/CD deploy of Linux Consumption based Azure Function - azure

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

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.

Related

Looking at modifying a pipeline build

I am working for a company that develops a lot of apps and we use Azure devops portal for all of our pipeline releases etc.
So, the general flow is that a developer will create a branch to do the development on and change the code on that branch. They would like to deploy that branch before it is merged back into the development line from a pipeline, rather than from visual studio, which they currently do. So, it's about giving the developer to the option to choose which branch to deploy from.
Has anyone done something similar or point me in the right direction to how I could go about this?
When creating the release, currently there is no build-in feature to choose which branch to deploy from, the release pipeline works with the corresponding source Artifacts configuration.
A good approach for your scenario is referring to the build id on your build pipeline (instead of release pipeline).
When running the build pipeline, you could choose the target branch and record the build id for this run.
In your release pipeline, you could check whether the source Artifacts is from your target branch by checking the build id.

Azure Devops - YAML Release Pipelines - How to select a specific artefact from a build pipeline using a dropdown list

So, recently I set about migrating our Azure Devops Classic Release pipeline to a YAML based one.
What I'm struggling to reproduce is the ability you have with a Classic Release pipeline to select a specific artefact from an associated build pipeline using a dropdown list.
The only way I've found to allow a user to specify a specific artefact is via a parameter, but the definition of dropdown lists is only possible if you know all of the values that will be in the list.
This link is the closest thing I've found that resolves the issue, but even this doesn't allow the specification of a dropdown: https://www.huuhka.net/runtime-artifact-selection-in-azure-pipelines-yaml/
Anyone know how to do this, or even if it is possible?
Ok, so I didn't quite answer the question I posed, but I found an answer that solves the issue I have.
The problem I had is that I want a user to be able to select a specific build at release time.
This is poorly documented and it was a surprise when I saw it working.
In your release pipeline specify a resource:
resources:
pipelines:
- pipeline: YourBuildPipelineReference
source: "Your Build Pipeline Name"
Now when you come to run your pipeline you see the following:
Click Resources and you are now taken to list where you can select a specific build.
Didn't see this before, but I figure lots of people will need this.

How to create bug or Notification in only one task/Job when other task/Job failed in an Agent in devops in Release Pipe line

I have an pipeline which will have few task mentioned in the image. I'm creating a bug work item when a particular task failed which is working fine using logic app.
Now my problem is I don't want to add every time new task for bug creation after each deployment task mentioned in the image.
Is there any way I can create only one bug work item based on failure in any of the task in the pipeline. may be in the last or somewhere..?
Not sure why you had to go the Logic app route as there is an option to do this with Azure Pipelines itself out of the box.
Navigate to {your pipeline} > Options as shown below:
If the build pipeline fails, you can automatically create a work item to track getting the problem fixed. You can specify the work item type. You can also select if you want to assign the work item to the requestor. For example, if this is a CI build, and a team member checks in some code that breaks the build, then the work item is assigned to that person.
Additional Fields: You can also set the value of other work item fields. For example:
Field Value
------- -------
System.Title Build $(Build.BuildNumber) failed
System.Reason Build failure
Check Build Options for more details.
UPDATE:
Doing this for Release Pipelines is not supported as an out of the box feature as of today. However, there are extensions available in the Visual Studio marketplace that can be used as alternatives until it is supported.
Here are two such extensions:
Create Bug on Release failure
Create Work Item
Another idea with PowerShell tasks is discussed here.

Azure Pipeline Check is any builds are running in different azure pipeline task

So to give you a bit of context we have a service which has been split into two different services ie one for the read and one for the write side operations. The read side is called ProductStore and the write side is called ProductCatalog. The issue were facing was down the write side as the load tests create 100 products in the write side resource web app and then they are transferred to the read side for the load test to then read x number of times. If a build is launched in the product catalog because something new was merged to master then this will cause issues in the product store pipeline if it gets run concurrently.
The question I want to ask is there a way in the ProductStore yaml file to directly query via a specified azure task or via an AzurePowershell script to check if a build is currently running in the ProductCatalog pipeline.
The second part of this would be to loop/wait until that pipeline has successfully finished before resuming the product store pipeline.
Hope this is clear as I'm not sure how to best ask this question as I'm very new to the DevOps pipelines flow but this would massively help if there was a good way of checking this sort of thing.
As a workaround , you can set Pipeline completion trigger in ProductStore pipeline.
To trigger a pipeline upon the completion of another, specify the triggering pipeline as a pipeline resource.
Or configure build completion triggers in the UI, choose Triggers from the settings menu, and navigate to the YAML pane.

Azure functions - deploy by project in single repo?

We are building a set of serverless functions in Azure, but having difficulty deciding how to structure our source (Azure GIT) and DevOps to support them.
I am thinking of a single GIT repo, with all function apps housed independently within projects. We may have a lot of these function apps, we see great value in small code segments to do utility type of work, and I don't want dozens and dozens of independent repos just because of DevOps deployments. Is there a way to have a unique build and release process for each project, not the repo entirely? We aren't clear how this can be done and searches have come up empty on this. I thought it was possible to have unique build YAMLs per project across many projects in a single repo - but unclear how to implement the DevOps build and release pipleines to support this approach - ie; only a single function gets updated and we need to deploy - any guidance if this is possible and how to approach it would be great.
I haven't done this myself, but I'm in a similar situation where I'd like to have multiple functions (and other stuff) in a single Git repo for simplicity, but only build/deploy them as needed when they change. It looks like you can have multiple pipelines on a single repo with a different YAML file for each pipeline. The steps are documented in this link, and summarized below
In Azure DevOps, create a new Pipeline.
For the "Where is your code?" page, at the bottom choose the Use the classic editor option.
Select your source repo and branch.
On the "Select a template" screen, choose the YAML option at the top. Hit Apply.
There is a YAML file path field where you can specify the path and name of your YAML file for the pipeline.
You may want to set the pipeline to run manually if you don't want a build each time there's a commit to the repo.
EDIT There may be an easier way to do this now. If you go through the New Pipeline wizard, select your source location, on the Configure tab, at the bottom you can choose the Existing Azure Pipelines YAML file option. This lets you select a custom YAML file directly.

Resources