¿Existe una herramienta de CI que no garantice regresiones en el nivel de calidad de la sucursal?

10

Tradicionalmente, los sistemas de CI solo monitorean los niveles de calidad en una rama de integración, al realizar verificaciones de QA en la base de código donde los cambios ya están confirmados, observando regresiones y enviando notificaciones para intervención humana.

Pero cuando se detectan estas regresiones, la sucursal ya ha estado en problemas al menos desde que comenzó la verificación de control de calidad respectiva y permanecerá en ese estado (¡o incluso empeorará!) Hasta que se identifiquen a todos los culpables, se cometan las reparaciones y una nueva verificación de control de calidad confirma que se restableció el nivel de calidad de la sucursal. La rama puede considerarse bloqueada para el desarrollo normal durante todo este tiempo.

¿Existe una herramienta de CI capaz de evitar que ocurran tales regresiones, que realizaría verificaciones de control de calidad previas a la confirmación y permitiría las confirmaciones solo cuando la base de código actualizada con las confirmaciones respectivas también pasara esas verificaciones de control de calidad previas a la confirmación, garantizando así un mínimo nivel de calidad de la sucursal?

Actualización: se supone que las verificaciones de control de calidad automatizadas adecuadas con la cobertura adecuada para poder detectar las regresiones respectivas están disponibles para su invocación por las herramientas de CI.

continuous-integration software-recommendation

— Dan Cornilescu
fuente

Me sigo preguntando sobre la forma correcta de entender esta pregunta (y su propia recomendación en su propia respuesta). Si reemplazara "monitorear" con "después de los hechos" y "prevenir" con "evitar que sucedan", ¿sería más o menos la misma pregunta entonces? Además, ¿tal vez pueda agregar algún escenario de ejemplo para explicar la diferencia?

— Pierre.Vriens

@ Pierre.Vriens ¿Es esto mejor?

— Dan Cornilescu

6

Por lo que puedo decir, está buscando una herramienta que rechace las confirmaciones que rompen la compilación; una herramienta de CI probablemente no podrá evitar regresiones al corregir su código, pero puede evitar que agregue código incorrecto al repositorio.

Atlassian tiene algunas aplicaciones interesantes de ganchos Git :

Los ganchos de pre-recepción del lado del servidor son un complemento especialmente poderoso para la integración continua porque pueden evitar que los desarrolladores empujen el código al maestro, a menos que el código cumpla ciertas condiciones, como los guardianes ninja de élite, protegiéndolo del código incorrecto.

Si usa Git, los enlaces son muy potentes (y hay enlaces similares para SVN , Mercurial y otros sistemas de control de versiones), y puede resultarle útil usarlos para ejecutar comprobaciones previas a la confirmación.

La documentación de Git tiene una página sobre cómo crear un gancho para rechazar los empujes si no cumplen con ciertos criterios que podrían adaptarse fácilmente a este caso de uso.

Sin embargo, mucha gente argumentaría que rechazar commits es una mala idea en una featurerama: solo perderá el tiempo luchando contra su sistema de CI cuando la compilación se rompa por alguna razón, en lugar de corregir el error.

En la masterrama, podría tener sentido rechazar fusiones rotas, porque es posible que desee asegurarse de que siempre se compila. Para una featurerama, que va inevitablemente romper cosas, y puesto que el código no se va a producir ahora , tiene más sentido sólo para advertirle que en realidad rechazará su conjunto.

— Aurora0001
fuente

Bueno, ¿de qué sirve una imagen SW que se construye, pero es DOA de prueba prospectiva? Los desarrolladores no pueden probar sus cambios de código incluso si se compilan, por lo que estarían igualmente bloqueados. Por lo tanto, en general, extendería el rechazo de compromiso a cualquier cosa que falle una verificación mínima de control de calidad, elegida al equilibrar 2 requisitos en conflicto: lo más alto posible para maximizar el número de desarrolladores protegidos contra el bloqueo y lo más bajo posible de modo que la verificación de control de calidad retrase No ralentices demasiado el proceso.

— Dan Cornilescu

