Prácticas recomendadas de gestión de versiones de software I DevTeam.Space

¿Quiere conocer algunas de las mejores prácticas de administración de versiones de software?

Has venido al lugar correcto.

Obtener la versión correcta de su software es uno de los puntos clave para garantizar que su aplicación sea un éxito. Una aplicación exitosa significa muchas ganancias.

La gestión de versiones es una disciplina relativamente nueva pero de rápido crecimiento dentro de la ingeniería de software. A medida que los sistemas, los procesos de desarrollo de software y los recursos se distribuyen más, invariablemente se vuelven más especializados y complejos.

Además, los productos de software (especialmente las aplicaciones web) normalmente «nunca se terminan» y, a menudo, se encuentran en un ciclo continuo de proceso de desarrollo, prueba y lanzamiento, a menudo ejecutándose en plataformas en evolución con una complejidad creciente.

El envío de productos desde el desarrollo hasta la prueba del sistema y la prueba de aceptación del usuario a menudo requiere recursos dedicados para supervisar la integración y el flujo de desarrollo, prueba, implementación y soporte.

En este artículo, dirigido a profesionales involucrados en proyectos de desarrollo de software, exploramos las mejores prácticas exitosas de gestión de versiones y algunos de estos procesos. Este artículo será de interés para los desarrolladores, analistas de pruebas, gerentes de desarrollo y lanzamiento, CTO y el equipo de operaciones de TI responsable del envío de productos de software.

Por qué la gestión de versiones

Exploremos solo algunas de las razones por las que podría querer adoptar un proceso de gestión de versiones más formal para sus proyectos de software.

Hace que el envío de productos sea más predecible y confiable

La implementación manual de versiones es dolorosa y siempre contiene un elemento de riesgo. La introducción de una gestión de lanzamiento formal elimina muchos de los gastos generales asociados con la publicación y lanzamiento manual de software.

Al introducir herramientas como Visual Studio Team Services o Jenkins, puede automatizar sus lanzamientos, haciéndolos así más predecibles y confiables.

Gestión de la configuración

Considere por un minuto, está implementando un sitio web ASP.NET, es posible que tenga una configuración de aplicación específica del entorno en el archivo web.config (cadena de conexión, etc.). Naturalmente, estos deben cambiar cada vez que se publica un comunicado.

Los cambios de configuración como estos pueden ser difíciles de rastrear manualmente a medida que promociona su sitio web a través de la ruta de lanzamiento.

Release Management elimina este dolor y puede manejarlo por usted al parametrizar los valores de configuración en tiempo de ejecución cuando se publica el lanzamiento.

Mejora la calidad del software

Exploraremos esto con más detalle en una sección posterior, pero la incorporación de la integración continua en su proceso de gestión de versiones puede mejorar la calidad de su producto de software.

Cada vez que un desarrollador verifica el código, el conjunto de CI puede invocar un conjunto de pruebas unitarias, ejecutar y analizar la calidad del código (según los estándares definidos por el equipo) e informar esto, casi de inmediato, al desarrollador que realizó el registro de código.

Centrándonos en lo que importa

Release Management permite que cada función se concentre en el trabajo que importa, es decir, los desarrolladores pueden escribir código mientras que los analistas de pruebas pueden ejecutar y escribir planes de prueba automatizados. Es difícil ignorar el ciclo de retroalimentación casi instantáneo que la administración de versiones brinda a los equipos de desarrollo de software.

Los desarrolladores pueden recibir una notificación si un cambio ha roto algo y los analistas de pruebas pueden encontrar errores antes de que se envíen formalmente las versiones de software.

Tiempo de comercialización más rápido

Las compilaciones automatizadas y predecibles, la calidad mejorada del código, la gestión de la configuración y las pruebas unitarias automatizadas se suman al ahorro de tiempo y, por lo tanto, ofrecen un tiempo de comercialización más rápido.

Por supuesto, la implementación de la gestión formal de versiones y los procesos de entrega continua en su ciclo de vida de entrega de software puede tomar tiempo inicialmente para configurarse, pero puede generar dividendos masivos a largo plazo.

Con estos puntos en mente, exploremos las mejores prácticas de administración de versiones de software.

Mejores prácticas de administración de versiones de software

Entornos

Lo primero en las mejores prácticas de administración de versiones de software es decidir la arquitectura del entorno que desea adoptar.

