Git: flujos de trabajo y herramientas para trabajo colaborativo
•Descargar como PPTX, PDF•
2 recomendaciones•1,594 vistas
Llevas unos meses dándole vueltas a subir ese parche que has hecho de jquery para corregir ese bug que te tenía loco. O crear ese proyecto en github para subir esa super tarea gulp que tanto os ha ayudado en el proyecto. Sí, te gustaría hacerlo pero no tienes ni idea de por dónde empezar: travis, pull-request, hooks, CI, gerrit, rebases, squashing, semantic versioning... ¿qué es todo eso y para qué sirve?. En esta charla hablaremos de qué herramientas aporta git y github para facilitar esta tarea, cómo podemos organizar nuestros repositorios y flujos de trabajo y os daremos las pautas para que podáis empezar a sacarle el máximo partido a los repositorios de código distribuido. Estas diapositivas corresponden a la charla que se dio en madrid el 26/10/2015 en un meetup conjunto entre los grupos de HTML5 Spain y Spanish git Meetup.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Git: flujos de trabajo y herramientas para trabajo colaborativo
Similar a Git: flujos de trabajo y herramientas para trabajo colaborativo (20)
Último
Último (20)
Git: flujos de trabajo y herramientas para trabajo colaborativo
- 2. Anuncios Grupo 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?
- 3. Git: flujos de trabajo y herramientas para trabajo colaborativo @aprendegit @aalbagarcia
- 6. 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
- 9. Reglas del juego más habituales para proyectos open source
- 10. 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)
- 11. Qué es un pull request
- 12. Qué es un pull request
- 13. 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/
- 18. 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/
- 19. Definiendo unas reglas del juego https://git-scm.com/book/es/v1/Git-en-entornos-distribuidos-Flujos-de-trabajo-distribuidos
- 20. Definiendo unas reglas del juego • ¿Ventaja de usar git? Su flexibilidad Si algo no te funciona lo cambias
- 22. ¿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?
- 24. Integración contínua Concepto 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
- 25. Integración contínuaMuy integrado en github Interesante lista en la wiki pedia…
- 26. ¿Cómo conectamos el repo con el sistema CI?
- 27. git hooks
- 28. 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
- 29. 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
- 30. 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
- 31. 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
- 32. Hooks • Referencias: • https://git-scm.com/book/en/v2/Customizing- Git-Git-Hooks • http://githooks.com/
- 33. 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/manag e-webhooks-735643732.html
- 34. ¡Ya lo tenemos (casi) todo!
- 36. 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/
- 37. 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
- 38. 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
- 39. Revisiones de código Disponen de herramientas para hacer code review: • Comentar código • Comunicación con equipo • Revisión de los pull- request
- 40. 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?
- 41. Revisiones de código ¿Qué alternativas tenemos? gerrit getbarkeeper.org
- 42. yo no tengo nada contra gerrit pero… https://www.mediawiki.org/wiki/Git/Gerrit_evaluation
- 43. Pensando en el usuario
- 44. 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!
- 45. ¡Gracias! @aalbagarcia @aprendegit Grupo de usuarios de git en meetup http://www.meetup.com/Spanish-Git-Meetup/
Notas del editor
- Paralelismo entre participar en un proyecto de software libre y trabajar en un equipo
- Ejemplo en negro: queremos compartir nuestra librería. Ejemplo en blanco: el equipo crece (somos una startup por ejemplo, de momento lo he hecho todo yo y el equipo empieza a crecer)
- Las dos cosas dan un poco de acojone. Para la historia en negro: no publico porque mi código es una mierda Para historia en blanco: pagar nóminas da acojone
- La primera pregunta que nos tenemos que hacer es ¿Qué herramienta queremos utilizar para compartir nuestro código? En negro: para código open-source: seguramente git es una buena opción, aunque mercurial y SVN también son alternativas En blanco: hay que hacerse algunas preguntas ¿en qué estamos desarrollando?¿qué tipo de proyecto vamos a desarrollar? ¿necesitamos muchos assets?
- La primera pregunta que nos tenemos que hacer es ¿Qué herramienta queremos utilizar para compartir nuestro código? En negro: para código open-source: seguramente github es una buena opción. En blanco: hay que hacerse algunas preguntas ¿en qué estamos desarrollando?¿podemos sacar el código de nuestra infraestructura? ¿vamos a compartir el código con nuestros clientes?
- Las reglas del juego más aceptadas cuando se trabaja con git en un proyecto de software libre
- En algunos proyectos, se pide que hagas un squash de varios commits y envíes un sólo commit. Esto se hace para eliminar ruido del repositorio especialmente en aquellos con muchas contribuciones y colaboradores.
- Comentar un poco los flujos de trabajo que se pueden usar y la importancia de definirlos.
- Sacado de pro-git. capítulo 5
- Comentar un poco los flujos de trabajo que se pueden usar y la importancia de definirlos.
- Lo normal es que: Proyecto open source: alguien nos envíe mejoras, correcciones de bug, etc. Equipo de trabajo: Tenemos que empezar a trabajar juntos. Eso nos va a añadir nuevas cosas a tener en cuenta. Preguntar ¿qué cosas se os ocurren?
- Esta es una de las primeras decisiones que tenemos que tomar. Qué herramientas vamos a utilizar para responder a esta pregunta.
- Estas son algunas de las herramientas que podemos utilizar para resolver este problema. La primera posiblemente es la más importante. En open source se soluciona con listas de correo, issues de github, etc. En tu proyecto, a lo mejor una solución mucho más mundana y sencilla como por ejemplo ‘hablar con el compañero’, es suficiente. No voy a entrar en la discusión de los tests. Aportan muchas cosas, entre ellas facilitar el que más de una persona pueda tocar el mismo código. También hay decisiones de diseño y arquitectura de la aplicación que facilitan esta tarea. Por ejemplo, a niveles de aplicaciones grandes, el desarrollo en microservicios (no quiero polémicas). A niveles más mundanos, el desarrollo en componentes. Por ejemplo, desarrollo de symfony1 monolítico con respecto a symfony2 basado en bundles. RAILS desarrolla todo basado en gemas. Permite equipos independientes, desarrollos en paralelo, etc. Todas estas soluciones no son excluyentes, son complementarias. Todas tienen su coste…
- Bien, hemos decidido que vamos a hacer tests automatizados. ¿Cómo los hacemos? https://en.wikipedia.org/wiki/Continuous_integration Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies to a shared mainline several times a day. It was first named and proposed by Grady Booch in his 1991 method,[1] although Booch did not advocate integrating several times a day. It was adopted as part of extreme programming (XP), which did advocate integrating more than once per day, perhaps as many as tens of times per day. The main aim of CI is to prevent integration problems, referred to as "integration hell" in early descriptions of XP. CI isn't universally accepted as an improvement over frequent integration, so it is important to distinguish between the two as there is disagreement about the virtues of each.[citation needed] In XP, CI was intended to be used in combination with automated unit tests written through the practices of test-driven development. Initially this was conceived of as running all unit tests in the developer's local environment and verifying they all passed before committing to the mainline. This helps avoid one developer's work-in-progress breaking another developer's copy. If necessary, partially complete features can be disabled before committing using feature toggles. Later elaborations of the concept introduced build servers, which automatically ran the unit tests periodically or even after every commit and report the results to the developers. The use of build servers (not necessarily running unit tests) had already been practised by some teams outside the XP community. Nowadays, many organisations have adopted CI without adopting all of XP. In addition to automated unit tests, organisations using CI typically use a build server to implement continuous processes of applying quality control in general — small pieces of effort, applied frequently. In addition to running the unit and integration tests, such processes run additional static and dynamic tests, measure and profile performance, extract and format documentation from the source code and facilitate manual QA processes. This continuous application of quality control aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. This is very similar to the original idea of integrating more frequently to make integration easier, only applied to QA processes. In the same vein, the practice of continuous delivery further extends CI by making sure the software checked in on the mainline is always in a state that can be deployed to users and makes the actual deployment process very rapid.
- Bien, hemos decidido que vamos a hacer tests automatizados. ¿Cómo los hacemos?
- Ok, esto es lo mínimo que necesitamos para empezar a trabajar…¿qué más podemos hacer?
- Si estás trabajando en un proyecto de software libre, posiblemente esto sea lo que utilices
- Esto no es es sólo poner la herramienta y ya está. Tened en cuenta que siempre que añades una herramienta debe ser para algo y debe aportar algo.
- Alternativas a gerrit
- Esto no es es sólo poner la herramienta y ya está. Tened en cuenta que siempre que añades una herramienta debe ser para algo y debe aportar algo.