¿Un equipo de 3 ingenieros necesita usar Chef y Jenkins en su proceso de desarrollo?

Realmente depende de tu esfuerzo de colaboración.

Asumiré que no estás familiarizado con Jenkins, y usarás una analogía aquí. Ignora si ya lo sabes. De esta forma, puede decidir si realmente necesita a Jenkins en su situación.

Para entender a Jenkins, primero tendrá que aprender sobre Integración Continua (CI)

El CI es un proceso que la mayoría de los desarrolladores utilizan para mantener intacta su base de código (es una práctica común cuando trabajas en un entorno grupal). Por ejemplo, una analogía para esto sería construir un nuevo hogar. Habrá múltiples contratistas trabajando en el sitio. Si instalamos las ventanas antes de que los pintores pinten la casa, existe la posibilidad de que pueda dejar caer pintura sobre las gafas o incluso terminar rompiendo una. El inspector revisará el sitio todos los días para ver si se rompió el aniquilamiento. El mismo proceso se aplica a la codificación. Un sistema de CI reúne todo el código de diferentes desarrolladores y lo compila en una compilación. Esto es bueno. Pero no completo. Lo haré una vez que termine de hablar sobre Jenkins.

Jenkins opera como el inspector en la analogía. Jenkins es un intermediario entre tu repositorio de código y tu servidor de compilación. Comprueba los cambios en su repositorio cada pocos minutos. Se recopila toda la información nueva y se envía a su servidor de compilación.

Aquí es donde entran en juego la iteración continua y la implementación continua. Si está desarrollando una aplicación móvil, el código se compilará bien, pero cuando instale la compilación e inicie la aplicación, es posible que ni siquiera se inicie. Aquí el Despliegue continuo entra en escena. Tiene que haber una forma de, al menos, probar sus aplicaciones con humo en cada registro de compilación o todas las noches antes de enviar los comprobadores.

Recomiendo TestGrid.io para ayudar con CI y CD.

Es por eso que lo creamos. Cada vez que su desarrollador comprueba el código, lo evaluamos usando nuestros Robots, no se necesita ningún script. Esto completará su proceso de CI.

Trabajé en equipos 2 ingenieros (sentados uno al lado del otro) en los equipos 0f 30 . Creo que incluso con un equipo de 2 o incluso 1 tener CI agrega mucho valor en mi opinión.

Ventajas principales

  • Te da más confianza en tu código que deseas compartir.
  • Alienta la calidad
  • Tiempo más fácil de implementación y menos errores (principalmente regresión)
  • Hace que la cobertura de pruebas de código / artefactos esté disponible para otros

Principales desventajas

  • Necesita una inversión temprana
  • Necesita a alguien con las habilidades

Vería las desventajas como algo fácilmente superable. ¿Quién no quiere gastar ese pequeño esfuerzo extra para aprender algo nuevo o hacer su vida un poco más fácil a largo plazo y automatizar esos aburridos y repetitivos pedacitos?

En cuanto a las herramientas, no está interesado en publicitar herramientas particulares, pero supongo que podría usar cualquier herramienta / proceso que le haga la vida más fácil (haga las suyas propias si tiene mucho tiempo libre personalizado según sus necesidades). hacer la mayor parte de esto en los días)

Cuando trabajé en equipos pequeños en el pasado y donde CI se saltó, los desarrolladores se culpan mutuamente por romper la compilación, refactorizar sin verificar lo que habían hecho, no probar en IE, solo Chrome antes de comprometerse. También hizo que el equipo fuera mucho menos productivo (principalmente esto estaba relacionado con el proceso, pero la herramienta de CI habría ayudado de alguna manera a resolver los problemas físicamente en estos casos)

Chicos, si son un equipo pequeño, quizás quieran consultar https://buddy.works . Esta es actualmente la forma más fácil de introducir la entrega continua a la cultura de la empresa sin poner tensión innecesaria en su flujo de trabajo + puede usarlo junto con Chef para lograr sus objetivos.

Sí, trabajo allí, pero no respondería a este hilo si no estuviera seguro de que puede ayudarte a optimizar tu proceso de desarrollo 🙂

Depende. Si el equipo no experimenta muchos problemas con las compilaciones rotas, las implementaciones manuales en varias cajas, los registros de seguimiento en varias máquinas durante la depuración o la falta de pruebas automáticas que se ejecutan periódicamente, entonces deberían estar bien sin Chef y Jenkins.

Una vez que se dan cuenta de que pasan demasiado tiempo en cosas que pueden automatizarse, es hora de reconsiderar el uso de estas herramientas.

De ningún modo. De hecho, solo una pequeña minoría de equipos necesita usar tales herramientas. Con solo tres ingenieros, generalmente sugiero que el uso de estas herramientas plantea una sobrecarga innecesaria que no es necesaria hasta que tenga más de 5-6 desarrolladores, en cuyo caso los cambios pueden no haber sido comunicados limpiamente en todo el equipo, por lo que es más formal y se debe agregar precaución al proceso del equipo.

Usé este tipo de herramientas incluso si estoy solo codificando. Hay 2 razones para hacer eso que tengo.

1. Se trata de cultura y si no creas la cultura al principio, entonces te devolverá un dolor de cabeza. Piensa en lo que sucederá si un nuevo desarrollador se une a tu equipo o mejor si luego creces rápidamente. Cambiar la cultura puede ser lo más difícil.

2. Me dieron mucho tiempo para pensar en la codificación y la creatividad reales y ahorrarme tiempo y operaciones repetitivas, como compilaciones, pruebas, revisión, etc.