Embed Size (px)
Citation preview
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
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
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/
