¿Cada cuánto integra el incremento tu equipo de desarrollo? Consejos para facilitar la integración en Scrum
La razón principal por la que los equipos necesitan alinearse es porque tienen cambios que afectan a otras partes de la organización, en otras palabras, dependencias entre equipos o desarrollos. El primer consejo innovador es el concepto de release train. Es un ciclo de release preplanificado y con una cadencia temporal establecida para habituar a los equipos a integrar código de manera regular y así disminuir riesgos. A partir de este punto, surge una primera pregunta a realizar a un equipo de desarrollo que se plantee el release train qué es: ¿Cómo de maduros estamos con nuestro control de versiones para gestionar las releases? ¿Usamos control de versiones distribuido?
A partir de ahí se abre un universo de herramientas y servicios a tener en cuenta. Los grandes servicios de cloud soportan GIT pero no controles centralizados como subversion. Así que otra recomendación es migrar a GIT para usar todas las nuevas posibilidades que GIT proporciona para mejorar las integraciones de código. La problemática que surge en la migración siempre es la siguiente: ¿Queremos mantener el log de commits o podemos salir limpios con GIT?
Cada bolita es un commit y en un entorno de integración continua va a disparar un build. A nivel del espacio de trabajo del desarrollador, el GITflow se traduce en esto:
Aquí se introduce el concepto más novedoso, el de pull request. Se puede pensar en una pull request como el deseo o la intención de incorporar nuevos cambios en un repositorio. Si es un miembro del equipo de desarrollo el que tiene que hacer algunos cambios en un repositorio, puede hacer esos cambios en forma de commit individuales (las bolitas de la rama feature por ejemplo) y luego abrir una pull request para informar a los otros desarrolladores sobre los cambios que desean realizar. Una vez que se abre una pull request, se puede discutir y revisar los cambios potenciales con cada miembro del equipo de desarrollo y agregar commits de mejora antes de que los cambios se fusionen en el repositorio. Esta práctica fomenta la transparencia y hace madurar al equipo de desarrollo de manera importante. El único problema que tiene es el de los merge, las fusiones de código pueden llegar a ser muy complejas.
La idea básica es hacer el merge en local un tu copia de trabajo y a partir de ahí solventar conflictos con la rama destino en tu working copy local. Cuando los tengamos solventados, subimos el código a la rama remota origen para hacer el merge a la rama remota de destino. Recomiendo que esta acción se lleve a cabo con un gestor gráfico, ya sea una interfaz gráfica como GitKraken o SourceTree o desde una interfaz web como Bitbucket o Gitlab.
Contenidos del artículo
La integración es clave para Scrum
En los últimos años, viendo problemáticas de desarrollo en varias organizaciones, he podido constatar el drama de hacer una release y la gestión de las integraciones de código fuente. La mayor problemática siempre es la integración, que sobretodo se acentúa si hay más de un equipo de desarrollo implicado en esa integración. Dejadme comentar cómo podríamos plantear un entorno de integración continua con varios equipos que gestionan una release integrada de producto.
La razón principal por la que los equipos necesitan alinearse es porque tienen cambios que afectan a otras partes de la organización, en otras palabras, dependencias entre equipos o desarrollos. El primer consejo innovador es el concepto de release train. Es un ciclo de release preplanificado y con una cadencia temporal establecida para habituar a los equipos a integrar código de manera regular y así disminuir riesgos. A partir de este punto, surge una primera pregunta a realizar a un equipo de desarrollo que se plantee el release train qué es: ¿Cómo de maduros estamos con nuestro control de versiones para gestionar las releases? ¿Usamos control de versiones distribuido?
Control de versiones distribuido
Para contestar la pregunta, primero comentar que en el desarrollo de software, el control de versiones distribuido es una forma de control de versión donde el código fuente completo, incluido todo su historial, se refleja en la estación de trabajo de cada desarrollador. Esto permite que las operaciones de branching y merging se gestionen de manera más eficaz, aumentando la velocidad de la mayoría de las operaciones relacionadas con la gestión del código.
A partir de ahí se abre un universo de herramientas y servicios a tener en cuenta. Los grandes servicios de cloud soportan GIT pero no controles centralizados como subversion. Así que otra recomendación es migrar a GIT para usar todas las nuevas posibilidades que GIT proporciona para mejorar las integraciones de código. La problemática que surge en la migración siempre es la siguiente: ¿Queremos mantener el log de commits o podemos salir limpios con GIT?
Migración a GIT
Empezamos respondiendo a las preguntas anteriores. Si la respuesta es mantener el log, lo mejor es usar algunas herramientas que harán la migración más llevadera como usar Git svn, aquí hay un ejemplo Si nos desprendemos del histórico, la migración es inmediata, ya empezamos a hacer todo lo necesario con GIT. Si sóis un equipo que queréis empezar con GIT, los mejores tutoriales son los siguientes: Cuando somos un equipo usando GIT, surgen los problemas de integración propios de GIT, así que nos hará falta un flujo de trabajo.Flujo de trabajo en GIT
La primera idea, la que surge más natural, para un equipo de desarrollo es siempre adaptar el GITflow y a partir de aquí surge el problema de gestión de las ramas.
Cada bolita es un commit y en un entorno de integración continua va a disparar un build. A nivel del espacio de trabajo del desarrollador, el GITflow se traduce en esto:
Aquí se introduce el concepto más novedoso, el de pull request. Se puede pensar en una pull request como el deseo o la intención de incorporar nuevos cambios en un repositorio. Si es un miembro del equipo de desarrollo el que tiene que hacer algunos cambios en un repositorio, puede hacer esos cambios en forma de commit individuales (las bolitas de la rama feature por ejemplo) y luego abrir una pull request para informar a los otros desarrolladores sobre los cambios que desean realizar. Una vez que se abre una pull request, se puede discutir y revisar los cambios potenciales con cada miembro del equipo de desarrollo y agregar commits de mejora antes de que los cambios se fusionen en el repositorio. Esta práctica fomenta la transparencia y hace madurar al equipo de desarrollo de manera importante. El único problema que tiene es el de los merge, las fusiones de código pueden llegar a ser muy complejas.
¿Cómo solucionar el merge en GIT de una pull request?
Una recomendación para solucionar los problemas de merge que surjan en tu equipo de desarrollo se adjuntan en este pequeña infografía.
La idea básica es hacer el merge en local un tu copia de trabajo y a partir de ahí solventar conflictos con la rama destino en tu working copy local. Cuando los tengamos solventados, subimos el código a la rama remota origen para hacer el merge a la rama remota de destino. Recomiendo que esta acción se lleve a cabo con un gestor gráfico, ya sea una interfaz gráfica como GitKraken o SourceTree o desde una interfaz web como Bitbucket o Gitlab.
¿Cómo puede madurar la integración del código de tu equipo de desarrollo?
ITNOVE ofrece el curso Professional Scrum Developer, oficial de Scrum.org, para mejorar la profesión y el delivery del equipo de desarrollo. Los equipos Scrum que atiendan el curso tendrán la oportunidad de mejorar / practicar / perfeccionar / aprender / crecer en las siguientes áreas:- Habilidades técnicas trabajando en un espacio de colaboración, haciendo peer programming
- Habilidades interpersonales a través de la conversación diaria y la interacción humana
- Habilidades de presentación al tener que mostrar software en funcionamiento cada dos o cuatro semanas
- Habilidades de relación al tener que trabajar con personas
- Habilidades de liderazgo al enseñar a otros una perspectiva única sobre cómo resolvió algunos retos del pasado
- Confianza en sí mismo saliendo de su zona de confort
- Conciencia de sí mismo al comprender qué acciones, o inacciones, tienen algunas decisiones sobre los demás y en el incremento que se está construyendo
- Habilidades de comunicación, tanto verbales como no verbales, a través de eventos, reuniones de demostración de clientes, reuniones de planificación de sprint
- Habilidades de estimación al comprender mejor todo el sistema a través de las prácticas de estimación colaborativa y propiedad colectiva de código.
- Mejora continua al tener la disciplina y la confianza en su equipo para permitir que los elementos anteriores se conviertan en una realidad
¿Quieres recibir más información y recursos de calidad?
¡Suscríbete a nuestra newsletter mensual!
Cada mes enviamos una newsletter a más de 1.500 personas con contenidos, recursos y ofertas especiales de nuestros cursos. Queremos ofrecer contenido de calidad y sin spam.
