Integración Continua: Un Enfoque Práctico

Plática dada en Julio del 2017

Transcript

1. Integración Continua Un Enfoque Práctico Agustín Ramos @MachinesAreUs 2017
2. ¿Qué es?
3. “Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.” Martin Fowler, 2006 http://j.mp/2tWcUTG
4. Contexto
5. Industria • Se originó en “Xtreme Programming” (1990’s) • En toda la industria reportan beneficios al usarla. Personalmente • Practico Integración Continua desde ~2007. • Desde entonces la aplico en todos mis proyectos. • En su momento di varias pláticas de esto y de Entrega Continua (Continuous Delivery), 2010- 2012.
6. Entonces… ¿Por qué ésta plática?
7. He visto o conocido a muchos equipos que fracasan al intentar aplicar Integración Continua… ¡Quiero ayudar a remediar eso!
8. Agenda • Ingredientes • Proceso • Demo I • Tips • ¿Qué sigue? • Demo II
9. Ingredientes
10. 1. Uso disciplinado del repositorio de código. 2. Build automatizado. 3. Pruebas automatizadas. 4. Servicio de Integración.
11. Uso disciplinado del repositorio de código • Uso de ramas y tags. • Criterios para subir código al repositorio. Ejemplo: • Que compile. • Que corran las pruebas (manuales o automáticas). • ¿Otro? • Mensajes utilizados en los commits. Hay lineamientos establecidos sobre:
12. Build automatizado • Utilizar una herramienta de build (e.g. maven, gradle, etc) • Que se puedan generar los binarios/release con una sola instrucción. • Que el build sea repetible. • Nada de “en mi máquina sí jala”. • Que el build sea auto-contenido. • Contiene todos los pasos necesarios para ejecutarse.
13. Pruebas automatizadas Mínimo • Unitarias • Integración Deseable • Aceptación • Carga
14. Servicio de IC Cloud On Premise Integrado al VCS No integrado al VCS
15. Proceso
16. 1 2 3 4
17. Conceptos
18. Task Es un una acción que puede ser realizada con un comando. • Ejemplos: • Compilar • Ejecutar pruebas • Empaquetar • Crear un directorio • Copiar un conjunto de archivos.
19. Job • Consiste de 1 o múltiples tareas, ejecutadas de manera secuencias. • Si una de las tareas falla, el job se considera fallido y se interrumpe la ejecución.
20. Stage • Consiste de 1 o más jobs, c/u de los cuales puede correr de manera independiente uno del otro. • Si un job falla, el stage se considera fallido.
21. Pipeline • Es una sucesión de stages, que se ejecuta en orden. • Si un stage falla, todo el pipeline se considera fallido.
22. Trigger Es el mecanismo que hace que se dispare un build. A grandes rasgos hay 2: • Polling. • Web Hooks (preferido).
23. Demo I CircleCI, BitBucket
24. Tips
25. Tips para que funcione Relacionados al proceso: • Todos integran código diariamente, varias veces al día. • Arregla los builds rotos de inmediato. • Prueba en ambientes lo más parecidos a producción.
26. Tips para que funcione Relacionados al build: • Mantén tu build rápido. • No dependas del ambiente donde corre tu build. • O usa contenedores
28. ¿Qué sigue?
29. Análisis estático de código • Te permite verificar si se cumplen estándares y buenas prácticas de programación. • También te permite identificar posibles bugs.
30. Continuous Deployment • Si el build pasa los tests requeridos, el binario se despliega en un ambiente para pruebas manuales (de integración o aceptación). • Se necesitan scripts/tasks para el despliegue. • Pueden existir diferentes ambientes, y el binario se promueve de uno a otro conforme se cumplan ciertos criterios establecidos.
31. Continuous Deployment
32. Demo II Gitlab, Jenkins
34. Mañana, tú…
35. 1 2 3 4
36. ooo…
38. ¡Gracias!