Deploy to Remote Server using Visual Studio Online - azure-devops

How does one deploy their code to a remote server using Visual Studio Online after a build completes?
My Google skills apparently are lacking today as I am not finding information on this anywhere.

I use release management which you get with VSO. If you download the release manager client for visual studio you can create a release pipeline with tge vNext template that lets you deploy to and number of environments remotely. This is called Agent-less deployment and will have a migration path to the new Release capability in TFS 2015 (and VSO when it hits)

Related

Azure pipelines self hosted agent - should there be separate users for building and deploying?

We want to use azure pipelines to deploy application on on-premise virtual machines. We are trying to see if we should use self hosted agents in azure so that we can try to manage access to private network. The tech stack is Microsoft based so we will install visual studio enterprise (for build and code coverage).
What are the best practices in setting up the self hosted agent?
Should there be a specific build user which is linked to visual studio license on the server?
Should there be a specific deploy user that has access on the on premise servers to copy artifacts like IIS websites?
Should there be a specific build user which is linked to visual studio license on the server?
No, you can check that here: https://visualstudio.microsoft.com/wp-content/uploads/2020/03/Visual-Studio-Licensing-Whitepaper-Mar-2020.pdf
Using Visual Studio on the Build Server
If you have one or more
licensed users of Visual Studio Enterprise Subscription, Visual Studio
Professional Subscription, or any Visual Studio cloud subscription
then you may also install the Visual Studio software as part of Azure
DevOps Server 2019 Build Services. This way, you do not need to
purchase a Visual Studio license to cover the running of Visual Studio
on the build server for each person whose actions initiate a build.
Should there be a specific deploy user that has access on the on
premise servers to copy artifacts like IIS websites?
Basically, yes. This user has to have corresponding permissions on target servers. However, you can use tasks that define users like Windows Machine File Copy task and PowerShell on Target Machines task.

Can you queue a Microsoft Visual Studio Team Foundation Server build remotely with powershell?

Given Microsoft Visual Studio Team Foundation Server 2015 (on premises), is it possible to interact with the build and release process remotely with powershell?
For instance, we have CI builds in place with various triggers...e.g. a working branch is merged to a feature branch will kick off a build. If I am working on a one off branch that is not part of the trigger set, can I queue a build with a script that I execute on my machine? Can I do things with the results of that build...e.g. queue the release that is created as a result of the build.
yes you can via the TFS Rest API.
I implemented the following Task with Powershell: https://marketplace.visualstudio.com/items?itemName=benjhuser.tfs-extensions-build-tasks
You can have a look at the source as well.
You can find the references to the API on msdn:
https://www.visualstudio.com/en-us/docs/integrate/api/build/overview
Regards

does #opshub allow one VSTS (previously Visual Studio Online) to another VSTS project

It seems #opshub allows migration from on-premise TFS to another Visual Studio Team Services account? Is there tool available to migrate source code from one Visual Studio Team Services account to another
While the Free version of OpsHub Visual Studio Migration Utility (OVSMU) only supports on-prem TFS to VSTS migration. The Commercial version of the tool supports all variations of migration (including TFS to TFS, VSTS to VSTS and VSTS to TFS) along with many more features.

How to execute shell deployment script on Azure Virtual Machine from on premises TFS 2015 release management server?

How to execute power shell deployment script on Azure Virtual Machine from on premises TFS 2015 release management server?
FYI: AD integration has been already setup for organization, currently office 365 is getting used.
This article provides detailed steps:
https://www.visualstudio.com/en-us/docs/release/previous-version/deploy-continuously-to-azure
Before you start, you'll need:
TFS.
A team project.
Azure VMs.
An Azure storage account.
Release Management for Visual Studio extension. To install in Visual Studio, go to Tools, Extensions and Updates, and search for Release Management for Visual Studio.
A deployment script.

Visual Studio and Release Manager

I have been playing around with Visual Studio and Microsoft Release Manager. I have found a couple of behaviors I wasn't expecting and I was hoping someone might be able to confirm these (in case I'm getting the wrong end of the stick).
My goal is to:
Host my code in Visual Studio Online.
Deploy said code to on-premise or Azure hosted VM, using deployment agents.
My first attempt; using the Release Manager service provided as part of Visual Studio Online. However I found that I wasn't able to connect to Release Manager Online with agents deployed on-premise (or in Azure VMs).
I later found this text at https://www.visualstudio.com/en-us/get-started/release/manage-your-release-vs
You have the following options for managing your releases:
Using Release Management as a service on Visual Studio Online: You
need a Visual Studio Online account. You cannot use Chef and you can
deploy only to vNext environments based on Azure IaaS services
Using an on-premises server: You need to install Release Management
Server; do that here.
This seems to suggest that Visual Studio Online Release Manager cannot use agents - is this correct?
Assuming that is correct, my second attempt was installing Release Manager on-premises (so to speak, it is actually in an Azure VM).
I installed the latest RM versions (server, client, agent) from https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs#d-release-management. Specifically, Release Management for Visual Studio 2013 with Update 4 (12.0.31101.0).
However I found that I was unable to connect the on-premise Release Manager to Visual Studio Online. The error message stating that I must supply the user name in 'domain\username' format - which won't match the online 'username#domain.com' format.
This seems to suggest that an on-premise installation of Release Manager cannot connect to Visual Studio Online - is this correct?
Thanks,
Okay, there are a few pieces of the puzzle here:
The Release Management client has to be on Update 4 (or later, when RM 2015 comes out later this year).
If you're using Visual Studio Online, on-prem Release Management cannot talk to it. It's a weird limitation, but there it is. You can hook the RM client up to RM Service in VSO, but that's it.
RM Service in VSO does not support deployment agents. It only supports "vNext" release templates, which operate off of PowerShell or DSC scripts to perform deployments.
Agents are, sadly, quickly becoming deprecated in favor of what's termed "agentless" or "vNext" deployments. Microsoft is currently working on totally revamping the Release Management piece, and the next version (which will be released in TFS 2015 Update 1) will not support agents at all.
If you want to use an on-prem RM server with VSO, you have to use RM without the TFS integration. It's still possible to get the bulk of the continuous delivery functionality, it just requires jumping through a few more hoops.
You'll have to set your components up as "builds externally" and use an on-prem build server
Your RM deployment agents in Azure (obviously) have to be able to talk to your RM server. This could require all sorts of firewall shenanigans, but that's a conversation to have with your networking folks.
If you want to do continuous delivery (where a build triggers a release), you'll have to look at the ReleaseManagementBuild.exe file (which is part of the RM client). This tool is responsible for launching releases as part of the build. The "Release" build process templates assume TFS integration, but the ReleaseManagementBuild.exe application has a "package" mode, where you can specify a UNC path to release. This gets you around not having direct TFS integration. It's possible to hack up the build process template a bit to take advantage of this.