Proceso de implementación de desarrollo ágil. ¿Dónde prueban el control de calidad y los propietarios de negocios?

9

Últimamente he estado leyendo mucho sobre varios procesos de implementación de aplicaciones web usando SVN o GIT, con miras a rediseñar cómo implementamos actualmente donde trabajo.

Como es el camino con muchos sabores de Agile, se supone que cualquier cosa comprometida con master o trunk está lista para la producción. Tanto GitHub como Etsy, http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/ dicen que funcionan sobre esta base (aunque Etsy realmente tiene un entorno de preparación).

Este proceso supone que todas las pruebas unitarias y las pruebas de CI se han ejecutado. Ejecuta las pruebas localmente y en CI y luego se compromete a troncal. Entonces, en este punto, su código es técnicamente sólido.

Su código puede ser técnicamente correcto, pero las pruebas de usuario / funcionales pueden descubrir más errores, particularmente cuando se trata de pruebas frontales.

Mi pregunta es esta ¿Dónde prueban los propietarios de QA y Business los cambios en las funciones que ha implementado? ¿En su máquina de desarrollo local antes de comprometerse con el tronco o en una máquina de control de calidad / preparación?

Si tiene una máquina de preparación que se ejecuta fuera de la troncal, y asume que todo el código comprometido con la troncal está listo para la producción ... eh ... entonces, ¿en qué punto está cerrado el código y es bueno para entrar en producción tanto desde el punto de vista técnico como comercial? ¿perspectiva? Si solo tiene una máquina de preparación, muchos desarrolladores y ahí es donde debe codificarse el código de calidad, entonces, ¿cómo puede implementar desde el tronco ya que muchos cambios de desarrollador pueden estar esperando la aprobación?

Me interesaría saber cómo otros han abordado esto.

git unit-testing svn testing deployment Bazza
fuente

Respuestas:

6

Para bien o para mal, generalmente veo que esto se realiza cuando las pruebas se realizan en la base de la sucursal y la firma de la empresa es lo que el punto de control debe fusionar con la implementación principal.

He visto esto hecho tanto con el desarrollo en "main" con una rama separada "desplegada" como con una rama de "característica" de desarrollo con una rama principal como "desplegada".

el flujo de trabajo termina luciendo así:

  • codificar algo
  • ejecutar pruebas locales
  • registrarse en la sucursal de trabajo
  • (opcional) el servidor de compilación construye pruebas ant
  • QA / Pruebas comerciales
  • correcciones de errores (bucle hacia arriba)
  • fusionar para desplegar sucursal
  • desplegar

Algunas personas trabajan desde una sola rama, pero si vas a tener pruebas manuales, eso se vuelve difícil. La mayoría de las personas con las que me he encontrado que trabajan suponiendo que cualquier cosa que se pueda implementar en commit que también funcione desde un solo tronco está haciendo algo pequeño, o tiene una ENORME cantidad de pruebas automatizadas, O consideran el "despliegue" en esta conversación para sea ​​una compilación para un servidor de prueba y el proceso de control de calidad que ocurre entre el servidor de prueba y la producción se maneja por separado.

Cuenta
fuente
Gracias Bill Trabajamos en un entorno donde los desarrolladores se comprometen y despliegan constantemente funcionalidades separadas para el sitio. Si trabaja en una rama de características, después de registrarse en la rama de trabajo, ¿dónde ve que se realizan las pruebas de control de calidad / negocios? Si solo tiene una máquina de control de calidad con la que los desarrolladores se comprometen, entonces solo se puede probar una característica a la vez, a menos que tal vez tenga un sitio y una instancia separada del servidor de aplicaciones configurado para cada desarrollador en la máquina de control de calidad, por lo que su los cambios se pueden probar de forma aislada antes de comprometerse con el tronco.
Bazza
en mi experiencia con esto, por lo general, no creamos una rama de características separada para cada desarrollador, más como una para cada equipo y configuramos un host qa para cada uno de ellos, incluso si era solo una máquina de desarrollo adicional.
Bill
Agradezco los comentarios. Me ha dado algunas ideas.
Bazza
2

Tenemos pruebas de aceptación automatizadas en la misma rama de características. Cuando hace una versión candidata, incluye las pruebas automatizadas que ejecutó para ver si la función pasa. También prueba al candidato de lanzamiento. Cuando todo pasa, lo promueves uniéndote para dominar.

Más sobre este proceso aquí:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Revisa los comentarios también.

Espero que esto ayude,

Adán

adymitruk
fuente
@ Adam - Gracias por eso, y el enlace. La discusión allí fue interesante. Comida para el pensamiento.
Bazza
0

Como regla general, esperar la confirmación antes de que el código sea perfecto es la mitad del tiempo, recuperar las ventajas del sistema de control de versiones. (¡Sin mucha explicación, diría que a menos que se permita a múltiples registros en VCS, uno no tiene forma de revertir mi propio trabajo!) Por lo tanto, como práctica, siempre pedimos a las personas que mantengan el registro (dentro de su sucursal para SVN o pueden ser confirmaciones locales en caso de GIT) tanto como quieran. De hecho, cuanto más mejor.

Sin embargo, cuando llega el punto donde todo parece estar hecho y probado, lo llamamos lanzamiento y luego se fusiona con el tronco. Esencialmente, el control de calidad puede certificar el RC haciendo un nuevo chequeo HEADde la sucursal y si él / ella lo acepta, lo mismo es fusionarlo nuevamente con el tronco.

Esencialmente, utilizamos el concepto de ramas de tareas o ramas privadas para que las personas sean libres de hacer los registros tanto como lo necesiten. Al mismo tiempo, el troncal está relativamente libre de cualquier registro roto .

Dipan Mehta
fuente