Git: flujos de trabajo y herramientas para trabajo colaborativo

AnunciosGrupo de usuarios de git

• Nuevo meetup 17 de noviembre ¿algún voluntario?

• Cambios en la política de reservas• ¿Alguien quiere dar una charla de gitlab?

Git: flujos de trabajo y herramientas para

trabajo colaborativo@aprendegit@aalbagarcia

Dando el salto

http://www.imdb.com/title/tt0298130/

Cosas a tener en cuenta(que no son objetivo de la

charla)• Calidad del código• Documentación• TDD / BDD / Testing en general• Metodologías ágiles: SCRUM, XP, etc• Gestión de proyectos

¿Cómo compartimos código?

¿Dónde alojamos nuestros repositorios?

Reglas del juego más habituales para

proyectos open source

Definiendo unas reglas del juego

• Sólo el propietario del repositorio puede escribir (hacer push)

• El resto del mundo tiene que hacer un pull-request para enviar código

• Con el paso del tiempo, se pueden añadir usuarios con permiso de escritura que pueden hacer commits directamente sin pull-request(se gana agilidad)

Qué es un pull request

Qué es un pull request

etiqueta

• Cada proyecto tiene su forma de aceptar contribuciones… entérate en cada caso y ¡sigue las instrucciones!

• Decide en tu proyecto cómo lo vas a hacer

http://www.moonmagazine.info/bond-su-nombre-es-bond-james-bond/

etiqueta

http://www.moonmagazine.info/bond-su-nombre-es-bond-james-bond/

etiqueta

http://www.moonmagazine.info/bond-su-nombre-es-bond-james-bond/

etiqueta

http://www.moonmagazine.info/bond-su-nombre-es-bond-james-bond/

etiqueta:squashing

http://www.moonmagazine.info/bond-su-nombre-es-bond-james-bond/

Definiendo unas reglas del juego

• Definir un flujo de trabajo• Repositorio maestro, todo el mundo tiene

permiso de escritura• Repositorio maestro con forks• Mezcla de los dos anteriores

• git-flow: http://aprendegit.com/que-es-git-flow/

Definiendo unas reglas del juego

https://git-scm.com/book/es/v1/Git-en-entornos-distribuidos-Flujos-de-trabajo-distribuidos

Definiendo unas reglas del juego

• ¿Ventaja de usar git? Su flexibilidad

Si algo no te funciona lo cambias

Ya tenemos reglas del

juego

¿Y ahora qué?

¿Cómo hacemos para

que el pull-request X no

se cargue nada?

¿Cómo hacemos para que

futanito no se cargue lo que yo he hecho?

Comunicación

Testing

Arquitectura y diseño

Integración contínuaConcepto más viejo de

lo que parece (origen en 1991 Grady Booch) Objetivo: eliminar el

“integration hell”¿Cómo? integrando el

trabajo de todo el mundo lo antes

posible… …incorporando/mezclando ramas y ejecutando los tests

AUTOMÁTICAMENTE

Integración contínuaMuy integrado en github

Interesante lista en la wiki pedia…

¿Cómo conectamos el repo con el sistema CI?

git hooks

Hooks• pre-commit: se usa para inspeccionar el snapshot de código, ejecutar

tests, analizadores de código estático…• Si devuelve !=0 no se sigue el flujo

• prepare-commit-msg: permite editar el mensaje por defecto. Útil para commits con mensajes automáticos como merge-commits, squashed commits, amends• argumentos: ruta a fichero con el mensaje, tipo de commit, SHA-1

• commit-msg: Permite validar el mensaje de commit del usuario• Si devuelve !=0 no se sigue el flujo• argumentos: ruta a fichero con el mensaje

• post-commit: se suele utilizar para notificar

commit-workflow hooks

pre-commit

#git commit

if $? != 0

prepare-commit-msg

crear mensaje por defecto

Editar el mensaje de commit

commit-msg

if $? != 0

commit

post-commit

Otros hooks• pre-rebase: antes de empezar el rebase. Se puede utilizar, por ejemplo

para detener el rebase si se está haciendo rebase de commits que ya han sido empujados (pushed)• Si devuelve !=0 no se hace el rebase

