We have Release Management for VS 2013 running for all our builds and releases on-premise. We are not ready to publish our systems to Azure Cloud yet, but would like to migrate our source-code to Azure DevOps Services in the mean time. We are also not ready to publish via Azure DevOps Pipelines to agents installed on our servers. Is it possible to have your source-code in Azure DevOps Repos, build the source using either Microsoft-hosted or self-hosted agents and then have Release Management for VS2013 release them to our environments?
I am able to do normal published via Azure DevOps Services totally to Azure Cloud, and even to on-premises with distributed agents running on servers, with test applications, but this would mean I have to recreate every build definitions, we have created, again in Azure DevOps, and also that we would bypass our Release Management server.
We would like to stick with Release Manager for now for releases, but want to migrate our source-code and work-items into Azure DevOps and build source in Azure DevOps Pipelines.
It's unlikely to work. Release Management Server 2013 only supported XAML builds. 2015 had support for JSON/visual designer builds, but the support wasn't particularly robust. I'm not even 100% sure that RM Server can communicate with a modern Azure DevOps instance. You're using a 6 year old tool that's been deprecated and unsupported for several years; you're not going to find a lot of options to keep it working properly with modern, supported tools.
There is a tool that can extract PowerShell deployment scripts from RM Server that can be used (with some degree of rework) in an Azure DevOps pipeline, but it's not a perfect solution. And I say that as the primary developer of that tool.
Related
With Azure Data Factory, mostly used with Azure Repo & for CI/CD, Azure DevOps is used.
Currently I am using Azure Data Factory, where the AzureRepo not configured and Azure DevOps is not to be used as DevOps need to be build around a framework which included GitLab, Concourse-CI , Terraform and other OpenSource tools. All the JSONs are exported & available on GitLab. From there Azure Data Factory need to be created on every check-in from the ARMs/ADF-JSONs.
Let me know if anyone has came across such scenarios and is there a way to publish Azure Data Factory without using AzureDevOps & AzureRepo.
Yes there is. The JSONs being exported are standard Azure Resource Manager (ARM) templates. These templates can be deployed from outside of Azure DevOps.
Here is how to deploy ARM templates using GitHub Actions
Another option would be to use Powershell New-AzResourceGroupDeployment -ResourceGroupName <resource-group-name> -TemplateFile <path-to-template>
Basically anything on how to deploy ARM templates to Azure will allow for Data Factory pipelines and infrastructure to be deployed.
Recently we have upgraded our TFS server to the latest 2019 version.
As the Admin, I was trying to install the downloaded Test Manager extension just like we did in TFS2017 and TFS2018.
However, I was unable to install it even with full access and TFS test plan subscription.
This extension does not support the version of the Server you are
currently using. See Works With for supported Server versions.
What should I do, am I missing something? Why it not work with TFS2019? Appreciate your help.
This is the expected behavior when you try to install the extension in Azure DevOps Server 2019. You do not need to install extra Test Manger for Azure DevOps Server 2019.
The official link is also clearly: This extension does not support the version of the Server you are currently using. See Works With for supported Server versions.
It only work Works with
Team Foundation Server 2017
Team Foundation Server 2018
Note:
Manual testers do not need this extension and can execute tests as a
Basic user in an Azure DevOps organization/collection. Read more on
this here.
This extension is available out-of-the-box in Azure DevOps Services and Azure DevOps Server (2019 onwards) and hence doesn't need to be acquired for them.
We strongly recommend you to use Azure Test Plans or the Test hub in Azure DevOps Service/Server (a fully featured Test management solution) over Microsoft Test Manager for all your test management requirements. There will be no new versions of Microsoft Test Manager.Microsoft Test Manager 2017 (which shipped with Microsoft Visual Studio 2017) is the last version.
More details please take a look at our official tutorial here.
Besides, to use Azure Test Plans in Azure DevOps service you need some License requirements
Azure Test Plans uses an access level called Basic + Test Plans, which is available from Azure DevOps.
For the Manual testing permissions and access suggest refer this link: https://learn.microsoft.com/en-us/azure/devops/test/manual-test-permissions?view=azure-devops#license-requirements
Hope this helps.
As mentiond in the Extension page:
This extension is available out-of-the-box in Azure DevOps Services and Azure DevOps Server (2019 onwards) and hence doesn't need to be acquired for them.
So you don't to install it, it's exist :) just go to the "Test Pans" tab in the left menu (maybe you need give permissions in the settings).
I have web applications that we build using build scripts and deploy as the last step of those build scripts, if everything builds and unit tests pass. We deploy to staging area.
With the new Release management functionality in TFS, Should I move the Deploy task from the build definition to the Release area? The Release Definition seems to only be able to copy files versus a build script can update an application running in IIS.
I honestly at this point do not see the need for the Release Management in TFS.
The Release Management is used to be an independent tool of TFS.
It has been integrated into Azure Pipelines and Team Foundation Server (TFS)as web-based version in TFS 2015 Update 2 and above or Azure Pipelines.
Release Management not only be able to copy files versus a build script but also as a Continuous Delivery (CD). It is a process by which code is built, tested, and deployed to one or more test and production environments. Deploying and testing in multiple environments drives quality.
CI(build) systems produce the deployable artifacts including infrastructure and apps. Automated release processes consume these artifacts to release new versions and fixes to existing systems. Monitoring and alerting systems run continually to drive visibility into the entire CD process. The Release service in TFS helps you set up and manage CD for your applications.
As for the difference on Release Management vs deploy task at the end of build pipeline, you could also take a look at this similar question: TFS Release Management vs build deploy task at the end
We migrated from TFS 2015 to Azure DevOps. The XAML builds also ported over to Azure. But we need to migrate them to Azure build pipelines as the XAML builds are still running on On premises TFS Server. We have hundreds of builds and cant manually create new pipeline for each build one at a time. Can some one help please?
XAML builds are still supported with Azure DevOps Service (with some limitations), see official response from Microsoft, in my answer here.
We're currently in the process of migrating from TFS to Azure DevOps and we're not planning on upgrading any of our legacy XAML builds (we're creating vNext builds going forward), as they were successfully migrated into Azure.
I figured out a way ( I am not done yet)..
we can call the api and export the build defs into json files
Use the Json files to port them over to the new Build defs. (Porting involves creating new builds programatically and using Azure Api .. + the data from Json files we just exported).
With the new TFS 2008 and the upcoming TFS 2010, are Web Deployment Projects depreciated? We used them in our 2005 projects because we needed the multiple distribution of files across a cluster but now that TeamBuild does that, and we are just now moving out of VSS to TFS 2008, I was wondering if there was an argument to be made on removing the WDPs and just go with a strict TeamBuild solution.
We use CruiseControl.NET to build currently but was looking at moving to one solution instead of just using the CC.NET plugin to build from TFS Source Control.
Typically speaking, in a team environment you want to use Web Application Projects anyway which lends itself to xcopy style deployments. We have dozens of applications that are under active development using this method.
When using Team Build, I highly recommend you get a copy of TFS Deployer which enables you to utilize powershell scripts that are hooked into the Build Quality settings.
Our setup is CI (leveraging TFS 2008) with TFS Deployer. A successful check in causes a build and deployment to our dev servers. When we change the build quality to "In Staging" TFS Deployer moves the projects to our staging servers. When our infrastructure team changes it to "In Production" in deploys to our web farms.
Simple, to the point