Las arquitecturas de implementación pueden variar. Una arquitectura común de 4 niveles es DEV, TEST, STAGING y PROD. O para darles sus nombres completos, desarrollo, prueba del sistema, puesta en escena y producción.

Sus productos de software deben hacer la transición en orden de DEV a PROD. Es posible que desee agregar un entorno de prueba de aceptación del usuario que se encuentre entre STAGE y PROD.

Hacerlo le permite al cliente validar la prueba del sistema posterior al lanzamiento realizada por su equipo y le permite lanzar el software solo después de que el cliente haya otorgado el estado de «listo para producción».

Desarrollo

El entorno de desarrollo (dev) es el entorno en el que se desarrollan los cambios en el software, más simplemente la estación de trabajo de un desarrollador individual.

El entorno para el proceso de desarrollo de software difiere del entorno de destino final de varias maneras: el objetivo puede no ser una computadora de escritorio (puede ser un teléfono inteligente, un sistema integrado, una máquina sin cabeza en un centro de datos, etc.).

Incluso si es similar, el entorno del desarrollador incluirá herramientas de desarrollo como un compilador, un entorno de desarrollo integrado, versiones diferentes o adicionales de bibliotecas y software de soporte, etc., que no están presentes en el entorno de un usuario.

Fuente: Wikipedia

Prueba del sistema

El propósito del entorno de prueba es permitir que las pruebas automatizadas o los evaluadores humanos ejerzan el código nuevo y modificado. Una vez que el desarrollador acepta el nuevo código y las configuraciones a través de pruebas unitarias en el entorno de desarrollo, los elementos se mueven a uno o más entornos de prueba.

Si falla la prueba, el entorno de prueba puede eliminar el código defectuoso de las plataformas de prueba, comunicarse con el desarrollador responsable y proporcionar registros detallados de prueba y resultados. Si todas las pruebas pasan, el entorno de prueba o un marco de integración continua que controle las pruebas puede promover automáticamente el código al siguiente entorno de implementación.

Fuente: Wikipedia

Puesta en escena

La puesta en escena es un entorno para la prueba final inmediatamente antes de la implementación en producción. Busca reflejar el entorno de producción real lo más fielmente posible y puede conectarse a otros servicios y datos de producción, como bases de datos.

Por ejemplo, los servidores se ejecutarán en máquinas remotas, en lugar de localmente (como en la estación de trabajo de un desarrollador durante el desarrollo, o en una sola máquina de prueba durante la prueba), lo que prueba el efecto de las redes en el sistema.

El uso principal de un entorno de prueba es probar todos los scripts y procedimientos de instalación/configuración/migración antes de que se apliquen al entorno de producción. Esto garantiza que todas las actualizaciones mayores y menores del entorno de producción se completarán de forma fiable, sin errores y en un tiempo mínimo.

Fuente: Wikipedia

Producción

El entorno de producción también se conoce como en vivo, en particular para los servidores, ya que es el entorno con el que los usuarios interactúan directamente. La implementación en producción es el paso más delicado; se puede hacer implementando un código nuevo directamente (sobrescribiendo el código antiguo, de modo que solo haya una copia presente a la vez) o implementando un cambio de configuración.

Esto puede tomar varias formas: implementar una instalación paralela de una nueva versión de código y cambiar entre ellos con un cambio de configuración; implementar una nueva versión de código con el comportamiento anterior y un indicador de función, y cambiar al nuevo comportamiento con un cambio de configuración que realiza un cambio de indicador; o implementando servidores separados (uno ejecutando el código anterior, otro el nuevo) y redirigiendo el tráfico del antiguo al nuevo con un cambio de configuración en el nivel de enrutamiento del tráfico.

Estos, a su vez, pueden hacerse todos a la vez o gradualmente, en fases.

Fuente: Wikipedia

Estándares de codificación como mejores prácticas de gestión de versiones de software

Ahora que comprende los entornos clave que debe configurar para admitir la administración de versiones, es hora de centrar su atención en el código en sí. Los estándares y convenciones de codificación tienen varios propósitos:

• Ayudan a crear un «aspecto» coherente para el código, lo que permite a los desarrolladores centrarse en el contenido y no en el diseño.
• Permiten a los desarrolladores comprender el código fuente más rápidamente, ya que se pueden hacer suposiciones basadas en la experiencia previa. Por ejemplo, en una aplicación orientada a servicios, tendría procedimientos almacenados, capas de acceso a datos, capas lógicas y una capa de servicio, todas pasando objetos distintos como DTO y contratos de datos.
• Promueve la reutilización y el mantenimiento del código.

