Serling dev team, development process

940
-1

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
5 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
940
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
1
Comments
2
Likes
5
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

×