Continuous Delivery, por donde empezar

www.sgcampus.com.mx @sgcampus

www.sgcampus.com.mx

@sgcampus

Edwin Cruz

Continuos Delivery, por donde empezar


Edwin CruzPrincipal Consultant @ MagmaLabs


¿Que es Continuous Delivery?


www.sgcampus.com.mx

@sgcampus


Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.


www.sgcampus.com.mx

@sgcampus


The ability to get changes, features, configuration changes, bug fixes, experiments into production or into the hands of users safely and quickly in a sustainable way.


www.sgcampus.com.mx

@sgcampus


A cheap way to deliver incremental changes to users


Ah ha?• Tu Software se puede enviar a producción a través de un ciclo definido

• El principal objetivo del equipo es mantener el software fácil de enviar a producción, con mejor prioridad el agregar nuevas funcionalidades

• En cualquier momento, cualquier persona, puede recibir retroalimentación acerca del estado de la aplicación, aun y cuando se hacen cambios

• Se puede tener un botón de ‘enviar a producción’, donde en cualquier momento se puede presionar y se tendrá la seguridad de que funcionará


www.sgcampus.com.mx

@sgcampus

¿Beneficios?

Reduce el riesgo, progreso real y retroalimentación de los usuarios más rápido


www.sgcampus.com.mx

@sgcampus

Entonces… ¿Porque?

¿Que tanto tiempo le toma a tu organización enviar a producción un cambio que involucra una sola linea de código?


www.sgcampus.com.mx

@sgcampus


Construir la aplicación correcta


www.sgcampus.com.mx

@sgcampus


Permite enviar a producción cambios que necesita el negocio sin restricciones como costos de operación.


www.sgcampus.com.mx

@sgcampus


5 Programadores escribirían aproximadamente 5k lineas de código por semana, ¿Las enviarían todas a la vez a producción?


www.sgcampus.com.mx

@sgcampus


Agile Manifesto: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software


www.sgcampus.com.mx

@sgcampus


Innova o muere Para cuando construyas algo que la gente pedía, ya querrán otra cosa diferente.


Queremos eliminar el estrés que crea cada deployment


Ok ok ok, ¿Por donde puedo empezar?


12 Factor Methodology al rescate!


www.sgcampus.com.mx

@sgcampus

1.- Codigo

El código debe estar guardado en un controlador de versiones, ejemplo: Git Extra: Git Flow


www.sgcampus.com.mx

@sgcampus

2.- Dependencias

Declarar explícitamente las dependencias de la aplicación, incluyendo versiones compatibles


www.sgcampus.com.mx

@sgcampus

3.- Configuración

Toda configuración tiene que ser via variable de ambiente, nada de configuraciones estáticas


www.sgcampus.com.mx

@sgcampus

4.- Servicios externos

Cualquier servicio que la aplicación consuma a travez de la red debe poder ser reemplazado sin cambio de código, ejemplo: la base de datos


www.sgcampus.com.mx

@sgcampus

5.- Compilar, Liberar y Ejecutar

Proceso por el cual se crea una nueva version de la aplicación Copilar: Crea un nuevo ‘binario’ Liberar: Aplica la configuración al binario Ejecutar: Ejecuta la nueva version


www.sgcampus.com.mx

@sgcampus

5.- Compilar, Liberar y Ejecutar

Proceso por el cual se crea una nueva version de la aplicación Compilar: Crea un nuevo ‘binario’ Liberar: Aplica la configuración al binario Ejecutar: Ejecuta la nueva version


www.sgcampus.com.mx

@sgcampus

6.- Procesos

Ejecuta la aplicación como un proceso totalmente independiente


www.sgcampus.com.mx

@sgcampus

7.- Puerto de escucha

Ejecutar la aplicación para que escuche en un puerto dinámico, definido en tiempo de ejecución


www.sgcampus.com.mx

@sgcampus

8.- Concurrencia

Para escalar, se hace de manera horizontal


www.sgcampus.com.mx

@sgcampus

9.- Disponibilidad

