Deploying to On-Premises Servers with VSTS

Play Deploying to On-Premises Servers with VSTS
Sign in to queue

Description

Damian is joined by Abel Wang to walk through using Visual Studio Team Services (VSTS) to deploy applications to on-premises servers. As Cloud Developer Advocates, we focus so much on deploying to Azure - especially Platform as a Service (Paas) - but not every app is on the cloud! Thankfully, VSTS has a solution.

Tag:

devops

Embed

Download

The Discussion

  • User profile image
    Andux

    Great intro, very informative.

    Does this work from on-prem build servers?

  • User profile image
    Damovisa

    Are you talking about using Release Management in TFS rather than VSTS? If so - it will work if you're on a recent-enough version (the docs say TFS 2018).

    If you're talking about whether you can do this from VSTS/TFS Build (rather than Release), the answer is no. Deployments should really be handled with Release Management (or another tool if you like) rather than Build - separating the creation of an artifact and actually deploying and promoting it between environments is really important in a good DevOps strategy. There's some good information about why on the 12 Factor App page.

  • User profile image
    Joey Eng

    I'm not seeing the SQL Server Database deploy task in VSTS. Is it just using SqlPackage.exe behind the scenes? If so can you pass SqlPackage.exe parameters like exclude users?

  • User profile image
    Joey Eng

    Whoops, ignore my last question. I was looking at build definition tasks instead of release. And I see the arguments section to pass parameters to SqlPackage.exe.

  • User profile image
    Doug

    Both "Deploy SQL DACPAC" and "Deploy IIS App" are deprecated now. I am looking for something to use in a production environment. Do replacements exist?

  • User profile image
    Damovisa

    @Doug: These tasks are now only available for Deployment Groups - i.e. you need an agent on the machine to do the deployment. The advantage is no potentially tricky remote connection issues! You can find info here: 

  • User profile image
    flozen

    @Damovisa: Does this work, if both web server and database server sitting on the same machine and no tags created.  B'cas, i currently have the issue, deploying this way,  it does perfectly, for the webapp.  But, it executes the sql task but, nothing is deployed to database server and it says, deployment completed successfully.

  • User profile image
    cenko

    The on-prem database server is owned and controlled by the vendor whose software application our company currently uses. We only have access to a database in the server. Since an agent on the machine is needed to deploy this will not work for us. What would be an alternative?

  • User profile image
    Rob

    I'm new to TFS and VSTS but have a question about what access does VSTS need to the on-prem server? How does the agent on the local server know that a deployment is waiting for it? Does VSTS need to communicate directly to the on-prem server or is it strictly the on-prem server reaching out to the VSTS site? In other words, are any firewall ports needed to be opened FROM the VSTS site to the on-prem server? Cause that ain't gonna happen! LOL Thanks!

  • User profile image
    AbelSquid​Head

    To go on prem you have to install an agent behind your firewall. The only requirement is that the agent needs to be able to reach out to Azure DevOps (formerly known as VSTS) and the agent needs to be able to reach whatever machine it is deploying to. You can even install the agent on the machine you want to deploy to, but that is not required.

  • User profile image
    sandipmstc
    Thank you for the video. It really breaks new comers disbelief that DevOps and CI/CD pipelines are only made for Azure like cloud environment deployment only!
    Definitely I will try to deploy our legacy web apps to on premises IIS servers and see how it goes and we can reduce the pain of manual deployment of my entire team. Additionally, I hope this on prem deployment would work well for my client network having multiple servers like Dev, UAT, QA and PROD behind a firewall, and hopefully should work for my tens of apps deployments on number of servers!
  • User profile image
    Dev

    Is there anyway that we can use one agent installed in a server in a private network, and to be able to coordinate deployments to multiple servers in the same network (line-of-sight)..? we have about 150 clients (and growing), and there will be up to 3 environments/servers per client (dev, test and/or prod). Our applications are hosted in client's private networks which we do no have direct access to (behind a firewall). All is well except the costing part, just want a bit of clarification on this.

    Current cost per self-hosted Agent = $20

    If an agent is required per server (deployment target),

    Agent Cost Per Month * Number of Private Networks * Number of Servers * 12 Months
    20*150*3*12 = $108,000


    If an agent can deploy to multiple servers in a private network,

    Agent Cost Per Month * Number of Private Networks * 12 Months
    20*150*12 = $36,000

    Is the cheaper option achievable..? please excuse if the question is too basic.

  • User profile image
    Damovisa
    @Dev: There are a couple of options.

    You could deploy from one machine inside the firewall, however you'd most likely need to build a lot of your own plumbing and scripts, and you wouldn't be using Deployment Groups - simply a self-hosted agent that knows about other machines it needs to run scripts on. You could use network file copying and Powershell remoting or similar to do the actual work. Obviously there's a bit of work there that Deployment Groups manages for you.

    However, your cost of $20 per self-hosted agent isn't _quite_ accurate. It's not priced per provisioned agent - rather per parallel job. So you could conceivably deploy all 450 agents, but only pay for 10 parallel jobs if you're happy to deploy 10 at a time. Or even a single parallel job if you are happy to deploy one at a time.

    Check out https://docs.microsoft.com/en-us/azure/devops/pipelines/release/deployment-groups/howto-provision-deployment-group-agents?view=azure-devops&WT.mc_id=devopslab-c9-dabrady for more details on provisioning the agents, and https://azure.microsoft.com/en-us/pricing/details/devops/azure-devops-services/?WT.mc_id=devopslab-c9-dabrady for more pricing details.

    Also, we're _just about_ to release another series of updated on-prem deployment episodes, so keep an eye out for those! They'll start to drop this week :)

    I hope that helps!
    Damian
  • User profile image
    Dev

    @Damovisa Thank you for the quick feedback. Glad to hear your response and to know that I was wrong about the cost being based on per agent.

    Looking forward to the upcoming episodes.

Add Your 2 Cents