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?
fuente
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.
fuente
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.
fuente