• Save
Serling dev team, development process
Upcoming SlideShare
Loading in...5
×
 

Serling dev team, development process

on

  • 475 views

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

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

Statistics

Views

Total Views
475
Views on SlideShare
428
Embed Views
47

Actions

Likes
4
Downloads
1
Comments
2

4 Embeds 47

https://twitter.com 40
https://www.linkedin.com 3
http://www.slideee.com 3
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • @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)
    Are you sure you want to
    Your message goes here
    Processing…
  • 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.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Serling dev team, development process Serling dev team, development process Presentation Transcript

  • 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 View slide
  • 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 View slide
  • 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 cada commit/push (Ver explicación más adelante sobre Jenkins) • No hacemos commit/push directo (solo en quick fixes)
  • 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
  • Git: feature branches
  • 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
  • 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
  • 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
  • Git: feature branches
  • 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
  • Git: feature branches
  • 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
  • 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 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”
  • 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 correctamente, otro trabajo se dispara
  • 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.
  • Jenkins • mt_fan_functional_tests! • Ejecuta pruebas funcionales sobre ambiente de staging