Cómo trabajar con un SVN

FeatureBranch
14 de Febrero de 2012
Este artículo es la traducción de un artículo escrito originalmente por Martin Fowler, si encuentras algún error por favor enviameló por mail a ramos.gaston arroba gmail punto com.



Con el surgimiento de los sistemas de control de versión distribuidos (SCVD) como git y mercurial, he estado viendo más conversaciones acerca de estrategias para branchingy merging y qué rol juegan con la Integración Contínua (IC). Hay un poco de confusión aquí, particularmente en la práctica de feature branch y cómo esta encaja en la integración contínua.
Simple (aislada) Feature Branch.
La idea básica de feature branch es que cuando se comienza a trabajar en una feature (característica o historia si prefiere ese término) ud. usa una rama del repositorio paratrabajar en ese feature. En un SCVD, va a hacer esto en su repositorio personal, pero también funciona parecido en un SCV centralizado.
Voy a ilustrar esto con una serie de diagramas. Tengo un proyecto compartido, en color azul, y dos desarrolladores, coloreados en púrpura y verde (los nombres de los desarrolladores son Reverendo Green y Profesor Plum).

Estoy usando cajas de color etiquetadas(ej: P1 y P2) para reprensentar commits locales en el branch. Flechas entre branches para representar merges entre branches, las cajas están coloreadas con naranja para que se destaquen. En este caso hay actualizaciones, digamos un par de bug fixes aplicados a la línea principal (supongamos que son hechos por el Sr Peacock). Cuando esto ocurre nuestros desarroladores lo mergean en su trabajo. Paradarle a esto algún sentido de tiempo, voy a asumir que estamos mirando unos pocos días de trabajo aquí, con cada desarrollador comiteando a su branch local aproximadamente una vez al día.
Para asegurar que las cosas están funcionando correctamente, ellos pueden ejecutar construcciones y tests en su branch. De hecho.voy a asumir que cada commit y merge se lleva a cabo con un build y test automáticoen el branch en el que está.
La ventaja del feature branching es que cada desarrollador puede trabajar en su feature y estar aislado de los cambios que hay en otros lugares. Ellos pueden traerse (pull) los cambios desde la línea principal a su propio ritmo, asegurando de no romper el flujo de su feature. Además de que permite al equipo seleccionar cuales features se van a entregar.
Si elReverendo Green se demora mucho, podemos entregar sólo con los cambios del Profesor Plum. O quizás deseemos retrasar la entrega de la feature del Profesor Plum por que no estamos seguros de que esta funciona de la forma en la que queremos entregarla. En este caso solo le decimos al profesor que no vamos a mergear sus cambios a la línea principal hasta que estemos listos. Esto se llama cherry-picking, elequipo decide cuales son las features que se van a mergear entes de la entrega.
Por más atractiva que se vea la imágen, puede haber problemas en el futuro.

A pesar de que nuestros desarrolladores puedan desarrollar sus features en forma aislada, en algún punto su trabajo va a tener que ser integrado. En este caso el Profesor Plum fácilmente actualiza la línea principal con sus cambios. No haymerge aquí por que él ya ha incorporado los cambios de la línea principal en su propio branch (habrá un build). Sin embargo las cosas no son tan simples para el Reverendo Green, el necesita mergear todos sus cambios (G1-6) con todos los cambios del Profesor Plum (P1-5).
(En este punto muchos usuarios de SCVD podrían sentir que me falta algo o que este es un punto de vista simple o quizássimplista de feature branching. Voy a mostrar un esquema más complicado más adelante).
He hecho esto como una caja grande de merge ya que es el merge del miedo. Podría estar bien, los desarrolladores podrían haber estado trabajando en partes completamente separadas del código base sin interacción, en cuyo caso el merge saldrá bien. Pero podrían haber estado trabajando en partes que interactúan, en...