Un ejemplo de esto podría ser el modelo de solicitud de extracción donde puede imponer ciertas restricciones sobre si una solicitud de extracción puede fusionarse o no. Por ejemplo, nosotros (mi empresa) usamos Atlassian Bitbucket Server y hay opciones para requerir al menos N número de aprobaciones y X número de compilaciones aprobadas para la rama dada antes de que se permita fusionar una solicitud de extracción. Esto no lo rechaza por completo. Pero evita la fusión accidental cuando las pruebas fallan u otros ojos aún no han visto el código.

— Andy Shinn

@AndyShinn: Sí, eso me parece bastante útil: GitHub también ofrece sucursales protegidas y verifica solicitudes de extracción , que a menudo son útiles.

— Aurora0001

1

Un argumento para permitir el código roto en las ramas de características es que permite a los desarrolladores insertar el código en el que están trabajando en el repositorio, incluso si aún no está listo. Esto puede ser útil para compartir código con otros para las revisiones tempranas de código / arquitectura antes de que las cosas estén listas para funcionar, ayudar a solucionar problemas o para que alguien que se va de vacaciones ponga trabajo parcialmente hecho donde otros puedan acceder. Para las ramas de características, solo pondría cosas como linters y como ganchos de precompromiso.

— bradym

2

Ninguna herramienta podría garantizar ninguna regresión, eso depende mucho más de sus pruebas que la herramienta que las ejecuta. Sin embargo, puede ayudar a evitar que las regresiones que se capturen entren en la rama de integración. Puede hacer esto con ganchos previos a la confirmación, pero a menudo es más fácil con las solicitudes de extracción (que esperamos que ya esté utilizando para la revisión del código de pares).

Si una rama está actualizada con su flujo ascendente (donde el PR se está fusionando), y sus pruebas pasan, entonces aún pasarán después de la fusión; el estado de la rama de destino después de la fusión coincidirá con el estado de la rama de origen antes de la fusión.

En general, no es particularmente difícil (dependiendo de las herramientas utilizadas) indicar si la rama de origen en un RP está actualizada con el destino y si tiene una compilación de CI pasajera. Puede usar esto como un requisito (por política y / o impuesto en el software) para fusionar la solicitud de extracción.

— Adrian
fuente

"Si una sucursal está actualizada con su flujo ascendente (donde el PR se está fusionando) y sus pruebas pasan, entonces pasarán después de la fusión" - ¿Por qué? Una fusión es una discontinuidad, trae incógnitas. Al igual que los conflictos: es posible que el código ni siquiera se cree hasta que se resuelvan. Usted necesita para ejecutar las pruebas y confirmar que pasan por cualquier combinación de rama. Diría que incluso para un avance rápido, si quieres jugar a lo seguro. Ver apartsw.com/insights/2016/11/16/…

— Dan Cornilescu

Sí, tal garantía es posible, verifique mi respuesta. Bueno, tal vez debería aclarar: por regresión me refiero a resultados peores que los resultados de la línea base de la rama (e ignorando la posibilidad de falsos positivos, es necesario abordarlos, ya que pueden sesgar la línea base, descarrilar todo y requerir intervención humana). Los falsos negativos intermitentes son solo una molestia, ralentizan las cosas, pero pueden tratarse.

— Dan Cornilescu

No puede garantizar que no haya regresiones, solo puede garantizar que no haya regresiones detectadas. Si un cambio causa una regresión que no es detectada por una prueba, es una regresión sobre la cual una herramienta de CI no puede garantizar. Y si bien la combinación de dos conjuntos de cambios trae incógnitas, puede elegir hacerlo en la rama de características (fusionando el flujo ascendente) antes de fusionar la otra dirección. Si la fuente está actualizada con el objetivo, es una combinación simple (avance rápido), y luego el estado objetivo será idéntico al estado fuente antes de la combinación, por lo tanto, si las pruebas se aprobaron antes, pasarán después.

— Adrian

División de pelos. La herramienta CI se puede configurar con una prueba para detectar y proteger contra cualquier regresión que le interese. No discutiré demasiado sobre las fusiones: mi objetivo es evitarlas tanto como sea posible, son solo problemas en general :)

— Dan Cornilescu

