Gestión de la configuración de software: estándares, mejores prácticas y herramientas para Agile y DevOps

[ad_1]

Toda organización de alto funcionamiento tiene un «plan maestro» que detalla cómo operar y realizar las tareas. El ejército tiene organigramas. Los contratistas de construcción tienen un cronograma de ruta crítica. Las matemáticas (no una organización, lo sé) tienen un orden de operaciones.

El mundo del desarrollo de software no es diferente. Si bien existen muchas metodologías de gestión de proyectos y herramientas de monitoreo del desempeño, existe un sistema que lo define todo. Este sistema se denomina gestión de configuración de software.

¿Qué es la gestión de la configuración de software?

La gestión de configuración de software (SCM) es un conjunto de procesos, políticas y herramientas que organizan el proceso de desarrollo. Simultáneamente mantiene el estado actual del software (llamado «línea de base»), mientras permite a los desarrolladores trabajar en nuevas versiones para funciones o correcciones.

Sin SCM, el código fuente estaría tan fragmentado y desorganizado que el desarrollo sería imposible sin romper las partes principales de la aplicación. Escalar tu equipo de desarrollo sería una pesadilla, porque no habría forma de organizar el trabajo de los desarrolladores individuales. El desarrollo de software sería lento, propenso a errores y frustrante para todos los involucrados.

Técnicamente, cada equipo emplea alguna forma de SCM, lo quiera o no. El propósito de este artículo, sin embargo, es definir un SCM efectivo y discutir cómo lograrlo. El objetivo de SCM es mejorar la velocidad y la calidad del desarrollo de software, identificando errores con anticipación y permitiendo correcciones rápidas cuando ocurren.

Estándares de gestión de configuración de software

La estructura de gestión de la configuración de software se compone de una serie de «estándares» que crean un organigrama para el desarrollo de software. Cada estándar representa una etapa en la que el código se escribe, prueba o integra en otro estándar y, finalmente, se lanza como una nueva versión del software.

Steve Berczuk es un ingeniero de FitBit que literalmente escribió el libro sobre estándares de gestión de configuración de software. Describe 16 estándares diferentes que trabajan juntos para ayudar a los equipos ágiles a administrar sus configuraciones de software. A continuación se muestra una vista previa de los estándares establecidos por Berczuk.

Gráfico de patrones de SCM del libro de Berczuk, Patrones de gestión de configuración de software: trabajo en equipo eficaz, integración práctica. Fuente

Hay 3 categorías de patrones según Berczuk: patrones principales, patrones de espacio de trabajo y patrones de línea de código.

Estándares fundamentales

Los principales estándares definen el estado actual del software. El patrón principal en la estructura de SCM es la «línea principal», que es la línea de código liberada para la implementación. Todos los cambios realizados por los desarrolladores se canalizan finalmente a ese único flujo de código.

Pero, ¿qué pasaría si varios desarrolladores intentaran realizar cambios en la línea principal al mismo tiempo? Lo más probable es que alguien rompa el software porque sus cambios no se integraron con los cambios de los demás. Aquí es donde el SCM comienza a desempeñar un papel.

En SCM efectivo, existen otros estándares que aseguran que la línea principal no se rompa. La primera línea de defensa es la «línea de desarrollo activo». La línea de desarrollo activa es el esquema de trabajo de la línea principal. Es un componente crucial del desarrollo ágil porque permite a los equipos desarrollar y lanzar cambios con más frecuencia, con un riesgo reducido de romper la línea principal.

Estándares del espacio de trabajo

Los patrones del espacio de trabajo son donde tiene lugar el desarrollo real. Estos patrones alimentan la línea de desarrollo activo y, eventualmente, la línea principal. El patrón del espacio de trabajo principal se denomina «espacio de trabajo privado», donde los desarrolladores individuales pueden replicar la línea principal y realizar cambios sin afectar a otros desarrolladores.

Otros estándares impulsan el escritorio privado y permiten a los desarrolladores crear, integrar y probar a lo largo del camino. Estos estándares incluyen:

• Construcción privada
• Construcción de integración
• Pruebas de humo
• Pruebas unitarias
• Pruebas de integración

Para obtener más información sobre cada uno de estos patrones, consulte el excelente artículo de Berczuk sobre DZone

Políticas de línea de código

Cada estándar requiere un conjunto de reglas y pautas para seguir siendo efectivo. Se denominan políticas de línea de código. Las políticas de línea de código también determinan qué pruebas e integraciones deben ocurrir antes de que se publique el código. Estos requisitos deben automatizarse tanto como sea posible, como las pruebas de automatización en la construcción de la integración.

Los estándares de la línea de código describen la línea de desarrollo principal. Estos patrones también se denominan «ramas». Fuente

Línea de patrones de código (también conocidos como ramas)

