¿Cómo evitar inestabilidades continuas causadas por la integración en entornos de prueba?

19

Suponga que está utilizando procesos de integración continua que frecuentemente actualizan algunos entornos de destino, de modo que cada vez que haya algunos cambios "usted" pueda probar sus cambios de inmediato. Eso es parte de los objetivos de CI, ¿no?

Pero, también suponga que tiene otras personas involucradas en su ciclo de prueba, por ejemplo, gerentes o clientes. Tiene sentido involucrar a otras personas para tratar de revisar (¿romper?) Sus próximos cambios, ¿no?

Pero si continúa continuamente entregando cambios en el entorno en el que esas otras personas están, en serio, tratando de probarlos, entonces pueden surgir múltiples problemas, como:

  • they podría perder su tiempo informando problemas que, cuando guardan el informe (en profundidad), ya ni siquiera pueden reproducir el problema por sí mismos (por ejemplo, porque accidentalmente también se encontró con el mismo problema y ya lo solucionó en su entorno).
  • you es posible que no pueda reproducir los problemas que informaron, ya que los entornos en los que se encontraron con algún problema ya no son idénticos (usted (!!!) podría haber superpuesto su entorno).

Entonces, ¿qué puede hacer (¿cómo configurar las cosas?) Para evitar tales (frustrantes) situaciones?

Pierre.Vriens
fuente

Respuestas:

10

Daré mi experiencia en este caso, principalmente porque muestra por qué algunas respuestas no siempre son aplicables.

Algún contexto para comenzar:

  • Tenemos 7 entornos para alojar aproximadamente 80 aplicaciones, la mayoría de ellas dependen de las demás a través de servicios web o tablas compartidas en db2-iSeries.
  • Para bien o para mal, los iSeries son nuestro sistema de referencia DB.
  • Este último punto invalida cualquier idea de llevar la aplicación con sus dependencias en un entorno aislado, ya que abrir un AS400 para cada uno costaría demasiado y no tendríamos el hardware para ejecutarlo de todos modos.

Lo que estamos haciendo no es una entrega continua automatizada completa, tenemos un cronograma de lanzamientos para que aparezca una gran cantidad de aplicaciones coherentes para las operaciones generales. Aparte de esto, cada equipo de prueba puede desencadenar una versión en uno de los entornos de preguntas y respuestas para la aplicación que están probando y puede bloquear una versión de la aplicación para evitar que otra solicitud del equipo rompa sus pruebas.

Las dependencias de las aplicaciones se verifican antes del lanzamiento, por lo que el sistema no lanzará algo si otras aplicaciones no se pueden actualizar o no coinciden con sus dependencias necesarias. La idea principal es permitir actualizaciones cuando no afecte a alguien, si no hay pruebas planificadas, debería fluir del entorno anterior (y nuestro objetivo es eliminar las versiones programadas en los 5 primeros entornos a medio plazo, ahora tenemos validado este sistema de método 'bajo demanda').

La versión corta es tener un sistema de 'semáforo' alrededor de las aplicaciones en el entorno, un equipo debe poder bloquear su aplicación de destino con sus dependencias (y dependencias transitivas) durante el tiempo de las pruebas manuales.
La implementación de este semáforo depende en gran medida de su sistema de automatización, por lo que no me extenderé en eso.

Por supuesto, la manera fácil es, como otros mencionaron, crear un entorno nuevo para una aplicación con todas sus dependencias para evitar el semáforo descrito anteriormente.