Mi punto es que no es la herramienta de CI que ofrece esa protección, eres tú al escribir las pruebas. La herramienta CI no puede proporcionar ninguna garantía más allá de las pruebas que usted proporciona.

— Adrian

1

Las verdaderas herramientas de integración continua (a diferencia de las pruebas continuas) como Reitveld y Zuul pueden ayudar, aunque son tan buenas como las pruebas que escribe y las revisiones de código que realiza.

— coderanger
fuente

Pero Reitveld parece ser una herramienta colaborativa de revisión de código, no una herramienta de CI, ¿me estoy perdiendo algo? Esto es lo que miré: github.com/rietveld-codereview/rietveld

— Dan Cornilescu

Zuul parece estar realmente relacionado, lo estudiaré más de cerca.

— Dan Cornilescu

No realiza pruebas, pero maneja algunos aspectos de la administración de sucursales, actuando como un sistema de control de acceso, que es la mejor opción para evitar la entrada de código incorrecto bloqueando la fusión.

— coderanger

Veo a que te refieres. Bueno, puede ayudar con la calidad general del código, pero por sí solo no ofrece ninguna garantía. Dos cambios perfectamente buenos que pasan todas las verificaciones de control de calidad de forma independiente aún pueden causar roturas cuando se encuentran en la rama.

— Dan Cornilescu

1

Use GitLAB, puede configurar los ajustes del proyecto para permitir solo una fusión cuando la tubería tenga éxito, por lo que puede tener una integración verdaderamente continua, combinar eso con agregar su QA a la lista de aprobaciones de fusión y con entornos dinámicos, puede tener garantía de calidad antes de unirte al maestro.

— Danny Goossen
fuente

Eso funciona, pero solo si no permite que una segunda fusión comience las comprobaciones de control de calidad antes de que se complete la fusión anterior, de lo contrario, la segunda fusión no verá la primera, dejando espacio para las regresiones. En otras palabras, las fusiones (incluidas sus comprobaciones de control de calidad) deben estar completamente serializadas, lo que no escala para equipos grandes.

— Dan Cornilescu

0

ApartCI es un sistema de CI diseñado exactamente para evitar regresiones, garantizando así un nivel de calidad de sucursal plano o creciente. Aún en beta.

Orquesta verificaciones centralizadas previas al compromiso de tal manera que se asegure que un cambio se confirme solo después de que se verifique, junto con todos los demás cambios comprometidos antes, para cumplir o superar el último nivel de calidad de la sucursal.

Esta es la diferencia clave en comparación con las verificaciones de precompromiso tradicionales impulsadas por el desarrollador, a menudo realizadas en paralelo, lo que deja espacio para regresiones causadas por cambios interferentes que nunca se probaron juntos.

La herramienta también está diseñada para escalar fácilmente , capaz de mantener tasas muy altas de cambios de candidatos entrantes y admitir cientos / miles de desarrolladores que trabajan en la misma rama de integración.

Descargo de responsabilidad: soy el autor de la herramienta y fundador de la compañía que lo ofrece. Disculpas por el anuncio.

— Dan Cornilescu
fuente

Es bueno que hayas agregado el descargo de responsabilidad, pero personalmente considero hacer una pregunta y responderla promoviendo tu propia empresa o productos como una forma de spam.

— THelper

He hecho una pregunta sobre meta si esto está permitido o no: meta.devops.stackexchange.com/q/59

— THelper

SnapCI hizo esto también. DEP.

— paul_h

@paul_h, a menos que me falte algo, SnapCI y su GoCD de reemplazo recomendado se basan en verificaciones posteriores a la confirmación (activadas al sondear el SCM), por lo que siguen siendo solo de monitoreo. Excepto tal vez para las comprobaciones de relaciones públicas, pero a menos que estas comprobaciones estén completamente serializadas, solo pueden reducir las tasas de ocurrencia de regresión, pero no eliminarlas por completo.

— Dan Cornilescu

Dan, no sondeando no, ganchos. Y a una rama de relaciones públicas de corta duración que aún no se fusionó en trunk / master - trunkbaseddevelopment.com/game-changers/…

— paul_h