Los patrones centrales y los patrones del espacio de trabajo representan una única ruta de desarrollo o una única versión. Es como un río donde los barcos se detienen en los puertos a lo largo de las orillas para abastecerse y verificar su stock. Los patrones en la línea de código son como arroyos y arroyos que alimentan el río. Están separados de la ruta de desarrollo principal y también se denominan ramas.

Las ramas se utilizan cuando las actividades pueden desestabilizar la línea principal o ralentizar considerablemente el desarrollo. Deben usarse con poca frecuencia y cumplir con una estricta línea de políticas de código para garantizar que se usen correctamente. Ejemplos de cuándo debe usar una extensión incluyen:

1. Asegúrese de tener la versión actual del software mientras trabaja en una nueva versión
2. Trabajando en un cambio grande y significativo
3. Empiece a trabajar en una nueva versión antes de que se complete la versión actual

Mejores prácticas de gestión de la configuración de software

Junto con un diagrama de patrones organizativos, la SCM eficaz se basa en un conjunto de principios. Si estos principios le parecen familiares, no se equivoca. Están mapeados muy de cerca a varios principios ágiles.

1.El desarrollo debe realizarse con la menor cantidad de líneas de código posible

Uno de los principales valores de SCM es eliminar los problemas de redundancia e integración. El enfoque estándar de su equipo para el desarrollo debería ser utilizar la menor cantidad de líneas de código posible, diversificándose solo cuando surjan ciertas advertencias.

2. Prueba temprano y con frecuencia

Las pruebas son fundamentales para una buena gestión de la configuración del software. Cada patrón representa una oportunidad de prueba antes de que se publique el código para el siguiente patrón en la jerarquía. Las pruebas de rendimiento se pueden realizar directamente en su estación de trabajo con herramientas de rendimiento de preproducción como Prefix.

3. Integrar temprano y con frecuencia

Los espacios de trabajo privados son esenciales porque permiten a los desarrolladores probar la integración antes de integrarse realmente en la línea principal. Los desarrolladores también necesitan integrar con frecuencia la línea principal con su estación de trabajo para tener en cuenta los cambios.

4. Utilice herramientas para automatizar las pruebas, la construcción y la integración.

Hay docenas de herramientas que ayudan a los equipos a automatizar aspectos críticos del proceso de desarrollo. Hablaremos más sobre estas herramientas en la siguiente sección.

Herramientas de gestión de configuración de software

Steve Berczuk identifica cinco categorías de herramientas que necesitará para una gestión eficaz de la configuración del software:

Repositorio de gestión de código fuente

Esta herramienta servirá como su repositorio de código fuente y lo ayudará a administrar sus versiones de software. Utilizará este sistema para replicar el estado de la línea principal para su espacio de trabajo privado y nuevas sucursales. Los ejemplos de sistemas de gestión de código fuente incluyen Git, Subversion y Mercurial.

Construcción de integración continua / herramienta de servidor

Aunque la construcción y la integración continua son dos funciones separadas, muchas herramientas hacen ambas cosas. Estas herramientas convertirán su código fuente en un artefacto, lo probarán en busca de errores y lo integrarán con estándares de nivel superior. Las herramientas incluyen Jenkins, Bamboo, TeamCity, Maven, Puppet y Chef. Tenga en cuenta que no todas estas herramientas tienen funciones de superposición y se pueden utilizar varias al mismo tiempo.

Sistema de documentación

Un sistema de documentación contendrá todas las políticas en la línea de código. Un Wiki simple servirá, o una ubicación conocida en su repositorio de SCM.

Repositorio de artefactos

Los repositorios de artefactos le permiten a su equipo almacenar, organizar y distribuir artefactos de software, no solo el código fuente. Según Automic, los repositorios de artefactos son esenciales para «reducir errores y garantizar que se incluyan las piezas correctas en cada construcción / implementación / lanzamiento». Las herramientas de repositorio de artefactos incluyen Artifactory, Nexus y Archiva.

Mejorando la gestión de la configuración de software en su empresa

Mejorar el SCM en su empresa significa mejorar sus estándares, procesos y herramientas para la entrega de software. Como cualquier buena práctica ágil, debe comenzar por identificar las principales prioridades de su organización.

Los estándares SCM son la parte más fundamental de la gestión de la configuración del software. Si sus estándares están mal definidos, los procesos y herramientas no ayudarán. Los estándares deben ser su prioridad.

Los procesos como las políticas de línea de código y las pruebas automatizadas son casi tan importantes como los propios estándares. Asegúrese de que todos los miembros de su equipo conozcan los procesos para trabajar con los estándares de SCM.

Finalmente, observe su pila de herramientas para ver las posibilidades de mejorar la eficiencia. Este debería ser el último paso para mejorar su SCM, porque las herramientas solo funcionarán si las configura para eso.

Aquí en Tutoriales Java, nos apasiona la agilidad, la automatización y la creación de un mejor software. Siga nuestro blog para obtener más información sobre estas prácticas y más.

[ad_2]