• post-checkout: justo después de hacer un checkout. Mover, borrar o descargar ficheros binarios,auto-generar documentación…

• post-merge: después de que se haya realizado un merge• pre-push: después de que se reciba la lista de referencias pero antes de

que se reciban los objetos.• argumentos: nombre y localización del remoto. Lista de ficheros por

STDIN• post-rewrite: se ejecuta por comandos ammend o rebase.

• argumentos: comando. Lista de ficheros por STDIN

Hooks en servidor• pre-receive: se ejecuta antes de recibir nada por parte del cliente. Se

puede usar para hacer control de accesos, impedir recibir referencias que no sean fast-forward, etc• Si devuelve !=0 no se sigue el flujo• Argumentos: lista de referencias que se quieren enviar

• update: muy parecido. Se ejecuta una vez por cada rama que se está recibiendo• Argumentos: referencia (rama), el SHA-1 de inicio y el SHA-1 de destino• Si devuelve !=0 esa rama no se acepta y se sigue con la siguiente

• post-receive: se ejecuta después de que se ha recibido todos los objetos. Se puede usar para notificiaciones, pasear los mensajes y abrir o cerrar tickets.• Argumentos: lista de referencias que se han recibido

Hooks

• Referencias:• https://git-scm.com/book/en/v2/Customizi

ng-Git-Git-Hooks• http://githooks.com/

github, bitbicket, etc,etc,etc…

• En esos servicios no podemos poner scripts a nivel de servidor…

• …podemos utilizar sus webhooks para enterarnos de las cosas que pasan

https://developer.github.com/webhooks/

https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html

¡Ya lo tenemos (casi) todo!

Otras herramientas

Semantic versioning

• Reglas para poner un número de versión al software (build, una librería, etc)

• Más información: http://semver.org/

Semantic versioning• Reglas básicas:

• Versionar el software con una secuencia de tres números X.Y.Z• X aumenta cuando se rompe la compatibilidad hacia

atrás• Y aumenta cuando se añade funcionalidad que es

compatible hacia atrás• Z aumenta cuando hay “fixes” que son compatibles

• La versión 0.Y.Z se utiliza para el desarrollo inicial• La primera versión estable es la 1.0.0

Semantic versioning• Facilita la gestión de dependencias:

¿Es seguro actualizar el paquete X de la versión 1.1.0 a la 1.2.0?

• Permite tener un conjunto de reglas comunes para que todo el equipo numere sus librerías

Revisiones de código

Disponen de herramientas para hacer code review:• Comentar código• Comunicación con

equipo• Revisión de los pull-

request

Revisiones de código• Introducir este tipo de herramientas abre muchas

conversaciones:• ¿Qué tiene que tener y/o cómo tiene que ser el código

para ser considerado aceptable?• ¿Qué herramientas vamos a utilizar para facilitarnos

que todos escribamos el código de la misma manera?… mismo sangrado, misma estructura de ficheros, etc

• ¿Cómo vamos a nombrar las cosas (módulos, paquetes, funciones, métodos, clases, objetos…)?

• ¿Cómo vamos a documentar el código?

Revisiones de código

¿Qué alternativas tenemos?

gerrit

getbarkeeper.org

yo no tengo nada contra gerrit pero…

https://www.mediawiki.org/wiki/Git/Gerrit_evaluation

Pensando en el usuario

Checklist☑ Seleccionar un SCM

☑ Seleccionar un servicio para alojar repositorios

☑ Herramienta de gestión de proyectos: bugs, tareas, scum/kanban, etc, etc, etc

☑ Definir los flujos de trabajo (ir a la presentación del mes que viene)

☑ Documentar e implementar los flujos de trabajo

☑ Herramientas de comunicación: IRC, email, chats…

☑ Arquitectura / Diseño de tests para trabajo en equipo

☑ Sistema de integración continua

☑ Sistema de code review y otras herramientas de calidad (code style tools, etc)

☑ Integración de repositorio con CI y CD (hooks y webhooks)

☑ Distribución de librerías, paquetes y/o módulos

☑ Empezar a trabajar y si algo no funciona ¡Cambiarlo!

¡Gracias!@aalbagarcia@aprendegit

Grupo de usuarios de git en meetuphttp://www.meetup.com/Spanish-Git-Meetup/