Using TFS 2018, I have a need to deploy (individually) different team projects to the same target server. Until update 2 is released, it is not possible to share deployment groups.
However, there must be a way to deploy different team projects to the same server.
My thought was maybe I have to create one release agent for each project, since I cannot share a deployment pool. However, I read a TechNet post from 2016 that says
It is recommended to limit the number of agents, in a build machine,
to the number of CPU cores it has.
Whether the article was being ambiguous and means build - or - release agents, or only means build agents only, I don't know. OK, my target server has 4 CPUs and I need the option to deploy any number of individual, independent Team Projects to the same server, so it's starting to look like creating a separate depolyment agent per team project is not going to be feasible.
Until update 2 is released it is not possible to share the same deployment group. My question is how do I actually achieve this necessary outcome of independently deploying more than one Team Project to the same server?
Please remember that I am restricted to TFS. VSTS is not an option in my scenario.
That recommendation is really more for build servers. Build servers have very different requirements in terms of CPU/memory than release agents. Build agents are very memory and CPU intensive while running builds. You're not going to be running builds on your release agents.
The release agent is going to be idle the vast majority of the time. I don't see a problem with creating a second deployment group with a second agent install as a workaround until you can upgrade.
Related
I'm in the process of establishing a dedicated build machine with several build agents for doing CI/CD for multiple team projects.
I've configured one agent pool against our TFS server, and installed 10 agents from that pool as services on our machine.
Our work is mostly .net but we do have some python and js stuff as well.
My question is what are the pros/cons of using one machine with all the toolsets/dependencies?
Is there any good practice that i'm missing? I would love to hear some opinions.
Yes you can run multiple agents in a single machine. You might want to have multiple build agents to be able to run builds in parallel.
The biggest advantage is that avoid all the upfront capital costs (physical servers, MSFT server licensing, etc). And you just need to deploy the build machine in one time (install the toolsets/dependencies etc).
However please note that builds are typically IO constrained (disk/network read/write speeds), also constrained by the memory/CPU consumed. So running too many parallel builds on one machine will actually degrade the performance. Also may affect calls to the TFS and possibly lead to time-outs.
Besides, you may need to install additional or upgrade software components on the build server and that may need a reboot to take effect, this may affect the current building. Although you try to limit this as much as possible, eventually you could end up with conflicting software as the project advances and interrupting the existing builds.
So, recommend you to deploy separate build servers with the agents installed separately on each of them. That means use multiple build agents to support multiple build machines (e.g.: with 3 build machines - and 3 build agents - to distribute the load).
Is there a way (or some plugin/add-on) to add servers to an environment in TFS Release Management 2015?
I came from a team that used Octopus Deploy for DevOps. One thing that was extremely helpful was the ability to add multiple servers to an environment. Then, when you execute deployment steps on an environment, it applies those actions to all the servers that are part of the environment -- making deployments super easy. I have yet to find similar functionality in TFS Release Management and it's quite sad. They have a concept of an environment, but it's more like a "stage" than a logical/physical group of servers. To deploy the same step to multiple servers in an environment, you have to re-create the step multiple times or specifically write the names of all the servers in each step. Sad!
There isn’t the feature that execute deployment steps on an environment and applies to all the servers that in the environment.
But for web-based release management, you can provide a comma separated list of machine IP addresses or FQDNs along with ports for many steps/tasks of remote deploy, such as PowerShell on Target Machines, IIS Web Deployment and so on.
There is an article that may benefit you: Environments in Release Management
Regarding server and client based release management, there is environment that can include multiple servers, but you need to add steps multiple times for each server. I recommend that you use web-based release management.
I have a Visual Studio solution with one SSRS project, two SSIS projects, one SSAS project and one SQL Server project. I'm using TFS2013 Update 4.
I'd like to deploy this solution using TFS Release Management in two environments. First environment should be "populated" after the developer's check-in and in the second environment the projects should be deployed only in the next night (during the day the environment is used by the testers and a new deployment can affect their data).
It's possible to achieve this with TFS Release Manager 2013.4?
Update 1:
A single gated check-in build is taking too much time and that's why in this moment I have gated check-in builds separate for each project in order to keep the developer's waiting time to minimum.
Update 2:
The current setup is with five gated check-in builds that are building and deploying each project to the first environment and one nightly build that is building and deploying to the second environment the entire solution.
Add an additional "collector" build, that you automatically queue from the others whose purpose is to collect artifacts and be the reference for Release Manager.
In other words, say you have five CI builds, one for each project named CI1 to CI5. In each CI post-test script you run a similar command
TFSBuild start /collection:%TF_BUILD_COLLECTIONURI% /buildDefinition:Collector /queue /msBuildArguments:CIDrop=%TF_BUILD_DROPLOCATION%
to queue the Collector build.
This latter collects the artifacts from the parent build and the last know good artifacts of the remaining CI builds and copies them to its drop location.
Now you can use Release Manager as usual on this Collector build.
We currently use TFS 2008 and have build agents on multiple build servers. I came across this article Configuring Multiple TFS Build Services on one Machine which details how to set up multiple agents on one machine and this is a route we'd like to take.
I've set up a new server with 3 agents on it based on the details in the link and each agent has it's own drive on the server to build to.
If I build a project using any one of the agents by itself then it works fine however if I build the same project on each agent at the same time then a very odd thing happens.
Basically two out of the three builds will fail. What I can see in the build output log file is that although the build starts out on the correct drive, at some point during the build it then swaps to the output drive the second agent is using. The build on the second agent will then change to the drive of the 3rd agent and ultimately the 3rd build succeeds.
Each of the build agent services have their own .config file, they all have different port numbers and the properties of the agents are all building to different drives.
Has anyone experienced anything like this before?
Many thanks
You are trying to do something that is not supported by default and I am not surprised that it does not work. You should upgrade to TFS 2013 and move to the Controller/agent model. In TFS 2010+ you can run multiple agents on one box by design.
I am going to be responsible for implementing TeamCity into our development environment pretty soon. I have searched around and see no real answers, does anyone know if there is a 'best practice' when it comes to a build server. Is it Ok to install TeamCity on the same server as TFS, is it preferred? Or should I install it onto a dedicated server (which I can do).
Thanks
I would think that Microsoft's own advice about TFS would also be relevant here:
You can host a build server on the same computer as your Team
Foundation Application-Tier Server, but, in most of these situations,
this build server should not host any build agents. Build agents place
heavy demands on the processor, which could significantly decrease the
performance of your application tier. In addition, you might want to
avoid running any build server components on the application tier
because installing Team Foundation Build Service increases the attack
surface on the computer.
So, you might see unnecessary slow downs on other operations like version control, work item tracking, etc.
Install it on its own server, you don't want it grinding tfs to a halt when it is performing a build.
You could install the Teamcity server on the tfs server but if you can a separate machine, but as its the agents that do the work it those that definitely need to be on a different machine from teamcity and tfs if possible.