Consider TFS 2010's ability for a Build Controller to have 1+ build agents. Since builds are a subjective topic to the team/environment, consider an environment where builds are performed on commit/check-in. Each Project Collection will have 10+ Team Projects, but perhaps only 1 or 2 are being committed to in a day.
When should a TFS administrator consider creating a new build agent?
Do multiple agents run in parallel?
When a single agent is defined to a Build Controller, does it run serially?
MSDN states: "if you set up your agents to have specialized capabilities..." . What does this mean? A technology/platform differentiator? How can you setup your agents to have specialized capabilities?
How can 'tagging' build agents be used effectively in an environment where builds are (typically) performed on each check-in.
You use multiple build agents to support multiple build machines (I work currently with a build farm with 3 build machines - and thus 3 build agents - to distribute the load).
You also might want to have multiple build agents to be able to run builds in parallel. This is a nice feature to share resources, but a requirement when you start working with Test/Lab Management features.
With the capabilities: for example you can setup a build agent with version 1 of a 3rd party component, and a second build agent with version 2. With tagging you can specify in the build definition which build agent it will choose from out of the pool of build agents.
We use 2 build agents on the same machine at work, since we only have one build machine.
The first one handles our CI builds, and is tag with CI. The build definition for the CI build is set up to only use agents that have the CI tag.
The second one is for manually queued builds, mostly for the release branch builds.
I specialized the CI build agent, because it was not uncommon when we were preparing a new build for QA to have several developers check into the development branch, which would slowing down being able to release the build to QA.
One of our builds takes 9 minutes. Its nice that you don't have to be in the Queue behind it if you happen to deploy at the wrong time.
Related
I have a Windows VM that hosts a VSTS build agent. Due to the number and length of builds that are running I would like to know whether multiple build agents can be hosted on one computer? That would allow a dedicated agent for slow builds, and a dedicated agent for quick builds.
https://www.visualstudio.com/en-us/docs/build/admin/agents/v2-windows
Yes you can run multiple agents in a single VM.
Make two directories say Agent1 and Agent2, extract the agent in each one of them and configure them with different names against your VSTS/TFS account.
It should work out of the box.
We run 4 agent jobs per machine concurrently with no issues. As mentioned above, should work out of the box. Just make sure you clean up directories. We have a script to do it every night
Yes, this works, I did the following:
Created a PAT for agent installation needs
Downloaded agent binaries from the agent creation page
Unpacked the archive contents into 2 different directories ("c:\ado-build-agents\agent1" and "c:\ado-build-agents\agent2")
Ran "config.cmd" and followed configuration instructions, provided by it.
Updated pipelines to build the agent pool, which those agents reside in ("Default" in my case)
To test the setup - triggered all 15 pipelines, that I had. As the result I was able to see two pipelines running at the same time, while others were in the "Queued" state (according to my expectations).
I will be also testing out how resources are consumed by the agents to try to understand if I should deploy more agents on the build machine.
I have a 4-5 java projects build procedure to be configured as CI using Jenkins. Whether it will be time saving to build some/all projects on different machines(connected as Jenkins slaves)?
Are there some any other benefits of Jenkins Master-Slave configuration?
Offloading work to build agents is a very good idea as it keeps load away from the master. This allows you to build more projects in parallel (esp. with dynamic agents launched in some cloud environment).
Further, it makes the systems easier to maintain, as e.g. the Java version/setup of your build agents required to build and test your application does not interfere with the Jenkins master machine.
We run an environment were multiple features are divided into branches. Those branches are configured to a channel in Octopus Deploy.
I would like to see if there is a way to check in a build definition if another build is queued for a branch.
For context - I have a Octopus Deploy step as the last step in our build definition. To deploy the app - it takes approximately 10 minutes. Our build process is also about 10 minutes (it is a big application).
When a team working on one feature checks in - we end up with 2 and 3 builds queued and waiting for each check-in and build to complete.
What I would like to do is have the deploy task run only if there is NOT another build queued for the same branch. This would ensure we don't waste 30 minutes of unnecessary deployments and only deploy the latest code.
What type of build do you use? XAML build or Vnext build. It seems that you use the CI trigger in your build definition, so it will trigger a build each time you do a check in.
VNext build:
You could select the Batch changes checkbox. According to this document,
If you select this option, when a build is running, the system waits until the build is completed and then queues another build of all changes that have not yet been built.
This will combin the changes into one build when you have a lot build queued.
XAML build:
In the build definition, you could use the Rolling builds trigger. This has the same function like the Batch changes mentioned above.
Note:
You also could use this REST API to get if there're builds of a build definition that are queued.
Http method: Get
http://servername:8080/tfs/DefaultCollection/TeamprojectName/_apis/build/builds?definitions=10&statusFilter=notStarted&api-version=2.0
It ended up being easier than I thought - but not exactly what I tried to do in the question.
The Octopus Create Release Task for TFS and VSTS has an option to "Show Deployment Progress". Checking this causes the build definition to wait - periodically receiving feedback from Octopus through the Octo.exe tool.
The deployment for this is actually a wrapper for several deployments (15 separate projects) - so it would take a long time.
Unchecking this option causes TFS to not wait - but send the create release / deploy command to Octopus.
Now this didn't solve my initial question - but Tingting0929-MFST did help me out in that I explored using the TFS Rest API. I wrote a PS script the effectively did what I asked - not deploy if there was a another build queued up for the same branch. I got it working - but it introduced a different problem in that the release notes from TFS and associated changesets / work items were getting swallowed in between releases.
In other words if three checkins came in fairly close separation, the last one would get deployed. Octopus would show only the release notes for last deployment and not the first two.
For those using Octopus Deploy in a feature branch set-up (one project deploying to multiple channels) - this is an option to get you the Continuous Deployment for each channel (branch).
In TFS 2015 Update 2, I have configured seven release agents in one pool, separated into a set of logical environments using capabilities.
I also have a release configured with three environments defined to use the queue corresponding to this pool and demands specified to filter to the appropriate servers for each environment (1-Test, 2-QA, 4-Prod).
My problem is that TFS is only releasing to the first agent created that meets the demands. If I remove all demands in an environment I would assume it would release to every agent in the pool yet TFS still releases to only the first agent in the pool. If I disable that first agent, it will release to the next; but still to only one agent.
What am I missing?
I think you're misunderstanding what agents are for. The agent merely acts as an invocation mechanism for your deployment activities. You don't need one agent per environment or per server.
For example, if you need to run a PowerShell script on a machine, you use the "PowerShell on Target Machine" deployment activity. The agent will then use WinRM to tell the target machine what scripts to run. That agent can run PowerShell scripts against any machine.
Why would you want the release or build to select a different agent every time? I had always seen with TFS that the probability of a build running on the agent, where the last successful build for a specific build definition ran, is very high.
The only reason I think a build/release should run on a different agent every time is if the number of builds running at a same time requiring the same capabilities is more than one.
If you would like to test each of the agents then try disabling one agent at a time and run the build/release.
I have a MsBuild process that start as part of build using TFS Build Services 2013. I need to pass a few parameters to this process (for example the build number). I've done this previously by modifying the build template and added these parameters to the list of parameters sent into MSBuild, something that has worked fine.
I did however found that TFS Build Services writes a number of environment variables for run (build number being one of them) and as I easily can change my MSBuild script I'd rather just use these directly variables instead of modifying the build template.
My question is however how this will work when I have several build agents? Won't they write over each others values in the environment variables? Can I be 100% certain in my MSBuild script that I didn't get the build number of the next build that might have started in parallel?
Each TFS build is done using a specific build number. If you have multiple agents working on a 'parallel' build, they will all use the same build number. Each build agent will be running in their own specific environment and will not have any issue if other agents are running in parallel - the build number for one agent will not 'clobber' another during a build.