Hay un momento en el que comienzas a comprender que, en la arquitectura de micro servicios, es más aterrador esperar una semana para implementar todos los microservicios a la vez para asegurarte de que todo funcione en conjunto, en lugar de aplicar estrictamente el control de versiones de la API, escribir muchas pruebas (un poco de cada: unidad y exploración, integración), y despliegue automático a producción tan pronto como su confirmación pase como pruebas en el escenario.
Ahora, parece una gran idea siempre que recuerde escribir pruebas, probar los cambios antes de confirmar, saber cómo usar el control de versiones de API y no va a soltar la base de datos en su script de actualización incremental de db que se ejecuta en la implementación (que no es un gran problema, ya que debería fallar en el escenario).
¿Pero es factible hacerlo con programadores junior? Tal vez tendré que implementar el esquema de solicitud de extracción. ¿Esto lo haría menos como una implementación continua (eso es lo que supongo)?
Espero que esto no se base en una opinión y puedo contar con que comparta su experiencia, gracias.
Tenga en cuenta que no estoy preguntando sobre CI ni sobre la entrega continua. Ya tenemos eso. Lo que estamos intentando ahora es hacer un despliegue continuo, lo que significa tenerlo todo en producción justo después del check-in del código.
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.Respuestas:
Por qué no? Cualquiera de las cosas que describa sería un problema si usa la implementación continua o no. Parece que el problema es que le preocupa que los juniors cometan un error catastrófico. Y que ese error se apresurará a la producción antes de que alguien pueda detectarlo.
Es por eso que haces revisiones de código y pruebas. Antes de que algo se fusione con su rama maestra y esté programado para su lanzamiento, solicite que sea revisado por código, tanto por otros junior (para que obtengan experiencia) como por desarrolladores senior (para usar su experiencia para mejorar el código). Todos deberían estar buscando estos errores catastróficos. Y debería detenerlos. Si no es así, probablemente necesite un mejor control de calidad / prueba en un entorno de ensayo (y tal vez algunos mejores desarrolladores si las revisiones de código pierden estas cosas).
fuente
La implementación continua funcionará bien si tiene un buen conjunto de pruebas automatizadas.
Los desarrolladores junior pueden entusiasmarse con su propia tarea y no ver que rompen las cosas. Puedes arreglar esto con algo de automatización. Configure un servidor de compilación que ejecute pruebas todo el tiempo y obtenga una herramienta como el notificador de compilación CatLight . Les dará una respuesta rápida y clara cuando rompan las cosas.
Solucionarán pequeños problemas a medida que sucedan y mantendrán su entrega continua en funcionamiento.
fuente
La única forma de aprender buenos hábitos es practicarlos, por lo que sí, los desarrolladores junior también pueden practicar la implementación continua. Es posible que desee considerar agregar pasos en la tubería para hacer cosas como verificar la cobertura de prueba y posiblemente ejecutar un análisis de código estático, y fallar la compilación si la cobertura de prueba no es lo suficientemente alta. Eso asegurará que los desarrolladores junior entiendan las expectativas antes de que algo se considere completo.
fuente
No solo eso se puede hacer con desarrolladores junior, sino que se requiere de usted. Primero, reducirá la calidad de su software de otra manera, y en segundo lugar, esto ayuda a los desarrolladores junior a aprender buenas habilidades de desarrollo de software.
Como analogía: ¿Le gustaría que su médico no practique la medicina a su leal saber y entender porque tendrá miedo de los errores de los jóvenes aprendices? ¿Cómo manejan los médicos el daño potencial?
fuente
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.
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:
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.
fuente
Sí, puedes practicar CI con desarrolladores junior. Sería estúpido no hacerlo en el clima de desarrollo actual. ¡Es increíblemente útil poder presionar para repo y luego fusionarlo automáticamente en el código provisional, y verlo todo en tiempo real en Travis (o Bamboo, Pipelines, etc.)!
Lleva a tu chico DevOps y haz que atraviese el proceso con ellos, además de un desarrollador senior en modo de espera solo para vigilar las cosas y vincularlo con sus revisiones de código (lo haces, ¿verdad?)
Si le preocupa que el código de mierda vaya a pasar, eso no está en el CI y no está en los juniors: está en usted .
Así que ayúdelos a mejorar y acostumbrarse a implementar el código de etapa / producción más rápido. Te lo agradecerás a largo plazo.
fuente