De la experiencia pasada con una base de código Big Ball Of Mud que evolucionó naturalmente durante muchos años a manos de muchos desarrolladores junior no supervisados, me gustaría señalar lo que sucede cuando no practicas CI con esos desarrolladores.
Editar / Actualizar : Según el comentario de RubberDuck; Esta respuesta supone que su objetivo de fusión para la integración es una rama de desarrollo en lugar de una rama de evaluación o lanzamiento.
- Obviamente, debe haber mucho más control sobre el código para el lanzamiento y la implementación en vivo; Si no hay una rama de producción separada, valdría la pena considerar un cambio en su estrategia de ramificación / fusión para ejecutar una rama de desarrollo maestra (que se utiliza para pruebas de integración y nunca para el lanzamiento) junto con la rama de lanzamiento maestro. Esto mantiene todos los beneficios de CI y fusiones frecuentes sin correr el riesgo de romper el código de producción.
1. Los desarrolladores junior tienen menos probabilidades de comunicarse con sus compañeros de trabajo o supervisor
La integración continua no es simplemente una cuestión de fusión en el código, es un momento en el que un desarrollador se ve obligado a interactuar con otras partes interesadas.
La comunicación es importante, y sin desear generalizar en exceso, tiende a ser una habilidad aprendida que llega con menos naturalidad a los desarrolladores sin experiencia que a los que están acostumbrados a trabajar en un entorno de equipo.
Si permite que los desarrolladores junior se sienten en su cubículo y combaten el código durante semanas sin que se les solicite informes / revisiones frecuentes, entonces es más probable que eviten la comunicación por completo.
2. Es probable que el código que están produciendo necesite una revisión más rigurosa
¿Alguna vez ha revisado algo que era tan malo que desearía haberlo leído antes y evitar que se haya escrito? Esto pasa mucho.
No puede evitar que se escriba un código incorrecto, pero puede limitar el tiempo perdido. Si se compromete a revisiones y fusiones frecuentes, minimiza el alcance del tiempo perdido.
El peor de los casos es que puede dejar a un desarrollador junior solo durante varias semanas en su propio proyecto en miniatura, y cuando finalmente estén listos para la revisión del código, simplemente no les queda tiempo suficiente para tirar todo el desastre. lejos y comenzar de nuevo desde cero.
Muchos proyectos se convierten en una gran bola de barro simplemente porque se escribió toda una carga de código incorrecto cuando nadie estaba prestando atención hasta que fue demasiado tarde.
3. Debe estar menos seguro de que un desarrollador junior u otro miembro nuevo del equipo haya entendido los requisitos
A veces, un desarrollador puede construir la solución perfecta para el problema incorrecto; esto es triste porque generalmente se debe a simples malentendidos que serían muy fáciles de evitar si solo alguien hubiera hecho las preguntas correctas anteriormente en el proceso.
Nuevamente, este es un problema que es más probable que afecte a los desarrolladores inexpertos que tienen más probabilidades de aceptar los requisitos "malos" al pie de la letra en lugar de rechazar y cuestionar la sabiduría del requisito.
4. Es probable que estén menos familiarizados con patrones comunes, con la arquitectura del código existente y con herramientas y soluciones conocidas
A veces, un desarrollador pasa una gran cantidad de tiempo reinventando la rueda innecesariamente simplemente porque no sabían que existía una solución mejor. O podrían pasar días tratando de clavar una clavija cuadrada en un agujero redondo sin darse cuenta de lo que están haciendo mal.
Una vez más, es más probable que este tipo de cosas les suceda a los desarrolladores sin experiencia, y la mejor manera de abordar el problema es garantizar revisiones periódicas.
5. Los largos períodos entre confirmaciones / fusiones de código hacen que los defectos sean más difíciles de identificar y corregir
Cuando surge un error inmediatamente después de que se hayan fusionado cambios de código por muchas semanas en la rama maestra, el desafío de identificar qué cambio puede haber causado el error se vuelve más difícil.
Obviamente, su estrategia general de ramificación también entra en juego aquí; idealmente, todos sus desarrolladores estarán trabajando en sus propias ramas, o dentro de las ramas de características (o ambas), y nunca trabajarán directamente desde el master / trunk.
He visto situaciones en las que equipos enteros trabajan directamente en el master / trunk al mismo tiempo, y este es un entorno terrible para CI, pero afortunadamente la solución de alejar a todos del master / trunk generalmente proporciona suficiente estabilidad para el trabajo individual. artículos / entradas / etc.
Siempre debe estar "bien" que cualquier desarrollador rompa la rama maestro / troncal, con el entendimiento de que la fusión debe ocurrir de manera tan regular, que los cambios y defectos de ruptura deben identificarse más rápidamente y, por lo tanto, resolverse más rápidamente también. Los peores defectos suelen ser los que permanecen sin ser detectados durante meses o incluso años.
En resumen; Las principales ventajas de la integración continua / implementación continua son:
- La comunicación entre tu equipo mejora
- La calidad del código generalmente se mantiene en un estándar más alto
- Es menos probable que los requisitos se pierdan o se malinterpreten
- Los problemas de arquitectura y diseño deben detectarse más rápidamente,
- Es más probable que los defectos sean detectados y reparados en una etapa anterior
Entonces, si no está practicando CI con sus desarrolladores junior, entonces está aceptando una gran cantidad de riesgos innecesarios, ya que estos son los miembros de su equipo que lo necesitan más que el resto.
it is more scary to wait a week to deploy all micro services at once to make sure that everything works together, than to strictly enforce api versioning, write lots of automatic tests (...), and auto deploy to production as soon as your commit passes as tests on stage- eso está basado en la opinión;) En mi humilde opinión, es mucho más difícil garantizar el éxito con la implementación de servicios independientes que con un enfoque monolítico: softwareengineering.stackexchange.com/a/342346/187812 . Y con un verdadero CI (sin ramas de características / integración) no debería tener que esperar una semana.