El código fuente es un activo vital para cualquier equipo de desarrollo de software. Las herramientas de gestión de código fuente sirven para rastrear cambios, lo que facilita la recreación de versiones anteriores del software y ver cómo se desarrolla con el tiempo.
También sirven para coordinar a un equipo de programadores que trabajan en un código base común. Al registrar los cambios que cada desarrollador realiza, estos sistemas pueden hacer un seguimiento de múltiples líneas de trabajo al mismo tiempo y ayudar a los desarrolladores a fusionar estas líneas de trabajo.
Se han desarrollado varios patrones para ayudar a manejar la división del desarrollo en líneas de trabajo que se dividen y fusionan en el flujo de trabajo (workflow) de los equipos de desarrollo de software.
Estos patrones no son estándares definitivos. El flujo de trabajo del desarrollo de software depende en gran medida del contexto, especialmente de la estructura social del equipo y otras prácticas que el equipo siga.
Git permite cambiar la historia a base de commits. Otros SCV no.
Git representa los commits como snapshots, no como diffs. Eso hace que sea más rápido, pero ocupa más espacio.
Staging es añadir ficheros al próximo commit.
En Mercurial, cada rama requiere su propio directorio
En Git, cada rama es un puntero a un commit, todo dentro de un único directorio
En Mercurial, cambiar de rama es cambiar de directorio
En Git, cambiar de rama es cambiar el contenido del directorio (haciendo checkout)
Mercurial tiene named branches (permanentes) para ramas dentro de un mismo directorio
En Git las ramas son temporales y se borran cuando se fusionan
En GitHub Flow:
- los desarrolladores trabajan con Feature branching
- la Mainline integration usa PR (Pre-integration review)
- no hay Continuous integration
M1 es un push de algún otro desarrollador
El merge final de violeta es más complicado
Hacer pull "de vez en cuando". ¿Cada cuánto?
Una estrategia de branching para equipos comerciales no tiene por qué ser la misma que en el mundo open-source.
CI es casi imposible para los contribuidores ocasionales al open-source, pero es una alternativa realista para el trabajo comercial.
Las nuevas features no se añaden a la release, sino a la mainline
Los desarrolladores solo se preocupan de la release para arreglar defectos urgentes (hotfixes)
Los hotfixes se aplican a la release y se fusionan en la mainline (¡Recordarlo!)
Release: explícita en Git Flow; no necesaria en GitHub Flow
Algunos productos tendrán muchas versiones presentes en producción.
El software que se ejecuta en el equipo de los clientes solo se actualizará cuando el cliente lo desee.
Muchos clientes son reacios a actualizar por nuevas características.
Pero siguen queriendo correcciones de errores, especialmente si implican problemas de seguridad.
Se mantienen abiertas varias ramas para cada release y se aplican los hotfixes según sea necesario.
Hotfix: explícita en Git Flow; no necesaria en GitHub Flow
Aplicar hotfix primero a producción y luego a la mainline
También a la release branch si hay una abierta
Si el equipo usa release branches, los cambios del hotfix se puede hacer en la release branch y se hace una nueva release.
Esto convierte la antigua release branch en una hotfix branch.
Si se hace CD, se pueden lanzar hotfixes directamente desde la mainline.
Se lanza la hotfix desde el último commit, no desde del último released.
La nueva release se etiqueta como 2.2.1, ya que si un equipo trabaja así es probable que M4 y M5 no incluyan nuevas características. Si lo hacen, entonces el hotfix se incluirá en una release 2.3.
No permitir commits en la mainline hasta que el hotfix esté completado.
Los de QA quieren conocer la versión última del producto
Una vez que el codebase llegue a un cierto nivel de preparación, se copia a una rama específica: v.g. production
A veces basta con usar bien el tagging en vez de una maturity branch separada
En Git Flow, la rama master es la maturity branch para producción
Cambios en una URL, en la configuración de acceso a la BD, ubicación del sistema de mensajería, etc.
Release train:
- variación: trenes futuros
- releases regulares desde la mainline
Release train:
- variación: trenes futuros
- releases regulares desde la mainline
Release train:
- variación: trenes futuros
- releases regulares desde la mainline
- En GitFlow hay release branches, luego no hay una release-ready mainline;
- En GitHub Flow solo hay una versión en producción, que se integra como Release-ready mainline