Presentación hecha en Grupo Expansion de parte del equipo de plataforma (Serling) al resto del equipo de producto.

1. Serling dev team
GEx’s Platform
Procesos, practicas y patrones de desarrollo

2. Objetivo
• Mostrar los distintos procesos, practicas,
patrones y algunas de las herramientas.

3. Jira
Seguimiento de tareas, issues

4. Jira
• Cada cosa en la que un desarrollador trabaja, debe tener
un issue en Jira
• Task
• Bug
• Refactor
• Improvement
• A veces trabajamos en cosas que no tienen issue,
tratamos de evitarlo

5. Git
Control de versiones

6. Git
• Master branch
• Intentamos que sea la rama más estable
posible.
• Sobre esta rama se ejecutan pruebas después
de cada commit/push (Ver explicación más
adelante sobre Jenkins)
• No hacemos commit/push directo (solo en
quick fixes)

7. Git: feature branches
• Se crea un branch por cada cosa que el desarrollador
necesita hacer
• Generalmente el nombre del branch es el id del issue
de Jira
• Evitamos que cada desarrollador tenga un único
branch. p.e.
• domix development branch
• Usamos tantos branch como sea necesario

8. Git: feature branches

9. Git: feature branches
• Todos los branches se crean a partir de master
• Los branches son “baratos”
• Es fácil cambiar de una tarea a otra (solo hay que
hacer commit y cambiar de branch si es que hay
trabajo a medias)
• Tratamos de evitar: git stash
• Los conflictos se resuelven en los feature branches

10. Git: feature branches
• Tratamos de hacer la mayor cantidad de
commits
• Eso ayuda a la trazabilidad de los cambios en el
código
• No es buena idea hacer commits mounstruo

11. Git: feature branches
• Tratamos de nombrar los branches usando una
jerarquía que describa la intención del branch
• Así es sencillo saber para que fue creado el branch
• bug
• feature
• refactor
• deploy

12. Git: feature branches

13. Git: feature branches
• git checkout -b {bug|feature|refactor}/{idIssueJira}
{comentario}
• git checkout -b bug/MTFANAPI-25_problema_al_buscar_partidos
• git checkout -b feature/MTFANAPI-23_perfil_usuario
• git checkout -b feature/MTFANAPI-23

14. Git: feature branches

15. Git: Pull Request
• Tratamos de evitar commits/pushes en master
• Cuando el desarrollador termina su tarea, crea
un Pull Request hacia master
• Opcionalmente se asigna a todo el equipo como
revisor

16. Git: Pull Request

17. Cuando al menos 2 aprueban
el PR se hace merge

18. Git commits
Si pongo el id de issue de Jira en el comentario del commit
Cosas magicas suceden

19. Git commits
Si pongo el id de issue de Jira en el comentario del commit
Cosas magicas suceden

20. Jenkins
Integración Continua

21. Jenkins
• Tenemos varios trabajos (Jenkins Jobs)
• Uno que verifica los cambios en rama master y ejecuta
al menos toda la suite de pruebas
• mt_fan_api_master_test!
• Genera reportes
• Pruebas
• Cobertura de código
• Análisis estático de código (Lint)
• Si el trabajo termina exitosamente, automáticamente
hace merge al branch “deploy/staging”

22. Jenkinscobertura de código
Cantidad de pruebas
Violaciones de
análisis estatico

23. Jenkins
• Implementamos un pipeline
de construcción encadenado
• Esto significa que si el trabajo
anterior funciona
correctamente, otro trabajo se
dispara

24. Jenkins
• mt_fan_api_deploy_staging!
• Se dispara cuando hay cambios en el branch “deploy/staging”
• Lo único que hace es el despliegue de la API en el ambiente
de staging (muchos le llaman ambiente de “desarrollo” o
“develop”)
• El ambiente de desarrollo IMO es cada maquina de los
desarrolladores
• Si el despliegue es exitoso, entonces se dispara el trabajo que
contiene las pruebas funcionales.

26. Jenkins
• mt_fan_functional_tests!
• Ejecuta pruebas funcionales sobre ambiente de
staging