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.
