I have a TeamCity (8.0.5) setup running with multiple agents and multiple projects with multiple configurations.
We have some build configurations for CI (eg compile and unit tests) and some of the configurations used for automated deployment.
The deployment configurations run scripts on shared services (eg IIS / sql etc) and so cannot be run in parallel with other deployment builds in any project.
Is there any way to limit this in team city?
I've have seen setting to "limit concurrent builds" but this only applies to a single configuration, I've also tried to limit the deployment builds to single common agent but I haven't been able to do this so far.
TeamCity 8 shipped with the Shared Resources plugin built-in and supported. It allows you to create a Shared Resource on any project in the hierarchy and under Build Features of a Build Configuration you can define what Shared Resources need to be available for the build to run, otherwise it'll be queued until the resource is available and a lock can be taken.
For more information, take at look at the TeamCity documentation: http://confluence.jetbrains.com/display/TCD8/Shared+Resources
Related
I have a solution with multiple projects, 2 of which are the main projects. A .NET WinForms desktop app and an ASP.NET WebApi2.
I have defined a number of publish profiles in Server project, which currently I execute manually. Now, moving to an Azure build pipeline I have a couple of questions:
I create a new pipeline based on the ASP.NET template, which builds all the projects within the solution. Should I leave as is, or should I exclude the client-side projects. If yes, then how can I achieve this?
I'm used to Visual Studio building and publishing just afterwards. In a CI/CD scenario, I assume that the I need to separate the building and publishing/deploying. Is this correct?
It all depends, you may use the same pipeline do build WinForms to create a package/installer. It is all up to you. If you want to exclude you may do it creating configuration
Configuration Manager -> Active Solution Configuration -> New ...
and then you will define what project you want to build. Next you will use this configuration in your build to just compile project you want.
You may pass configuration here.
If you use YAML pipeline instead of classic you may consider using multi stage pipeline. Here you have documentation and here a simple tutorial. If you decide to have one pipeline please check deployment jobs for deploying your app, however this is not necessary.
You you secleted classic pipeline you should go with classic release pipelines.
We are using VSTS for build and release management, and using CI/CD. Typically, our solutions consist of a web application project, and a database project.
Our current release tasks take the application offline (using app_offline.htm), publish the database, then publish the web application. Publishing the database project often results in no changes, as due to CI/CD we are much more frequently updating code on the web app than changing the db schema.
Is there a way to only run the database publish task (using WinRM) when it detects a change in the database project code, in our git repository?
EDIT: This in itself isn't a problem, as typically when the DACPAC gets published, there will be no activity. HOWEVER, I've been requesting that the database is backed up using the /p:BackupDatabaseBeforeChanges=true flag - which seems to back up the database even if there are no changes. This is an issue for large databases.
The simple way is that you can separate web project and database project to two build definitions.
Create a new build definition
Enable Continuous Integration in Triggers tab
Specify Path filter to include database project
Modify Visual Studio Build task, specify /t:[database project name] argument in MSBuild Arguments box to just build database project
The same steps for web project
Create a new related definition
Add artifacts for previous two build definitions and enable Continuous deployment trigger
Add two environments (e.g. database, web)
Open Pre-deployment conditions of an environment (e.g. database)
Enable Artifact filters and select corresponding artifact (e.g. database build artifact), specify build branch (can specify *, it means all branches)
Add tasks to just deploy database in this environment
The same steps for web environment
The answer is - exactly what I want isn't possible.
I have a few test sets in a single TFS build definition. I'm looking for a way to run all my tests sets in parallel to cut down on the time that the build takes to run.
Below is a screen shot of my build definition and my automated test configurations.
Does any one know how to accomplish this? I'm not seeing a setting in the build definition and I've seen test setting files being used to set this, but I'm not sure where to set the test setting file in the build definition .
The new vNext build system can run different build configurations in parallel (on different build agents) so you could, but I'm not sure how practical it would be.
Your tests sets would have to be in 4 different projects. Then you'd need to have different configurations:
- anycpu / release-with-tests1
- anycpu / release-with-tests2
- anycpu / release-with-tests3
- anycpu / release-with-tests4
With that you can enable (build) only 1 test project per configuration and set your build to run all tests (*test.dll), each configuration would only run one test project because the other ones were not built.
You enable the parallel build and it runs on up to 4 agents, depending on how many you have. Each agent would have to download the sources and build them before running the tests, so it could be interesting or not depending on how long your tests actually are.
There is a filter for the binaries you want to copy to your drop folder, so you can copy them for only 1 configuration and not waste disk space.
You can use the test frameworks that support multiple threaded execution to run the testing in parallel with multiple cores machines or distribute your test to multiple machines. Refer to this blog from MSDN for details: http://blogs.msdn.com/b/visualstudioalm/archive/2015/07/30/speeding-up-test-execution-in-tfs.aspx
Our team has a full licence for the TeamCity server, as well as 7 additional agents. Another unrelated team has reached the limits of their free TeamCity licence and is eyeing our licences up.
The powers that be think it's a good idea to run both teams using the same enterprise licence, which means that we'd be hosting the TeamCity configurations on the same server, and either sharing agents or somehow assigning some agents to one team, some to another.
One concern I have is that configuring an agent to only accept certain builds is difficult - our team has hundreds of build configurations, and we create new ones all the time. To limit an agent to certain builds, you have to fully specify the whitelist. So maintaining the agents such that we have full use of some agents, and the other team has full use of theirs will be a pain. On the other hand, just using one pool of agents means now you have arguments over priority and starvation, etc.
Does anyone have any experience of this? Is it a workable solution? How do you configure agents to reserve them for a particular team? How do you configure the server so that each team only sees their own projects, build configurations and agents? Basically what we'd want is complete separation of the projects, just using the same TeamCity server and agents.
As a gut feeling it doesn't look like a good idea...
edit: As an aside, does Hudson do this better? The ivory tower architects want us to change from TeamCity to Hudson because other people are using Hudson. If I tell them this sharing TeamCity won't work, the Hudson camp will probably use it as a stick to beat us with. Joy.
Not sure what version of TeamCity you're using but the newly released TeamCity v7.0 now has a new Agent Pool feature that provides a much easier way to distribute agents. It may be of interested to you, check out the What's New section or the Agent Pools docs for more info.
I had a similar issue with our two departments starting to share the same TeamCity instance to save the expenses of additional licenses. I must admit we didn't really have any issues apart from our agents were now twice as busy.
I enabled Per-project permissions on the Global Settings page and created 2 user groups, one for 'us', and the other for 'them'. You can then configure each group's roles accordingly. If a group does not have the Project Viewer role for a project then it does not appear for them - a great way to only display necessary projects to the group; but there are plenty of other role options to use.
I have never used Hudson so can't compare unfortunately. I should really try it out but as I've always got on so well with TC I've never had a reason too.
You can make builds on run on certain agent, from the build configuration of each build in the agent requirements section, thereby limiting any build configuration to certain agents.
For example if your agent for one team is teamcity1 you can specify:
system.agent.name does not equal teamcity1
So it will never run on that agent.
That way you can at least copy build configurations and they will run on seperate agents without the fiddle agent configuration.
The other team can create a new Teamcity server, and it will have its own new set of free build configurations and agents.
We don't do this any more, but we used to split our agents into pseudo-pools so we could reserve some for compilations and others for automated tests (because automated test jobs can swamp the grid). We added a "can_run_tests" property to the test agents, and made those builds require that property as an agent condition. It worked great, and it's the sort of thing you can bake into the AMI for a set of cloud agents.
What we do now is to make the compilation and test builds require on different AMIs, which does essentially the same thing.
I have many build configurations in TeamCity, each servicing a large project. In the past if a build is kicked off the Build Agent could be busy for up to 20min!
In order to improve throughput I installed a second Build Agent on the same machine such that if a build run is kicked off by say Build Agent 1 and it is busy for 20min and someone from another project makes a change then Build Agent 2 can do the build for the other project without needing to wait on the current build run to finish.
All was well until two successive check-ins resulted in both Build Agents running a build for a single build configuration in parallel. Since some resources are shared, IIS directories & databases, I don't want a single build configuration to run on both Build Agents in parallel.
How can I ensure a build isn't triggered if a build is currently running for that build configuration on a different build agent?
One way seems to involve environmental variables and ensuring a 50/50 split by Build Agent in terms of build configuration compatibility, but that seems a little clunky.
You can "Limit the number of simultaneously running builds" for a build configuration (general settings page).
Set it to 1, to fulfil your task.