Agile deployment process

By Product Owner Alexis F. Zunino


The process to follow each time you need to upload a new software version to the Stage or Production environment.

Roles

Solicitante: Lider de Proyecto (PL)
Responsable: Lider de Infraestructura (IL) / SrumMaster (SM)
Solicitante alternativo: Jefe de Desarrollo (HD)
Solicitante alternativo / Responsable alternativo: CTO
Autorizante: Líder de QA (QA)

Steps

1. El SM y PL acuerdan el armado de un nuevo deploy con nuevas tareas / bugs fixeados.

El PL / SM deberá realizar las siguientes tareas para proveer a IL de la siguiente información:

  • Asegurar que el deploy solicitado no interfiera con el trabajo de algún tercero
  • Generar TAG que desea subir.
  • Incluir las “Deployment Notes” cuales tienen el objetivo de informar:
  • pasos adicionales a realizarcambios de piezas no versionadasconfiguraciones necesarias de plataformas externas o internasActivación / Desactivación de subsistemas (Ej. Cache)Ejecución de procesos pre-deploy y/o post-deploy
  • Proveer de información explicativa de lo que el proceso hace
  • Proveer de las herramientas, scripts, etc. que hagan falta para ejecutar las tareas
  • Incluir la ruta absoluta al TAG

2. El SM debe:

  • Generar en la Wiki las Release Notes, para luego enviar al IL el título de la página. Estas notas indicarán:
  • Tickets tipo Error que se fixearon para esta versiónTickets tipo Cambio y Nueva Característica que se incluyeronNuevas funcionalidades que no estén listadas en los tickets de Cambio o Nueva característicaKnown issues particulares de la versión

3. Una vez hecho esto, se tiene que obtener el OK de QA para la realización del deploy.

4. Una vez hecho el deploy, el IL debe:

  • Avisar al equipo de QA que el deploy está completo. Se hará por mail a qa@gointegro.com.

5. QA realizará un “Smoke test” de las tareas entregas + un flujo básico para determinar la integridad del deploy. En caso de tener fallas graves, se rechazará el deploy seguido de una de las siguientes opciones:

  • Se esperará un nuevo deploy que arregle los errores
  • Se hará un “rollback” a la versión anterior.

Se decidirá que acción llevar a cabo en base al tiempo de fix que lleve armar un nuevo deploy.