Diseño de código

Asegurarse de que su código esté bien formateado hace que sea más fácil de leer. Desde la perspectiva de un desarrollador, no hay nada peor que se le asigne un defecto, «levantando el capó» en el código para descubrir que está viendo un lío de brownfield.

Lo que sigue son algunos consejos que asegurarán que su código esté casi formateado y estandarizado en términos de apariencia.

• Utilice la configuración predeterminada del Editor de código (guiones de cuatro caracteres para tabulaciones, etc.).
• Sólo una declaración por línea.
• Sólo una declaración por línea.
• Al menos una línea en blanco entre las definiciones de métodos y las definiciones de propiedades.
• Use paréntesis para hacer que las cláusulas en una expresión sean obvias. Por ejemplo, en cálculos como este:

Comentando

Algunos argumentan que su código no debería necesitar comentarios, no estoy de acuerdo. Algunas palabras de elección o comentarios XML pueden brindar a los nuevos desarrolladores una descripción general de lo que la clase o el método subyacente está tratando de lograr.

Las únicas cosas a tener en cuenta son:

• Los comentarios deben colocarse en una línea separada, no al final de una línea de código.
• Si tiene demasiados comentarios, su código es demasiado complejo. Refactoriza tu código.

Propiedades

• Cree obtener solo propiedades si la persona que llama no cambia dicha propiedad.
• Proporcione nombres razonables para todas las propiedades.
• Proporcione valores predeterminados para las propiedades.
• No lance excepciones de captadores de propiedades.

Nombres de clase

• Use un sustantivo o una frase nominal para nombrar una clase.
• Utilice el caso de Pascal.
• Use abreviaturas con moderación.
• No utilice un prefijo de tipo, como C para clase, en un nombre de clase. Por ejemplo, utilice el nombre de clase FTPStream en lugar de CFTPStream.
• No utilice el carácter de subrayado (_).

Nombres de métodos

• Usa el caso de Pascal
• Proporcione nombres descriptivos, piense cuál es su propósito más amplio
• Usar verbos o frases verbales
• Revelar la intención de la implementación, por ejemplo, SendJSONData debe cambiarse de nombre a PostTweet

Fuente de control

No se puede tener una estrategia de gestión de versiones eficaz sin implementar un producto de control de código fuente. ¿De qué otra manera va a mantener fácilmente numerosas iteraciones de su producto, implementar funciones, mantener versiones anteriores y fusionar código entre flujos de desarrollo concurrentes?

Hay muchos productos de control de código fuente para elegir, como Visual Studio Team Services y Git.

Gestión de archivos

El control de código fuente le permite administrar el flujo de trabajo de los archivos de código a medida que pasan de un desarrollador a otro. Según sus preferencias, los productos de control de código fuente le permiten definir el acceso a archivos compartidos y exclusivos a los archivos de código.

Si, por ejemplo, configura su producto de control de fuente para habilitar el «acceso exclusivo», entonces solo un desarrollador puede trabajar en ese archivo a la vez.

Archivo Histórico

A medida que los desarrolladores verifican la entrada y salida del código del producto de control de código fuente, el almacén de datos crea un archivo y una instantánea de cada archivo con una identificación de conjunto de cambios que lo acompaña (asumiendo Visual Studio Team Services o TFS por el momento).

Si es necesario, es bastante fácil restaurar cualquier archivo controlado por versión de este archivo en caso de que necesite deshacer cambios importantes.

Automatización

Los productos de control de fuente a menudo le permiten automatizar tareas repetitivas al darle la opción de ejecutar un comando desde un archivo por lotes, como ejecutar un script de base de datos.

Sucursales

Dependiendo de la cantidad de desarrolladores y el tamaño de su proyecto de software, la introducción de una estrategia de bifurcación puede ayudar a acelerar el proceso de compilación y hacer que las tareas de mantenimiento y el desarrollo de funciones sean más fáciles de administrar.

El mecanismo de bifurcación permite a los desarrolladores o equipos trabajar de forma aislada de la «rama principal del código fuente» y hay muchas estrategias que puede adoptar.

Una inmersión profunda en la planificación de sucursales está más allá del alcance de esta publicación de blog, pero si lo está considerando, es importante tener en cuenta lo siguiente:

• ¿Qué tan grande es el equipo?
• ¿Con qué frecuencia necesita enviar el producto?
• ¿Qué tan estable debe ser la construcción?

Es importante bifurcar solo cuando sea necesario, ya que la bifurcación introduce tareas adicionales, como el mantenimiento del repositorio de origen y las tareas de fusión.

Si es el único desarrollador en su equipo, es poco probable que necesite implementar una estrategia de bifurcación, dicho esto, puede decidir mantener una rama para revisiones y otra para características.

Algunos escenarios de bifurcación comunes y sus definiciones:

• Lanzamiento: bifurcación para estabilizar el código que desea lanzar. Puede bifurcar antes del lanzamiento, evitando la necesidad de bloquear la rama principal.
• Mantenimiento: sucursal para mantener una compilación publicada anteriormente.
• Característica: rama para aislar el desarrollo de características que podría hacer que el resto del proyecto sea inestable.
• Equipo: rama para aislar subequipos para que puedan trabajar sin estar sujetos a cambios importantes, o que puedan trabajar hacia hitos únicos. Estas son muy parecidas a las ramas de características.

Fuente: microsoft

Integración continua

Una vez que tenga el código de su aplicación almacenado de forma segura en su proveedor de control de código fuente, otro elemento importante de la gestión de versiones es integración continua (CI).

CI es el proceso automatizado de integración de cambios de código y fusión de todo el código de desarrollador en el repositorio de control de código fuente. Proporciona comentarios casi instantáneos sobre la integridad de la compilación y brinda confianza a los equipos de desarrollo y control de calidad en la compilación actual.

Registros regulares

Los desarrolladores deben esforzarse por verificar el código diariamente, no se debe dejar ningún código desprotegido durante la noche, ¡puede romper la compilación!

Código

Las plataformas en la nube como Windows Azure le permiten configurar flujos de trabajo que se integran con productos de control de código fuente como BitBucket, GitHub y Visual Studio Team Services. Azure extraerá las actualizaciones más recientes de su proyecto una vez que se haya comprometido con cualquiera de estos proveedores de control de código fuente.

Su estrategia de CI debe ser autoevaluada. Los desarrolladores deben escribir pruebas unitarias que se invoquen automáticamente durante una compilación automatizada.

Base de datos

Las actualizaciones de la base de datos, naturalmente, deben sincronizarse con las implementaciones de código e implementarse al mismo tiempo. Estos pueden ser difíciles de mantener.

Se deben considerar los scripts de reversión si falla una compilación/versión iniciada por la plataforma de CI; de lo contrario, podría invalidar la integridad del esquema de la base de datos o los datos mismos.

Promoción a través de Release Paths y Change Management

Esto merece una serie de publicaciones en el blog, pero cubramos lo básico. Con los entornos mencionados anteriormente (DEV, SYSTEM TEST, STAGING y PROD) en mente, su software solo debe realizar la transición a través de cada uno de los entornos cuando esté «aprobado» por la función respectiva, como desarrollo o prueba del sistema.

Como equipo, debe decidir el flujo de trabajo que mejor se adapte a su proyecto. A un alto nivel, un conjunto típico de procesos de gestión de versiones incluye:

• Desarrollo
• Pruebas
• Producción

Cada función tendrá naturalmente sus propios puntos de control internos establecidos. Sus desarrolladores probarán manualmente el código. También pueden complementar esto con pruebas unitarias automatizadas que se pueden ejecutar bajo demanda. Los analistas de pruebas ejecutarán planes de prueba y también pueden escribir planes de prueba automatizados utilizando productos como Selenio.

Los procesos dentro de cada función sirven para actuar como un punto de control antes de la transición de su software de un entorno al siguiente. ¡Ignora este enfoque por etapas bajo tu propio riesgo!

Automatización de pruebas

La automatización de pruebas y la integración continua van de la mano cuando se trata de mejores prácticas de gestión de versiones de software. Esfuércese siempre por automatizar tantas pruebas unitarias como sea posible. Si su equipo se encuentra probando rutinariamente un conjunto de casos de uso, automatícelos.

Sí, puede tomar algún tiempo configurar inicialmente su proyecto para adoptar el enfoque TDD, pero los beneficios superan esta sobrecarga inicial.

Al automatizar las pruebas unitarias, puede probar una aplicación completa con solo unos pocos clics y obtener comentarios casi instantáneos, lo que le permite identificar fallas de código en su aplicación.

