We are developing a robotics product that requires quite a few manual tests in every release cycle and we want to automate the management of these tests.
We envision a process with these steps:
One or more test plans are assigned to one or more testers by new stage in our release pipeline using the Azure DevOps REST API (with the respective build artifact related to the pipeline)
Manual testing takes place
A deployment gate keeps the release in a testing stage until all tests have passed (solvable with a function app that parses the response from: GET https://dev.azure.com/{organization}/{project}/_apis/test/runs?buildUri={buildUri}
Is it possible to assign testers (to test a specific build) using the REST API https://dev.azure.com/{organization}/{project}/_apis/test?
Is it possible to assign testers (to test a specific build) using the
REST API
The answer is yes. You can use Test Point - Update rest api to achieve this.
PATCH https://dev.azure.com/{organization}/{project}/_apis/testplan/Plans/{planId}/Suites/{suiteId}/TestPoint?api-version=6.0-preview.2
Update Test Points. This is used to Reset test point to active, update the outcome of a test point or update the tester of a test point.
Related
Is this possible?
We’ve got a monorepo that holds all that slns for our given project. The product requires these services to function.
Here’s my question
Is it possible to get a pipeline that will build everything but only release changes?
Eg.
Let’s days I’ve got a
Submission api
User management api
MVC app.
If I make changes to the MVC app, then the pipeline needs to build everything but only indicate the the MVC app needs releasing
Same if I made a change to user management
What if I make a change to all 3 in a single PR? I’d want to build and release everything.
I have a tool aztr that summarizes the Azure Build/Release pipeline test results. A recent requirement has come up to save the incoming variable information and the summary information for consumption outside of the tool (say a csv file).
Now on the Release pipelines side the Release API provides all the details about the variables passed into the Release. I want the same functionality to be available on the Build side as well but the Build API, does not provide that functionality. Is there a different API, I need to use to get the variables passed into the build?
Thank you for your responses.
We could list the custom build variables via this API
GET https://dev.azure.com/{organization}/{project}/_apis/build/definitions/{definitionId}?api-version=6.0
In addition, they are some predefined variables in the variable and they are DevOps Services system variables, we cannot list them via this api.
Result:
I need to refactor a .Net Web API, I'm considering moving to serverless and I'm trying to understand the best option to migrate the code to Azure Functions.
As far as I understand the correct approach to reduce costs and cold start time is to split the API: it is much better to have many small web api than a single one with all methods. Small api consume less memory and cold start quicker.
Having more Functions in the same Project does not resolve the problem as they would be all deployed in the same Function App so one dll, high memory, slow cold start.
So I should create several Azure Function Projects and deploy each of them in a different Function App.
If all the above is correct we finally got to the problem:
I would structure the code and the repo so that I have one Solution containing several Azure Function Projects. How can I have a CI/CD (Azure DevOps) so that when I push the repo ONLY the Azure Function Projects updated/modified/new are deployed? I need to deploy only the modified Azure Function Projects so not to have all the Function Apps (also the ones whose code is unchanged) goes cold.
This is less important but I'd also need to have one URL for all APIs, so https://myapi.azurewebsites.net/api/Function1, https://myapi.azurewebsites.net/api/Function2, etc and not https://myapi1.azurewebsites.net/api/Function1, https://myapi2.azurewebsites.net/api/Function1, etc. Is this possible using the above structure?
You need to have multiple CI/CD pipelines with trigger limited only to specific folder:
trigger:
paths:
include:
- function-a/*
exclude:
- '*'
for this you will get pipeline triggered only if changes are done in function-a folder. To limit a work needed to develop pipelines you should consider using templates. You can find more info about this here:
Template types & usage
Build templates on Azure DevOps - this is my ow blog
In this way you will avoid repeating yourself.
EDIT
To unify your API you can use Azure Functions Proxies
With this feature, you can specify endpoints on your function app that
are implemented by another resource. You can use these proxies to
break a large API into multiple function apps (as in a microservice
architecture), while still presenting a single API surface for
clients.
we implemented UI tests for a web application using cypress and they are executed on a release pipeline in Azure DevOps.
We need to link the ui tests and test results with our test cases defined in the test plans.
For linking the ui tests with the test cases we retrieve the automated test results using the API-URL:
_apis/tcm/ResultsByRelease?releaseId={}&publishContext=CI&%24top=20000
...once we retrieve the results, I can link the test cases in the test plan to automated tests using the Microsoft.TeamFoundation.WorkItemTracking.WebApi (Method: UpdateWorkItemAsync). Our UI tests have the ID of the test case as attribute, so I can use that to link them.
We can't change the outcome of the test cases based on the retrieved results. I’ve found there is the concept of test point, but I could not find what it is for. In the REST API documentation this the resource has the outcome of test cases. According to the documentation, test point cannot be created only updated based on run, if a understood correctly.
Any ideas, how we can change the outcome of the test cases?
Thanks,
P
You can try getting the test points with below api.
https://learn.microsoft.com/en-us/rest/api/azure/devops/testplan/test%20point/get%20points%20list?view=azure-devops-rest-5.1
You can then iterate the test points results from above step and to get each test point id. Then try updating the outcome of each test point with api here
If your project is developed with visualstudio. You can associate these test results and test case via visual studio. And the outcome would be automatically updated when the test cases completed in release pipeline.
To associate tests with test cases in test plan, check here.
To run tests from test plan, check here
At the moment if I update my API so that I include a query parameter on one of my endpoints, I also need to update the ARM template that is used during the Azure DevOps release pipeline to update APIM.
Is there a way to automatically update the ARM template json based on the updated action methods?
The end goal is to have APIM reflect the changes I made in my action methods, without me having to update things in multiple places (ie. action method AND ARM template).
Although this doesn't directly answer your question, I'd like to invite you to explore using Azure API Management DevOps Resource Kit instead, an official tool maintained by the APIM team.