Serling dev team
GEx’s Platform
Procesos, practicas y patrones de desarrollo
Objetivo
• Mostrar los distintos procesos, practicas,
patrones y algunas de las herramientas.
Jira
Seguimiento de tareas, issues
Jira
• Cada cosa en la que un desarrollador trabaja, debe tener
un issue en Jira
• Task
• Bug
• Refactor
• Improvement
• A...
Git
Control de versiones
Git
• Master branch
• Intentamos que sea la rama más estable
posible.
• Sobre esta rama se ejecutan pruebas después
de cad...
Git: feature branches
• Se crea un branch por cada cosa que el desarrollador
necesita hacer
• Generalmente el nombre del b...
Git: feature branches
Git: feature branches
• Todos los branches se crean a partir de master
• Los branches son “baratos”
• Es fácil cambiar de ...
Git: feature branches
• Tratamos de hacer la mayor cantidad de
commits
• Eso ayuda a la trazabilidad de los cambios en el
...
Git: feature branches
• Tratamos de nombrar los branches usando una
jerarquía que describa la intención del branch
• Así e...
Git: feature branches
Git: feature branches
• git checkout -b {bug|feature|refactor}/{idIssueJira}
{comentario}
• git checkout -b bug/MTFANAPI-2...
Git: feature branches
Git: Pull Request
• Tratamos de evitar commits/pushes en master
• Cuando el desarrollador termina su tarea, crea
un Pull R...
Git: Pull Request
Cuando al menos 2 aprueban
el PR se hace merge
Git commits
Si pongo el id de issue de Jira en el comentario del commit
Cosas magicas suceden
Git commits
Si pongo el id de issue de Jira en el comentario del commit
Cosas magicas suceden
Jenkins
Integración Continua
Jenkins
• Tenemos varios trabajos (Jenkins Jobs)
• Uno que verifica los cambios en rama master y ejecuta
al menos toda la s...
Jenkinscobertura de código
Cantidad de pruebas
Violaciones de
análisis estatico
Jenkins
• Implementamos un pipeline
de construcción encadenado
• Esto significa que si el trabajo
anterior funciona
correct...
Jenkins
• mt_fan_api_deploy_staging!
• Se dispara cuando hay cambios en el branch “deploy/staging”
• Lo único que hace es ...
Jenkins
• mt_fan_functional_tests!
• Ejecuta pruebas funcionales sobre ambiente de
staging
Serling dev team, development process
Upcoming SlideShare
Loading in...5
×

Serling dev team, development process

529

Published on

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

Published in: Technology
2 Comments
4 Likes
Statistics
Notes
  • @undefined Sobre lo que comentas de UAT, es muy diferente a lo que nosotros llamamos staging.

    Staging es un ambiente 'inestable', que sirve para ejecutar pruebas funcionales (pero no significa que sean de usuario). Cuando las pruebas funcionales que tenemos pasan, entonces se despliega a QA, que tal vez es lo que tu dices, aunque parte de nuestro pipeline de construcción es un nuevo ambiente que le hemos llamado PreProd. Preprod si lo vemos como un ambiente en donde el usuario puede validar (algo como lo que dices de UAT)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • De hecho, en la 26 el ambiente donde se debería de hacer el despliegue debería de llamarse UAT (User Acceptance Test Environment) ya que es una manera de asegurarse de que el componente cumple con los requerimientos funcionales (no los técnicos, ya que eso ya lo hizo Jenkins). Aunque entiendo que este ambiente (staging) tiene como finalidad cumplir con la integración de todas las líneas de trabajo(desarrollo) - 'asegurarse' dicen, de que compila XD.
    - IMHO

    Buena presentación, le tomaré unas ideas.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
529
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
1
Comments
2
Likes
4
Embeds 0
No embeds

No notes for slide

Serling dev team, development process

  1. 1. Serling dev team GEx’s Platform Procesos, practicas y patrones de desarrollo
  2. 2. Objetivo • Mostrar los distintos procesos, practicas, patrones y algunas de las herramientas.
  3. 3. Jira Seguimiento de tareas, issues
  4. 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. 5. Git Control de versiones
  6. 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. 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. 8. Git: feature branches
  9. 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. 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. 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. 12. Git: feature branches
  13. 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. 14. Git: feature branches
  15. 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. 16. Git: Pull Request
  17. 17. Cuando al menos 2 aprueban el PR se hace merge
  18. 18. Git commits Si pongo el id de issue de Jira en el comentario del commit Cosas magicas suceden
  19. 19. Git commits Si pongo el id de issue de Jira en el comentario del commit Cosas magicas suceden
  20. 20. Jenkins Integración Continua
  21. 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. 22. Jenkinscobertura de código Cantidad de pruebas Violaciones de análisis estatico
  23. 23. Jenkins • Implementamos un pipeline de construcción encadenado • Esto significa que si el trabajo anterior funciona correctamente, otro trabajo se dispara
  24. 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.
  25. 25. Jenkins • mt_fan_functional_tests! • Ejecuta pruebas funcionales sobre ambiente de staging

×