{"id":29386,"date":"2017-04-10T11:22:41","date_gmt":"2017-04-10T18:22:41","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudioalm\/?p=29386"},"modified":"2019-02-14T15:55:38","modified_gmt":"2019-02-14T23:55:38","slug":"deploying-to-on-premises-environments-with-visual-studio-team-services-or-team-foundation-server","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/devops\/deploying-to-on-premises-environments-with-visual-studio-team-services-or-team-foundation-server\/","title":{"rendered":"Deploying to On-Premises Environments with Visual Studio Team Services or Team Foundation Server"},"content":{"rendered":"

I hear this particular question frequently as a reason teams are concerned about adopting Visual Studio Team Services when their applications still run on-premises. \u00a0The good news is that it is typically a quick walkthrough on how build & deployment pipelines work. \u00a0I want to give a big thanks to Sachi Williamson<\/a> from Northwest Cadence<\/a> for the guest blog post today!<\/em> — Ed Blankenship<\/strong><\/p><\/blockquote>\n

Your company\u2019s apps may not be hosted in the cloud yet for various reasons, such as their configuration, dependencies, or network requirements. That\u2019s okay!\u00a0\u00a0 What many people don\u2019t know is that you can still take advantage of great tools like Visual Studio Team Services<\/a> or Team Foundation Server<\/a> to manage your deployments.\u00a0 You\u2019re probably asking yourself, \u201chow can a cloud SaaS service like Team Services be able to deploy to our on-premises environments?\u201d\u00a0 That\u2019s what we will explore today.<\/p>\n

For the core service, your team has a choice to either use Visual Studio Team Services as a completely hosted SaaS service by Microsoft or you can run it on-premises by setting up Team Foundation Server (TFS). \u00a0When you build and deploy your apps through Team Services or TFS, you use agents to run the build and deployment tasks. \u00a0Team Services allows you to take advantage of hosted agents<\/a> for running your build and deployment pipelines. \u00a0The hosted agents are perfect for many scenarios including your automated build process. \u00a0However, when you want to deploy on-premises, you will want to run the deployment steps from agents that have access to your on-premises environment. \u00a0This alternative scenario is enabled through leveraging private agents<\/a>.<\/p>\n

How does an agent communicate with Team Services or TFS?<\/strong><\/h2>\n

<\/strong>The agent communicates with Team Services or TFS to determine which pipeline tasks it needs to run in addition to reporting log entries and job status. This communication is always initiated by the agent. All the messages from the agent to Team Services or TFS happen over HTTP or HTTPS, depending on how you configure the agent. This polling model allows the agent to be configured in different topologies as shown below. \u00a0In the Team Services example, you’ll notice we included an additional scenario where you are running a “private agent” in a cloud-hosted virtual machine as well.<\/p>\n

\"deployonprem1\"<\/p>\n

How does an agent communicate with target servers for deployment?<\/strong><\/h2>\n

<\/strong>When you use the agent to deploy artifacts to a target set of servers, the agent\u00a0must have “line of sight” connectivity to those servers. The hosted agents pool, by default, has connectivity to from the Azure cloud to anything else running in the Azure cloud or exposed to the public Internet. \u00a0For example, you may have an Azure Website that a hosted agent is able to deploy to through endpoints exposed through the Azure App Service platform<\/a>.<\/p>\n

If your on-premises environments do not have connectivity to the hosted pool (which is typically the case because of\u00a0firewalls), you\u00a0will want to setup and\u00a0configure a private agent on servers hosted in your on-premises network. The private agents need to have\u00a0connectivity to the target on-premises environments where you want to deploy, and also have access to the Internet to connect to Team Services, as shown in the following diagram. \u00a0If you are using Team Foundation Server, you will connect your private agent to your Team Foundation Server.<\/p>\n

\"deployonprem2\"<\/p>\n

To read more on communication and deployment to target servers, check out this documentation<\/a>.<\/p>\n

How do I deploy from Team Services\u00a0or TFS to on-premises environments?<\/strong><\/h2>\n

Build and deployment agents can run on many platforms. \u00a0There are a few walkthroughs available for setting up your agent on various operating systems:<\/p>\n