Desde la perspectiva de un desarrollador, las pruebas unitarias automatizadas le evitan esperar hasta que el producto haya sido promovido a un entorno de prueba del sistema para los analistas de control de calidad. También sirven para evitar que su producto retroceda cuando se implementan las solicitudes de cambio.

Si está trabajando en una aplicación heredada o «brownfield» que no contiene pruebas unitarias automatizadas, aborde primero las áreas de alto riesgo de tráfico. No se preocupe por tener una cobertura de prueba del 100% inicialmente, de lo contrario, la tarea puede volverse demasiado abrumadora.

Liberación

Después de que su producto haya pasado todas las pruebas del desarrollador y del sistema (y UAT si también tiene ese entorno), debe lanzarlo a producción. Si este desarrollo se ha realizado en una rama separada, con la rama raíz/maestra, entonces estos cambios deben fusionarse nuevamente en la raíz.

Las herramientas de control de código fuente más populares le pedirán que resuelva cualquier conflicto en una ventana de revisión de diferencias, lo que le permite fusionar el código de todos los desarrolladores. Debe tener cuidado durante este ejercicio, ya que es esta nueva versión fusionada la que se promoverá en su entorno de producción.

Estrategia:

• Solo fusione el código de la rama de desarrollo con la rama maestra cuando desee implementar, no intente fusionar nada por adelantado, de lo contrario, se dará trabajo innecesario.
• Programe los principales lanzamientos a producción en la fecha/hora programada que todos conozcan, con la ayuda de las herramientas de análisis, puede establecer qué hora del día es la mejor. Deberá elegir un momento en el que no haya muchos usuarios activos.
• Si puede, presente una «página de mantenimiento» para la comunidad de usuarios.
• Asegúrese de tener personal clave disponible durante unas horas después de la actualización en caso de que necesite aplicar una revisión.

Notas de lanzamiento

• Utilice su proveedor de control de código fuente para generar notas de la versión que contengan todas las funciones nuevas y compártalas con el equipo y la comunidad de usuarios.
• Haga circular documentación o guías de implementación en cada función (prueba/desarrollo, etc.) que les permita saber exactamente qué se debe implementar y cómo.

Finalmente

• Elimine cualquier rama adicional después de haber completado su combinación para mantener limpio el repositorio de control de código fuente.
• Una vez completada la implementación, realice pruebas de humo clave para verificar que todo funcione como se espera en el entorno de producción.
• Como regla general, ¡no realice actualizaciones los lunes o viernes!

Seguimiento de problemas como mejores prácticas de gestión de versiones de software

Ahora que su software está disponible para los usuarios, puede estar seguro de que los usuarios utilizarán su producto de maneras que nunca anticipó. Sin duda, generarán problemas o defectos y deberá gestionarlos en consecuencia.

Hay muchas herramientas que pueden ayudarte a hacer esto, como JIRA y Servicios de equipo de Visual Studio (VSTS) que facilitan el manejo de defectos.

Por ejemplo, con VSTS, puede presentar defectos en su Tablero Kanban en comparación con la Historia de usuario o la Característica del producto original. Esto facilita que su equipo realice un seguimiento de las solicitudes de cambio originales y les permite identificar cualquier cambio de código y los respectivos scripts de prueba que se escribieron y ejecutaron.

Cuando tiene defectos en su software de seguimiento de problemas, puede impulsarlos a través de su proceso de gestión de versiones y el ciclo de gestión de versiones comienza de nuevo.

Pensamientos finales

Ahí lo tiene, las mejores prácticas de administración de versiones de software. No existe una solución mágica o un enfoque único para todos, pero al aplicar algunas de las técnicas e ideas que hemos explorado, ayudará a suavizar su ciclo de lanzamiento de desarrollo de software.

Si necesita asistencia de profesionales experimentados en el desarrollo de software para los procesos de desarrollo y lanzamiento, DevTeam.Space puede ayudarlo con su comunidad de desarrolladores de software y administradores de proyectos expertos en el campo.

Escríbenos tu requisitos iniciales del proyecto y uno de nuestros gerentes de cuenta se pondrá en contacto contigo.

Esperamos que haya disfrutado leyendo esta publicación de blog, siéntase libre de dejar cualquier comentario o sugerencia.

Preguntas frecuentes sobre las mejores prácticas de gestión de versiones de software