Tensibai
fuente
Esta respuesta es una variación de lo que estoy acostumbrado (mainframes), donde hacemos este tipo de cosas durante al menos 1,5 décadas más o menos (antes de que naciera "DevOps"). Me pregunto si tendría sentido agregar mi propia respuesta aquí (para ampliar aún más esta respuesta, cómo hacemos esto con CMN / ZMF para, por ejemplo, "bancos"), o simplemente llevarla a una nueva pregunta (auto-contestada). ¿Qué piensas? Además, tengo curiosidad acerca de esa metáfora, ¿vale la pena una nueva pregunta (con referencia a esta respuesta)? PD: ¿te importa si corrijo algunos errores tipográficos?
Pierre.Vriens
No hay problema para editar :) Lo mantuve genérico, eso no es muy específico para una organización devops en mi humilde opinión. Una vez más, DevOps es un cambio de organización, que puede ayudar a establecer una mejor automatización al compartir las preocupaciones ... así que llamo a esto un semáforo como en programación, no creo que valga la pena una pregunta, pero eso depende de usted
Tensibai
Ok, editar completado (como siempre: retroceder / mejorar como mejor le parezca). Por cierto, ¿tienes una "s" en tu teclado?!?!?! Aparte de eso: cosas para pensar durante el fin de semana: mira mi nueva meta pregunta ... ¡Buen fin de semana! Tiempo para la jardinería por aquí (poda ...)
Pierre.Vriens
8

Parece que está hablando de un entorno de prueba que se reutiliza constantemente sin reinicializarse de manera confiable para cada ejecución de prueba. Esto hace que tal prueba no sea confiable. Similar, desde la perspectiva de la confiabilidad, con pruebas manuales, si lo desea.

En mi humilde opinión, no debe utilizar tales pruebas dentro de sus propósitos de calificación de CI / CD, ya que eso invalidará efectivamente su proceso de calificación (al menos en esa área). Decir que el software pasa la prueba X sin ejecutar realmente la prueba X para cada versión de software entregada o sin tener la certeza de que el passresultado obtenido no es accidental (debido a falsos positivos) erosionará el nivel de confianza de su prueba. Los falsos negativos no son perjudiciales para la credibilidad, pero tampoco son indeseables debido al "ruido" innecesario que crean.

Está bien ejecutar tales pruebas fuera de su proceso de calificación de CI / CD. Pero trataría un resultado fallido en tales pruebas como un error encontrado por el cliente: necesitaría reproducir de manera confiable el problema para poder desarrollar una solución y confirmar que la solución está funcionando. Y realmente no puede hacer eso si la prueba no es confiable.

Si planea abordar el problema, lo ideal sería desarrollar primero un caso de prueba automatizado y confiable para reproducir el problema. Lo que usaría para desarrollar una solución y confirmar su efectividad (el resultado de la prueba debe pasar de FALLO a PASO). También puede (¿debería?) Colocar este caso de prueba dentro de su proceso de calificación de CI / CD para evitar futuras repeticiones, si lo desea, para aumentar su nivel general de calidad de lanzamiento de software.

Dan Cornilescu
fuente
Hay mucho que digerir en su respuesta (no estoy seguro de haberlo entendido por completo). Pero lo que escribió sobre " ejecutar tales pruebas fuera de su proceso de calificación de CI / CD ": esperaría que el resultado final de lo que se produce / entregue se almacene en su QA y entornos de producción (a través de CD, ya sea automático o manual). Pero eso también "me parece " que CI también debería entregar su salida allí, mientras que "afuera" parece separación o duplicación o algo así, ¿no?
Pierre.Vriens
Las referencias insidey outsideson relativas al bucle de verificación de CI. Básicamente, cuestiono la razón de la existencia del entorno de control de calidad: la mayoría de las pruebas realizadas allí deben ser confiables y eventualmente ejecutadas como parte de las verificaciones de CI, especialmente en un contexto de implementación continua, ya que desea ejecutarlas en cada iteración de CI (exitosa hasta ese punto al menos) de todos modos.
Dan Cornilescu
7

El enfoque habitual es crear diferentes entornos:

DEV: este es el lugar donde el equipo de desarrollo ensucia las cosas. Aquí se crean ajustes de todos los cambios, se implementa una nueva versión, etc. Aquí es el lugar donde CI está completamente integrado.

PREPROD / QA: este es el lugar donde "juega" el equipo de QA / prueba / validación para realizar las pruebas. Este ambiente generalmente se congela durante las pruebas. La integración de CI con este entorno es solo para proporcionar una nueva versión del producto, configuraciones, etc.

