In TFS 2017 Update 2, NOT the online TFS, how do I use Release Management/Build agents in a production environment without installing Visual Studio on the build box? Alternative best practices are welcome!
My TFS is in a controlled development environment with a different, untrusted domain from production. Installing Visual Studio on agent machines is not a problem here (needed for vstest, visualstudio, et al agent capabilities).
I can configure my production agents to work with TFS as described here: https://realalm.com/2016/11/25/tfs-2017-build-agent-in-untrusted-domain/
However, I am not permitted to load Visual Studio itself on any production servers. We are trying to use the Release Management and Continuous Deployment capabilities of TFS. However, I don't see how to get the agent capabilities into production as required by the agents.
I thought perhaps to have a workflow that builds/tests in our dev/test/qa environments, drops the files to a location, and then the production agent simply pulls the files and deploys them. But this seems to defeat the idempotency of compiled code and introduces potential for the files to be modified between environments. Also, the production build/release wouldn't have the associated build and test result artifacts and I'd have to backtrack through previous build histories for reporting. This environment is very concerned with compliance and auditing so adversely impacting the reports is a tough sell.
To repeat the question, then, how do I use RM/Build agents in a production environment without installing Visual Studio on the agent machine? We're new to CD so I'm open to the idea that I have the wrong workflow.
Although the build and release agent is the same software, you can create dedicated agent pools of "release" agents that don't have any build concerns installed on them.
Then it's just a matter of choosing the appropriate agent queue when creating a release definition for your production environments. Each environment within a release definition can be configured to run on a different agent queue.
Your build will run once, in any environment you want, and then publish a set of artifacts. This will be on your pool of agents dedicated to building, and the agents in this pool will be configured appropriately.
Your releases will download and deploy those artifacts. These will run on your pool of agents dedicated to deployment.
Related
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
I have a windows service project that has a Build ready and now needs to be installed at the target machine and run. There is no task in TFS Releases that allows that to happen. What are my options other than writing a custom PowerShell script?
For the current approach, you need to install the build and deployment agents on a set of proxy servers in an agent pool and drive deployments to remote target servers.
The simplest way is using remote powershell task to achieve the installation. Details about the task please take a look at Deploy: PowerShell on Target Machines
In the near future, you could also use Agent-based deployment in Release Management. For this, you can install the agent on each of your target servers directly, and then drive rolling deployment to those servers. More details please refer this blog: Agent-based deployment in Release Management
You can do this easily with Team Build.
You use the "Copy" task on the Release tab to send the files to the machine that you want, and then run a remote PowerShell to do the installation.
You can even deploy the same Windows service to 10 machines using "Machine Groups".
I have created a lightly customized TFS build process template and also appropriate TFS build definition. It builds fine on the TFS build server.
Is there any way I can allow developers to reuse the same build process XAML and definition to do full builds on their local machines? Maybe there is some utility which can be run with TFS build process XAML files?
I really would like to avoid maintaining a separate copy of the build script for full local rebuilds.
The build templates can only be run by the TFS build service. Without installing that on each developers machine, that might not be the best idea.
An alternative is to setup a share on the developments machine and grant access to the TFS Build account (the one that TFSBuildServiceHost.exe runs on the server as). Then the developer can Queue a build and get the Server to Drop the files onto their machine.
The downside to this is you need a lot of builds to be run on the Agents.
I'm working on automating our build process using Team Foundation Build 2010. When our TFS Server was installed, whomever installed it didn't install the Build Configuration Services so this node is missing from the TFS Admin Console. I'm pretty sure I know the answer to this but I wanted to check in case I'm missing something. I'm also asking because the TFS Server is a production server and my supervisors do not want to install anything on this server. Can the Build Services be installed on another machine or VM and still have the Build Configuration Node appear in the TFS Admin Console? I know the Build Controller as well as the Build Agent can be installed on another machine or VM. I just wanted to get clarification on the "Build Configuration Services" piece. Thank you
Absolutely! This is actually a very typical scenario. I don't normally recommend for people to install the build services on any of the application tier servers. When you install only the build features, the TFS Administration Console will show only the build features.
By installing it on separate machines, you can create a build farm of a build controller with multiple build agents. It scales very well.
Build servers would be considered "production" servers in my opinion as well. They don't have the same disaster recovery or monitoring requirements though. If a build machine dies, just image another one and add it to the pool. This is essentially how the elastic build service for the Team Foundation Service (aka TFS Preview) currently works. They get destroyed after each use.
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