Apart from maintaining 6.5.x branch and addressing critical issues there, we are preparing for a jump into 7.0 features and spend quite a time elaborating general directions and specific features. We will surely start presenting them within upcoming EAP releases.
There is one of the minor features I'd like to ask your feedback for at this time. It is a so-called Agent Pools: ability to manage assignment of build configurations to agents not only on agent level, but for a set of agents. This is necessary to reduce configuration effort.
Apparently, this is only an issue for installations with many agents, but we get a continuous flow of related requests from many customers.
Current idea that we want to start with is:
Allow creating an "agent pool" that will hold a set of agents. Each agent can belong to a single pool only. There is a default pool of agents that all agents initially belong to.
A pool has a set of associated projects. This means:
a) the agent in the pool can only run the builds belonging to the associated projects;
b) the builds from the build configurations within the projects can only be built on the agents of the associated pools (a single project can be associated with several agent pools).
We will still preserve current ability to select build configurations that can be run on a specific agent.
Now the question for you: Does this approach sound like a major help in simplifying your agent management needs? Is restricting the granularity to project level is enough for your specific case?
Feel free to vote in the poll (to the right on the main blog page) or leave your comments.
There is one of the minor features I'd like to ask your feedback for at this time. It is a so-called Agent Pools: ability to manage assignment of build configurations to agents not only on agent level, but for a set of agents. This is necessary to reduce configuration effort.
Apparently, this is only an issue for installations with many agents, but we get a continuous flow of related requests from many customers.
Current idea that we want to start with is:
Allow creating an "agent pool" that will hold a set of agents. Each agent can belong to a single pool only. There is a default pool of agents that all agents initially belong to.
A pool has a set of associated projects. This means:
a) the agent in the pool can only run the builds belonging to the associated projects;
b) the builds from the build configurations within the projects can only be built on the agents of the associated pools (a single project can be associated with several agent pools).
We will still preserve current ability to select build configurations that can be run on a specific agent.
Now the question for you: Does this approach sound like a major help in simplifying your agent management needs? Is restricting the granularity to project level is enough for your specific case?
Feel free to vote in the poll (to the right on the main blog page) or leave your comments.
5 comments:
At ESPN we use TeamCity for more than continuous integration. We currently have Continuous and Release build configs for nearly every project. I'd like to add Deploy build configs for each project and have them run on agents in the production datacenter while the existing configs will run on our existing dev build agents.
It would be nice to be able to align triggers and artifacts. So for example if a project has multiple artifacts and multiple triggers I would like to associate triggers to artifacts such that if a trigger fires only the associated artifact(s) will be built vs. all artifacts being built.
I would also like to see agents or in agent pools to operate at certain times for e.g 9 till 6
What we need is if a build config has multiple steps then we can choose on which agent a step will run.In short step 1 runs on agent A; step 2 runs on agent B etc
> What we need is if a build config has multiple steps then we can choose on which agent a step will run.
Then you are to vote for TW-16423. Please make sure to add a comment to the issue on your specific case.
Post a Comment