Agentes remotos contra agentes locales para integración y deployment continuos

Actualmente estamos buscando mover nuestro código .NET del control de fuente TFS a Git usando Jira y Stash.

También nos gusta tener un buen server continuo de integración e implementación . Entonces, por esa razón, también estamos buscando en Bamboo .

Todas las características parecen estar bien. Lo único que no entiendo es la parte Agentes . Hay dos sabores, Local Agents y Remote Agents .

Entiendo que Local Agents están instalados en la misma máquina donde se instalará Bamboo. Y los Remote Agents están instalados en otras máquinas. Pero lo que realmente no entiendo es el objective. ¿Por qué no simplemente instalarías 5 o más agentes localmente? ¿Por qué querrías hacer eso en una máquina remota?

Por eso, también estoy cuestionando si un Local Agent puede publicar mi código .NET en cualquier otro server remoto.

¿Es posible con un Local Agent publicar nuestro código en una máquina remota? ¿O es allí donde deben usarse los agentes remotos?

Como se explica en este enlace , la principal diferencia entre los agentes locales y remotos es dónde se ejecutan:

  • Los agentes locales se ejecutan en la misma máquina que el server de Bamboo. Incluso se ejecutan como parte del mismo process / JVM.
  • Los agentes remotos pueden funcionar prácticamente en cualquier lugar. Un server dedicado o máquina virtual en su networking, o incluso en la nube. Los agentes remotos se comunican con el server central de Bamboo utilizando queues de posts (JMS).

Para ayudar a decidir cuál necesitará, intente pensar cuántos agentes tendrá inicialmente, pero también piense a más largo ploop.

Si solo vas a tener un agente, probablemente puedas hacerlo con un agente local. Si espera seguir aumentando el número de agentes con el time, es posible que desee planificar el uso de agentes remotos.

Un par de arguments para usar agentes remotos son:

  • Flexibilidad: a medida que crece, puede agregar fácilmente más agentes remotos según sea necesario. La implementación elástica en la nube puede ser de gran ayuda si necesita get más agentes rápidamente.
  • Escalabilidad: si solo está utilizando agentes locales, todos se ejecutarán en la misma máquina virtual Java (JVM). Cada agente local consumirá CPU y memory, lo que significa que no puede escalar interminablemente. Al usar agentes remotos, cada agente tiene su propio process, lo que permitirá escalar mejor a los agentes sin tocar los límites del sistema operativo con respecto al uso del tamaño / memory del process.
  • Ubicación: puede tener un server central de Bamboo, y luego soportar múltiples equipos individuales con eso, por ejemplo, si usted es una empresa global. Cada equipo podría ejecutar sus propios serveres de compilation con agentes remotos dedicados y configuration dedicada.
  • Failover: tener varios agentes remotos, y tenerlos separados del server central de Bamboo, le permitirá reiniciar los agentes de una manera más fácil. Si todo se ejecuta en el process central de Bamboo, si lo reinicia, todos sus agentes se reiniciarán también.

Con respecto a las preguntas de su networking: Claro, puede implementar desde un agente remoto o un agente local a cualquier otro server. Tendrá que establecer el acceso a la networking entre los serveres, siempre que lo tenga, se despliega con bastante libertad. Estamos utilizando SSH / SCP / SFTP en la mayoría de los casos, pero también HTTPS para implementar utilizando web services (por ejemplo, Tomcat o JBoss).

En general, tendrá más libertad y flexibilidad con los agentes remotos. La desventaja es la installation / configuration un poco más compleja. Si tiene la intención de crecer más allá de uno o dos agentes de compilation, generalmente vale la pena el esfuerzo.