Aplicación robusta con un rápido arranque y detención del proceso de una manera gentil


www.sgcampus.com.mx

@sgcampus

10.- Paridad entre Dev & Prod

Mantener los ambientes de desarrollo y pruebas lo mas similar posible a producción


www.sgcampus.com.mx

@sgcampus

11.- Logs

Manejar los logs como eventos en serie, etiquetados y con posibilidad de ser redireccionados a otra salida


www.sgcampus.com.mx

@sgcampus

12.- Procesos de Administración

Procesos necesarios para la administración de la aplicación, por ejemplo migraciones a la base de datos deberían de correr en un ambiente idéntico al de la aplicación


Deployments, ¿que tipos hay?


www.sgcampus.com.mx

@sgcampus

Deployments

Blue-Green Actualizar todo en un solo evento


www.sgcampus.com.mx

@sgcampus

Deployments

Canary Releases Dirigido a un porcentaje pequeño de los usuarios Reduce el riesgo Funciona para detectar problemas de rendimiento


Deployment != Release


www.sgcampus.com.mx

@sgcampus

Deployment vs Release

Enviar código a producción no significa que esta activo Long-lived Branches Feature toggles, habilitar/deshabilitar modulos en tiempo real


Reglas de Oro


• El Software siempre es ‘deployable’ • Nada de ramas ‘long-lived’ • Ningún deployment se hace

manualmente


Componentes necesarios


• Control de versiones • Continuous Integration • Automated tests • Testing Environments


¿Como lo implementamos nosotros?


www.sgcampus.com.mx

@sgcampus

Roles

Engineers QA Product Owners


www.sgcampus.com.mx

@sgcampus

Engineers

Escriben código teniendo siempre en cuenta hacer fácil su ejecución y portabilidad


www.sgcampus.com.mx

@sgcampus

Aseguramiento de la Calidad

• Automated • Manual • Manual/Automated


www.sgcampus.com.mx

@sgcampus

Product Owners

• Validación de la funcionalidad • No revisan Pixel perfect


www.sgcampus.com.mx

@sgcampus

Flujo de Trabajo

• Feature Branches • Pull requests • Review App por PR • Master branch está protegida • CI con flujo personalizado


www.sgcampus.com.mx

@sgcampus

Pull Requests

• Todo el trabajo se hace en feature branches • Engineers revisan su trabajo en la Review App • CI ejecuta las pruebas y validadores • Hasta que todo esta aprobado, se acepta el

cambio


Pull Request Dashboard


Pull Request


Review Apps


www.sgcampus.com.mx

@sgcampus

Ambiente de Staging

• Una vez que las pruebas son ejecutadas y validadas, se hace deployment automáticamente a Staging

• QA revisa los criterios de aceptación incluyendo diferentes navegadores

• Si es un cambio de email, usamos Litmus


Ambiente de Producción


www.sgcampus.com.mx

@sgcampus

Que hemos aprendido

• Planear el trabajo por adelantado (al menos 2 sprints)

• Tener una suite de pruebas confiables • Re-estimar el esfuerzo después de una

discusión técnica en los Sprint Planners


www.sgcampus.com.mx

@sgcampus

Que hemos aprendido

• Review Apps, replicar los datos de staging • No necesitamos las ramas de

‘Development’, ‘Release’ o ‘Staging’ • Feature toggle en vez de long lived PR’s


www.sgcampus.com.mx

@sgcampus

Que hemos aprendido

• En caso de un Hotfix, se crea una branch a partir de un tag de git

• En caso de una mala estimación, se parte la tarea en vez de editar la tarea

• Escalamiento horizontal es mas fácil y barato


www.sgcampus.com.mx

@sgcampus

Que hemos aprendido

• No necesitamos una posición dedicada a DevOps

• La elección de la herramienta de PM tiene que adaptarse al flujo de trabajo


www.sgcampus.com.mx

@sgcampus

Gracias

¿Preguntas?

Edwin Cruz MagmaLabs @softr8

Continuous Delivery, por donde empezar

Technology

Transcript of Continuous Delivery, por donde empezar