I need help to understand better how to create complete CI/CD with Azure Devops for APim. Ok I already has explored the tools and read docs:
https://github.com/Azure/azure-api-management-devops-resource-kit
But I still have questions, my scenario:
APim dev instance with APi and operations created and others settings, as well APim prod instance created but empty.
I ran the extract tool and got the templates (not all), still need the Master (linked templates), and on this point seat my doubt, I already have 2 repos too(dev and prod).
How can I create the Master template, and how my changes from dev environment will be automatically applied to prod?
I didn't used the policyXMLBaseUrl parameters not sure what Path insert there, although seems #miaojiang inserted a folder from azure storage.
After some search and tries I deployed API's and Operations from an environment to another, but we still don't have a full automated scenario, where I make a change in a instance and that is automatically available.Is necessary to edit policies and definitions directly on the repositories or run the extract tool again.
Related
Forgive me for asking a stupid question. I am from IT Infrastructure background & have been asked to create CI/CD pipelines based on my recent learnings on DevOps.
We have couple of applications whose source code is currently in TFS 2013 & those apps are written in ASP.NET C# language. Now, requirement is to migrate the source code from TFS to Azure Repos (Azure DevOps services) & further create a CI/CD pipeline.
Now for demo purposes, customer is asking us to do the deployment (i.e. Release pipeline) on a test server which is a plain windows 2012 OS without any SQL & IIS for both of these applications. Is that possible & how could we achieve the results to confirm release pipeline is funcioning properly?
In my opinion, it wont work as there is no application infra/configuration done for those applications on that plain test server. I guess we actually need a ready dev/stage environment which is replica of production to do the testing of release pipeline for those applications. Am I correct?
Just need expert advise for confirmation so I communicate the same to customer.
Azure DevOps Pipelines use an agent to perform the deployments. You can run the agent entirely in the cloud when deploying to Azure resources. You can also install an agent locally. Follow this link and scroll down to read about self-hosted agents. This is how you can deploy to your test instance from the pipeline.
Now, what you deploy there may require additional software be installed. You say it's an application in C#. Cool. Now, what's it do? Is it a windows program? Then just having the server there, with an agent installed, is all you need. Is it a web program? Then, yeah, it's going to need an IIS (or whatever) instance available somewhere to deploy to. Is it a database program? Then, yeah, it's going to need a database instance to deploy to. There's nothing magical about having a VM or a machine somewhere. All the same rules have to apply. There has to be an OS, drives, memory, and yes, supporting services depending on the needs of the application.
However, using a local machine instead of a hosted one, that works fine. Just follow the instructions in the link above.
Traditionally we have to deliver our applications on the test and pre-production platforms one by one (usually by hand using setups). Applications like the front end javascript SPA UI are linked to backend services and their delivery sometimes goes together.
Each service and each application has its own git repository. (we are using on premise TFS 2018 for now )
Then when it is necessary to go into production, we deliver all of the front end services and applications at once that have been validated at once.
We would like to automate our process but we don't know if Azure Devops is suitable.
From what I understand with Azure Devops, we can make an independent artifact for each microservice and each front end application. We can also deliver them independently.
It seems to me that Azure Devops by default allows you to manage the delivery cycle for a particular microservice but not for an assembly making up a complete system, right?
But is it possible to deliver a set of projects each with a particular version? For that, must all of our projects be in the same solution or the same git repository?
Yes, you can use multiple artifacts from different sources (build artifacts, repositories, package feeds, github, docker hub, Azure Container Registry, ++) within a single pipeline or release definition. That's true for both the classic release definitions and the modern multi-stage pipeline implementation.
For example you can define a pipeline or release definition that consumes a front-end web app from a build artifact sourced from RepoA, a back-end service artifact consumed from a container registry originally from RepoB, and say a script library in the form of a Git artifact from RepoC. From there you could deploy each of those artifacts together, or in parallel stages, in sequence, partially, with approvals, conditionally, etc, all from the same pipeline.
The full configuration as code YAML multi-stage pipelines are still in preview, so there are some workflow orchestrations that are a little tougher to implement. But there is enough feature parity with the classic release definitions that I would default to using multi-stage for any net new needs.
My company creates a lot of projects in Azure DevOps, and they all have the same structure -- same members, same permissions. Each project has different Git repositories within it, but that's the only thing (other than the name) that differs between them. It would be helpful to have a template so that everything is set up correctly each time we need a new one.
I don't see a way to do this through the web interface. I have the sense that I could probably do it with a script, but I don't know where to begin with that (including which tool to use). Where should I start?
It looks like there is now a way to do this without the Azure DevOps CLI (as long as your project that you want to template is one of the supported types (Agile, Scrum and Basic)). There is a tool available here that will step you through the process.
There is also an excellent blog post here that gives you an overview.
Yes, you can accomplish most of the configuration by script. For the beginning you might take a look at the Azure Devops CLI, which allows you to perform several actions on Azure Devops, like:
Create projects, Users and configure security
Create repositories, pipelines and set branch permissions
Create and manage work items
...
I am new to VSTS. I am deploying Azure services using PowerShell using VSTS Release management. Now, On dev environment, everything goes well. I want to deploy to Clients Production Subscription. Client won't allow access to Production subscription to the dev team. In that Case, I have Cloned Dev environment pipeline and named it to Prod.
I am using the config file for each environment.
The client doesn't want to check-in Config file of Prod environment. My Question is How to populate Config file in Prod pipeline? First I thought of to copy Config file directly in Drop Folder ( in VSTS agent VM) but if Developer also has access to a private agent then the config is still in Developers' hand. We can't use multiple agents somehow.
Is there any specific way or VSTS security where we set some access permission?
Is there any location where we can put the file and use it in VSTS?
If somebody doesn't understand question Please ask me I will explain in detail.
We have a similar situation where Developers are not allowed to access prod. To solve the problem, we've created a Dev and Prod project. Developers setup the production project initially, but are denied access entirely now using Azure DevOps security groups. Only our Ops group has access to prod, including the repo that the config files are stored in.
To get things from Dev to Prod, we have a third project for our build engineering team that has scripts to promote artifacts from Dev to Prod. This team is neither Dev nor Ops and the promotion pipelines that we use to promote artifacts require approvals.
Looks like all you need is to create a new git repo and add the file that you would like to use. After that, just add the git repo in any release where you want to use it by adding a new artifact, selecting the git option under "Source type", and selecting the name of your repo in the "Source (repository)" dropdown.
You can use Secure files to manage the config file.
I'm using Visual Studio Team Services and I'm trying to set up Release Management to allow automated deployments for our Azure Web App to multiple environments. I would like the same source to be deployed to each environment, but with modified configuration settings.
I was hoping that I could create a single Build for my application, and then modify the configuration at deployment time for each environment. I'm aware that this can be done for appSettings and connectionStrings (either through Tokenization, or even managing those settings via the Azure portal), but I'd like to be able to make more general changes to the web.config file. For example, I want to be able to:
Update 'simple' settings such as appSettings/connectionStrings
Update multiple attributes on elements (like httpErrors)
Insert or rewrite sections of the config file itself (for example to add IIS rewrite rules, or to remove unwanted HTTP handlers for production)
Currently we achieve this by using config file transformations and separate publish profiles for each environment (manual deployment). I can't see a way to re-use this if I want a single release pipeline.
I'm hoping someone can help point me in the right direction. I'm also happy to accept alternative solutions - ultimately I just want to be able to deploy the same source (e.g. from the same commit in source control) to multiple environments, with different configuration, while keeping some kind of flow from dev, to test, to eventually production.
You can use Tokenization Task to update the files base on the environment variables.
More similar extensions: Replace Tokens and Colin's ALM Corner Build & Release Tools.