PRODUCCIÓN: ¿es necesario explicar :)?

Romeo Ninov
fuente
ok, eso debería ayudar a mejorar la estabilidad, merci! Mi pregunta es sobre los entornos de "prueba", por lo que, obviamente, la "producción" no debe considerarse como tal. A pesar de aquellos que usan "producción" para las pruebas, ¿sabes el dicho " La mejor prueba es activarlo en producción, y si no funciona, simplemente realiza una reversión / retroceso "?
Pierre.Vriens
@ Pierre.Vriens, "jugar" en la producción en mi humilde opinión no es sabio :) Tal separación del entorno es intencional. En el trabajo anterior teníamos 5 entornos diferentes ... Un servicio de votación
Romeo Ninov
1
"Yo" estoy de acuerdo en que ese juego no es sabio. Sin embargo, ¿qué puede "usted" hacer con los vaqueros (mi 'término' que uso para tales juppies) que siguen haciendo esto una y otra vez, y cada vez que obtienen la aprobación de sus gerentes para sortear la (por ejemplo) activación de liberación mensual , por otra corrección de errores (por ejemplo, por su corrección del día anterior ... que introdujo un nuevo error). ¿Crees que eso no sucede en el mundo real? Por cierto: sobre el "congelamiento" en su respuesta, cree que tiene sentido publicar una pregunta como "¿Qué son las implementaciones de muestra de un entorno congelado?"
Pierre.Vriens
@ Pierre.Vriens, para mí tiene mucho sentido publicar esa pregunta. Normalmente esto está regulado por las reglas de la compañía, pero los desarrolladores crean un entorno bastante dinámico y esto puede ser un verdadero desafío :)
Romeo Ninov
1
Este es mi enfoque preferido, de esa manera proporciona un entorno en el que los desarrolladores pueden probar inmediatamente sus cambios en un entorno integrado, pero mantiene limpio el control de calidad hasta que el código esté listo para ser probado formalmente
Taegost
3

Si está haciendo CI / CD, eso implica que hay algunas pruebas automatizadas que están ocurriendo (CI) antes de la implementación (CD). Si encuentra muchos problemas en su entorno de prueba, eso significa que las pruebas que se ejecutan antes de la implementación no los detectan; Esto indica pruebas automáticas insuficientes. Si los desarrolladores tienen problemas donde surgen defectos en los entornos de prueba, deben mejorar sus conjuntos de pruebas automatizadas para evitar esto. Esto también mejorará la calidad y la confiabilidad en general, hasta la producción.

Adrian
fuente
3

Para agregar a la respuesta de Romeo Ninov, internamente dentro de un entorno debe intentar separar las aplicaciones tanto como sea posible. Esto es en parte por qué Docker ha sido tan exitoso para dev / test. Casi te permite fingir que no estás compartiendo un entorno en absoluto.

La otra opción es tener servidores claramente definidos en los que se ejecutan las aplicaciones, que son independientes del resto de la infraestructura que conforma su entorno. Es decir. Toda la maquinaria de gestión o habilitación del entorno va en servidores separados y de larga duración. Luego conecta nuevos servidores de corta duración basados ​​en una imagen conocida para probar una aplicación y, si se realizan cambios en la imagen base, debe aplicar esos cambios en todas partes para cada nuevo componente. Lo que significa probar los cambios contra todo.

Si un equipo de appdev solicita un cambio que rompa la aplicación de otra persona, entonces, mala suerte, deben crear internamente un mitigante en su código y mantener sus requisitos específicos separados de los entornos que ofrecen.

hvindin
fuente
Puntos de vista / adiciones interesantes, aunque hay algunas cosas en él que tal vez desee refinar / reelaborar: (1) "aplicaciones" en este contexto, ¿qué quiere decir (algunos ejemplos?) (2) alguna idea de cómo esto podría funcionar (buen viejo) entornos mainframe (3) ¿Qué es un "mitigante" en este contexto aquí? PD: avíseme si cree que debería crear una nueva pregunta para cualquiera de estas "cosas" (viñetas).
Pierre.Vriens