ElectricCommander Course Video - Continuous Integration
2015-03-25 06:32:04 UTC
The content of this article is moved to https://support.cloudbees.com/hc/en-us/articles/360032823292 .
Comments
Benson Ayabe
If you have an enterprise setup that includes shared build pools, creating separate EC Sentry schedules just for the purpose of specifying a project-specific default resource seems like overkill. With such a setup, making sure that the server-wide 'default' resource is changed from 'local' to one of the servers in the shared build pools is sufficient.
A better reason for separating groups of projects into different EC Sentry schedules is the long-time problem that happens when a CI schedule fails during an EC Sentry run. When one CI schedule fails, all the remaining schedules do not run. Imagine having a large part of your Enterprise-wide user base demanding to know why their CI schedules aren't running. Separating the projects into different EC Sentry schedules minimizes the fallout/impact of a failed CI schedule (albeit does not solve it).
If you have an enterprise setup that includes shared build pools, creating separate EC Sentry schedules just for the purpose of specifying a project-specific default resource seems like overkill. With such a setup, making sure that the server-wide 'default' resource is changed from 'local' to one of the servers in the shared build pools is sufficient.
A better reason for separating groups of projects into different EC Sentry schedules is the long-time problem that happens when a CI schedule fails during an EC Sentry run. When one CI schedule fails, all the remaining schedules do not run. Imagine having a large part of your Enterprise-wide user base demanding to know why their CI schedules aren't running. Separating the projects into different EC Sentry schedules minimizes the fallout/impact of a failed CI schedule (albeit does not solve it).