¿Qué es el desarrollo paralelo o concurrente?

El desarrollo concurrente o en paralelo provee de los mecanismos necesarios para aislar una versión de un desarrollo software con el objeto de realizar modificaciones a esta sin alterar otras versiones que puedan coexistir en ese momento, puesto que cubre la necesidad de realizar cambios simultáneos con distintos objetivos en una misma aplicación. Un ejemplo típico de desarrollo en paralelo es el desarrollo correctivo o mantenimiento y el desarrollo evolutivo.

El valor de esta técnica no está en la capacidad de abrir múltiples líneas de desarrollo en paralelo, ya que no aporta ningún valor una línea de desarrollo que diverge indefinidamente respecto a su línea principal sin propagar cambio alguno, si no, que está en la integración o fusión de los cambios implementados en su línea principal de desarrollo.

Pero esta integración no es gratuita y tiene costes y tareas implícitas que muchas veces se omiten a la hora de definir una política de desarrollo en paralelo.

Esta forma de trabajo se basa en la utilización de ramas, líneas base y en procesos de integración y promoción de software.

• Una rama es una instancia aislada o línea de desarrollo con un objetivo definido que parte de una línea base existente.
• Una línea base es un conjunto de elementos de configuración en un punto del tiempo. (vista estática)
• La consolidación es la integración de dos líneas de desarrollo o ramas.
• La promoción consiste en desplegar o implantar software en un entorno físico.

De cara a definir la política de desarrollo en paralelo que realmente cubra nuestras necesidades hay que considerar estos aspectos:

• Tiempo: Es el factor que mayor influencia tiene ya que conforme más tiempo pase entre integraciones la posibilidad de encontrar más cambios será mayor, por lo tanto la integración será más compleja y requerirá mayor esfuerzo.
• Riesgo en la estabilidad: Cuando se integra una modificación implementada en una rama de desarrollo provoca que la línea principal de esa aplicación no sea estable, ya que hasta que no se haya probado completamente e implantado en Producción se tendrá que considerar como una versión del software en vuelo.

Por lo que antes de definir nuestra política de desarrollo concurrente o en paralelo tendremos en cuenta estas buenas prácticas:

• No abrir ramas, esta debe de ser la mentalidad del equipo de trabajo, es decir, como objetivo no se debe abrir una rama salvo que exista un motivo que justifique su creación. Lo importante es tener claro que si necesitamos llevar a cabo dos o más propósitos debemos aislarlos en líneas de desarrollo independientes que se hayan creado a partir de la misma línea base. Estos propósitos pueden ser:
  • Trabajar en dos o más “releases” al mismo tiempo.
  • Trabajar en una nueva “release” al mismo tiempo que en arreglos de incidencias o parches para releases anteriores.
  • Trabajar con otros “sites” (“site specific branch”)
  • Trabajo concurrente sobre el mismo “site” (“shared branch”)
  • Trabajo dentro de workspaces privados(“user specific private branch”)
• Consolidar a menudo y lo antes posible las ramas entre sí de forma que evitemos que la complejidad aumente, el esfuerzo disminuya y la estabilidad aumente, ya que habrá menos cambios por lo que las modificaciones a integrar serán menos y normalmente más sencillas.
• Hacer uso de un motor de “Integración Continua” ya que reduce significativamente el tiempo necesario para validar una versión del software integrada, lo que nos permite reducir el tiempo de inestabilidad.
• Identificar los motivos por los cuales se actualizan ficheros y crear las líneas base en función de estas peticiones.

Es imprescindible el uso de una herramienta que ofrezca un buen soporte a esta técnica de ingeniería de software ya que será la que permita realizar la integración o fusión de múltiples líneas de desarrollo de forma sencilla y segura.

Esta herramienta debe de ofrecer, como mínimo, los siguientes mecanismos para garantizar la integración de los cambios.

• Creación de ramas y su independencia.
• Comparación de ramas identificado las siguientes casuísticas:
  • Creación de elementos en alguna o en ambas de las ramas.
  • Borrado de elementos en alguna o en ambas de las ramas.
  • Movimiento de elementos en alguna o en ambas de las ramas.
  • Borrado de elementos en alguna o en ambas de las ramas.
• Integración automática y manual de los cambios, tanto a nivel de rama como de fichero.

Recomendaciones

Para definir una política de desarrollo en paralelo hay que especificar claramente cuándo y cómo se van a realizar los “check-out”, “check-in”, la integración de los cambios e y su implantación.

Dentro de estas definiciones es conveniente tener en cuenta los siguientes aspectos:

• “Mainline” o línea principal de desarrollo: El resto de líneas de desarrollo acabarán integrándose contra esta línea principal que contendrá todos los cambios.

• Propiedad de las líneas de desarrollo: Asignar a un responsable para cada línea que sea capaz de asegurar la integridad y la consistencia de dicha línea.
• Integrar pronto y frecuentemente: Integrar los cambios de una rama a su línea de desarrollo tan pronto como los cambios en la rama se hayan completado y probado

• Restringir el acceso a las líneas: Al determinar la política de ramas se debe plantear el control de acceso a ésta.
• Control de ejecutables o artefactos a implantar:
  • “Vault” o librería de medios: Repositorio en el que se almacenará todos los artefactos generados que son susceptibles de ser instalados en Producción.
  • Bill of Materials: Se puede construir un ejecutable correctamente, pero puede ser necesario generar exactamente el mismo ejecutable en el futuro, por lo que será necesario identificar todos los elementos que participaron en la construcción.
  • Build Reproducible: Todos aquellos procesos de compilación que se utilizan, deben poder ser reproducidos en el futuro, por lo que habrá que almacenar cómo se construyen los artefactos.
  • Caché de Objetos Compartidos: Permite a los desarrolladores llevar a cabo builds locales basados en archivos extraídos del repositorio y un conjunto común de archivos objeto o librerías.
• Código Fuente Compartido: Mantener y soportar un conjunto común de código utilizado por más de un proyecto.

Patrones de CM

En el libro “Software Configuration Management Patterns: Effective Teamwork, Practical Integration” de Steve Berczuk y Brad Appleton (http://www.scmpatterns.com/book/) se detallan los patrones a aplicar durante la definición de la política de desarrollo en paralelo que se adapte a nuestras necesidades.

En el siguiente link se puede descargar una guía rápida de estos patrones: Quick Reference Card for the Software Configuration Management Pattern Language

Conclusiones

El desarrollo en paralelo es una de los mecanismos más potentes de cara al desarrollo de software ya que permite a una organización trabajar simultáneamente en varios cambios y decidir posteriormente cuando se implantará estos en Producción.