El desarrollador debe esperar a que se complete la canalización de CI o iniciar la siguiente tarea después de presionar

8

Mi compañía está integrando CI / CD, hasta ahora hemos implementado CI por lo que entiendo. Actualmente, cuando un desarrollador introduce código en nuestro repositorio de git, se ejecuta la canalización de CI.

Actualmente, nuestro canal de CI incluye la construcción del proyecto y el análisis de código estático para asegurarnos de que cumpla con nuestros estándares de codificación. Implementaremos las pruebas a continuación. La construcción y el análisis de código estático tardan unos 3 minutos en este momento. Por lo que he leído, solucionar problemas de inmediato es fundamental para CI / CD. Espero que cuando agreguemos pruebas unitarias, la tubería podría tardar alrededor de 10 minutos en ejecutarse.

Entonces, mi pregunta es cuando un desarrollador hace una solicitud de extracción / fusión ¿debería esperar a que se complete la canalización de CI o simplemente pasar a la siguiente tarea y volver para solucionar los problemas de la tubería si existen? ¿O deberían sentarse y ver correr la tubería?

continuous-integration git continuous-delivery

— iqueqiorio
fuente

7

¿Sentarse y ver correr la tubería?

No, no es así como trabajas eficientemente.

Los desarrolladores envían sus confirmaciones al repositorio de control de origen y luego se activa la canalización de CI / CD.

Los desarrolladores pueden publicar una solicitud de extracción bien escrita en cualquier momento que lo deseen. Generalmente hay una marca visual que representa una "compilación en curso" / "compilación fallida" / "compilación exitosa".

Por lo general, un brach se puede fusionar cuando se cumplen todos estos criterios:

ha aprobado al menos un aprobador / o tantos como se requiere para aprobar.
una "construcción exitosa"
sin conflictos de fusión no resueltos

Si alguno de estos criterios no se cumple, deben corregirse, pero el desarrollador lo hace cada vez que tiene tiempo o prioridad para realizar esta tarea.

— Jonas
fuente

2

Buena respuesta. Muchas personas no son conscientes de que con GitHub SaaS puede hacer que circle-ci u otro CI compile los cambios propuestos en una solicitud de extracción antes de que el cambio se fusione. Por lo tanto, he visto que GitHub Enterprise se usa in situ sin que se use esa característica: Jenkins Farm solo se ejecuta una vez que se fusiona el PR, que puede romperse a menos que el desarrollador haya fusionado y construido por completo. Eso hace que la vida sea mucho más compleja. Hace años, teamcity te permitió hacer una construcción ci en una granja antes de que incluso te comprometieras a evitar romper una rama. Solo construir después de que se haya publicado el problema es una forma de trabajo heredada.

— simbo1905

@ simbo1905 todo bien, excepto que la verificación de relaciones públicas no es 100% efectiva a menos que esté completamente serializada. Los RP superpuestos significan que los cambios respectivos no se tienen en cuenta y aún pueden interferir entre sí y causar una ruptura cuando aterrizan en la rama de integración. Incluso si no tienen conflictos de fusión o incluso tocan los mismos archivos, los conflictos funcionales aún son posibles.

— Dan Cornilescu

@DanCornilescu Los RP acordados pueden pasar compilaciones independientes pero en conflicto. Uno cambia el nombre de un método, uno agrega código que usa el antiguo nombre del método. Ambos RP pasan compilaciones en paralelo. Cuando se aprueban y se combinan, el código no se compilará. Los proyectos grandes usan un robot de fusión como bors-ng. El revisor no lo fusiona, le dice al bot que lo intente. El bot realiza fusiones en serie solo después de una nueva compilación donde había combinado lo que está en su cola de fusión. En nuestro ejemplo, intentará una compilación combinada de los RP combinados. Falla, así que intente solo el primero agregado a su cola, tenga éxito, fusione, luego cree y rechace el otro.

— simbo1905

1

Recomiendo hacer todo lo posible para asegurarse de que la tubería sea inferior a 10 minutos. Puede ejecutar sus pruebas en paralelo para habilitar esto. Como respondió Jonás, pueden pasar tiempo creando una solicitud de extracción (mientras se está ejecutando la canalización).

El cambio de contexto es malo para la productividad, por lo que, en lugar de tomar otra tarea, recomiendo que el desarrollador use ese tiempo para trabajar en cualquier otra cosa relacionada con el cambio que acaba de hacer. Tal vez hay alguna documentación que podría actualizarse relacionada con esto. Si es una característica notable, podría crear un pequeño gif que muestre cómo trabajar con él. Incluso mirar su cambio de código nuevamente puede ayudarlos a pensar cómo podrían mejorarlo la próxima vez. Este tiempo también podría usarse para revisar otras solicitudes de extracción de desarrolladores y cambios de código.

Si pasan a desarrollar otra función en esos 10 minutos, es probable que pasen más de 10 minutos antes de que vuelvan a ella y el trabajo sea menos fresco en su mente. Si el CI falla, será más difícil para ellos recordar qué pudo haber salido mal y corregir el código.

— Samuel Garratt
fuente

Esto es tan cierto: CI en mi opinión nunca debería funcionar más de lo que lo haría en la máquina del desarrollador.

— Peter Muryshkin

0

Bien, supongamos que tiene una herramienta de control de versiones como Git y la herramienta de CI Jenkins. Entonces Dev crea una rama de características para un problema. Tiene una tubería multibramch o un flujo de trabajo en su herramienta de CI que detecta esta rama de características en el siguiente escaneo y ejecuta los pasos de CI.

Entonces, las cosas que deben garantizarse son:

Antes de aumentar PR / MR, el trabajo de CI es verde. Si no es verde, PR / MR no debe elevarse. Obviamente, el desarrollador puede realizar otras tareas y luego volver y solucionar el problema en esta tarea, que es su elección dependiendo de la prioridad de la tarea. Incluso puede controlar que se genere cualquier PR verificando sus parámetros de CI.
Una vez que se genera PR, un revisor de código revisará y combinará si todo está bien. El revisor de código puede ser cualquier otro desarrollador. Su responsabilidad es revisar el código, ver si está dentro de los criterios de "Definición de Hecho". DoD es principalmente un término ágil pero ágil y DevOps van de la mano.
Una vez que se combina el código, el elemento de configuración para la rama principal debe ser verde. De lo contrario, el código debe revertirse y el problema debe repararse porque, en general, la rama principal también se implementa en entornos y no revertir significa que todo el entorno se romperá.

Obviamente, las acciones posteriores a la compilación notificarán al confirmador que Hey, usted ha roto la compilación, para que los desarrolladores puedan realizar sus otras tareas, de todos modos recibirán correos electrónicos.

— deosha
fuente