Guía: Gestión de versiones de software para equipos pequeños

Formalización del proceso de gestión de versiones (si lo hay)

En algunas configuraciones de equipo, especialmente las que se encuentran en las startups, no hay DevOps ni ingenieros de infraestructura para brindar soporte al lanzar una nueva versión del producto.

Además, a diferencia de las grandes empresas burocráticas con procesos formales definidos, el CTO o el equipo de desarrollo de software en una startup a menudo no es consciente de las complejidades del proceso de gestión de versiones de software; algunos desarrolladores de la empresa pueden conocer los detalles complejos del proceso, pero no todos. Si este conocimiento no se documenta a fondo , creo que podría generar confusión.

En este artículo, intentaré brindar algunos consejos sobre cómo formalizar el proceso de lanzamiento, particularmente desde el punto de vista del desarrollador.

Ingrese a la lista de verificación de versión de software

Es posible que esté familiarizado con la idea de una lista de verificación para algunas operaciones, según el Manifiesto de la lista de verificación, un libro de Atul Gawande. Creo que un proceso de lanzamiento formal (como muchas otras tareas en el mundo del desarrollo de software) brinda a los desarrolladores la oportunidad de implementar este protocolo. Se debe mantener una lista de verificación del proceso de lanzamiento en un documento compartido, preferiblemente en forma de wiki colaborativo o una hoja de cálculo en Google Drive.

Al compartir este documento vital con el equipo y otorgar permisos de edición, cada miembro tiene acceso al proceso de publicación definido formalmente. Esto les permite entender cómo funciona el proceso. Además, después de las discusiones con otros miembros del equipo, permite al equipo mejorar de vez en cuando. Esto debería brindar transparencia y permitir que todo el equipo tenga acceso en tiempo real a lo que sucede durante el lanzamiento, qué pasos se completaron y quién lo hizo.

Al mirar esta hoja de cálculo, las partes interesadas pueden decidir entre 'SIGUIR' o 'NO IR', en función del resultado de los pasos. Por ejemplo, si una prueba de estrés sale mal en un entorno de prueba, en función del evento, el director del proyecto podría decidir cancelar la versión de producción.

Pasos sugeridos para usar como base

En esta sección, propondré algunos pasos que puede usar para crear su propia lista de verificación para su proceso de lanzamiento. Algunos de estos pasos no son de ninguna manera obligatorios . Cada aplicación es diferente y cada organización funciona de una manera diferente, así que siéntete libre de adaptarte y hacer cambios que encajen mejor en tu flujo de trabajo.

1. Crear una rama de lanzamiento

Es probable que esté familiarizado con el concepto de Git Workflow, o con la idea de las ramas de lanzamiento, un tema que se explicó en una publicación de blog anterior.

Lo ideal es tener al menos tres ramas:

• maestro : esto debería reflejar el estado actual de lo que hay en el entorno de producción. Cada nueva confirmación en el maestro debe comprender solo una nueva versión.
• desarrollar : esta rama debe contener las próximas funciones completadas (y probadas). Es común crear una rama separada para cada función y luego fusionarla para desarrollarla cuando la función esté lista.
• lanzamiento : las ramas de lanzamiento son una colección de confirmaciones que están listas para enviarse a producción, además de algunas correcciones de errores menores adicionales relacionadas con el lanzamiento.

Tenga en cuenta que las ramas de lanzamiento deben eliminarse una vez que se completa el lanzamiento, por lo tanto, estas ramas se crean y destruyen todo el tiempo, a diferencia de master o de desarrollo , que siempre son las mismas.

Para crear una nueva rama de lanzamiento , desde la rama de desarrollo en su terminal git, escriba:

$ git checkout -b release/xyz

Es conveniente usar una convención de nomenclatura, como la definida anteriormente, reemplazando xyz por el número de versión major.minor.patch según sus necesidades (es una política que debe definir dentro de su equipo y cumplirla).

También es importante decir que si codifica algunas correcciones de errores en la rama de lanzamiento, no debe olvidar fusionarlos nuevamente para desarrollar . El objetivo principal de la rama de lanzamiento es tener una vista previa de cómo debe comportarse la aplicación después de que entre en producción.

2. Versión de golpe

El siguiente paso sería aumentar (modificar o aumentar) el número de versión en la rama de lanzamiento .

Debe abrir AndroidManifest.xml/package.json/pom.xml/o donde esté almacenada la versión de la aplicación en su proyecto (YMMV), actualizar el número de versión y luego confirmar los cambios en la rama de versión actual.

Es importante actualizar el número de versión por dos razones.

Primero, puede rastrear y mapear las funciones que se introdujeron en cada versión, y segundo, sabrá la versión que están usando en caso de que necesiten solucionar algún problema o contactarlo para obtener asistencia. Si está creando una aplicación móvil, el número de versión que está actualizando en este paso generalmente se muestra en el extremo del usuario, en la sección Acerca de o en Google Play o Apple App Store . Este paso también es una buena oportunidad para actualizar según el entorno. -archivos de configuración (aunque sugeriría mantenerlos en un repositorio separado), como hacer que la bifurcación apunte a la base de datos de producción, o cualquier otro ajuste necesario en el proceso de compilación.

Finalmente, se recomienda que empuje la rama de lanzamiento al origen, para que esté disponible para sus otros desarrolladores:

$ git push -u origin release/xyz

3a. Combinar la rama de lanzamiento para dominarla y etiquetarla

Solo la rama maestra debe implementarse para la producción, por lo tanto, en este paso, debemos fusionar la rama de lanzamiento en la maestra .

 $ git checkout master $ git merge --no-ff release/xyz $ git push

El indicador --no-ff es opcional, sin embargo, se recomienda su uso para forzar la creación de un nuevo objeto de confirmación, aunque la fusión se puede completar utilizando la técnica de avance rápido.

A continuación, es hora de etiquetar el lanzamiento en la rama principal :

$ git tag -a xyz -m 'description of new version, features or fixes included'

Las etiquetas son útiles porque persiste este punto específico en la historia en el repositorio de git, y puede volver más tarde para recrear una rama separada de una etiqueta en particular.

3b. Use una solicitud de extracción para fusionar la rama de lanzamiento

Otra alternativa que se usa con frecuencia es usar una solicitud de incorporación de cambios para fusionar la rama de publicación en la maestra .

Existen numerosas ventajas en este enfoque. Se crea un nuevo espacio para la colaboración, que el equipo puede usar para discutir varios problemas relacionados con la versión. Este punto es un buen momento para agregar una puerta adicional para incorporar un proceso de revisión de código, mientras se tienen más ojos para monitorear el código que se introducirá y discutir posibles modificaciones.

Algunas herramientas que le permiten implementar solicitudes de incorporación de cambios en sus flujos de trabajo son GitHub, Bitbucket y GitLab (solicitud de fusión como lo llaman en este último). Con estas herramientas, no escribe los comandos de git manualmente, sino que utiliza una interfaz web para configurar la rama de origen ( versión ) y la rama de destino ( maestro ), y luego agrega uno o más revisores, todos los cuales ser capaz de escribir comentarios en línea sobre estos nuevos cambios, sugerir mejoras, etc.

Después de que todos los revisores aprueben la solicitud de extracción, puede fusionar automáticamente los cambios en el maestro presionando un botón en la interfaz de usuario.

4. Implementar el maestro en el entorno de producción

Es una buena práctica, en esta etapa, que un probador de su equipo realice una prueba de humo (esto podría definirse en una lista de verificación separada) antes de implementar la aplicación. Una buena sugerencia es implementar la rama maestra en un entorno de prueba separado. Luego, el probador puede realizar algunas acciones básicas para asegurarse de que nada salió mal después de la combinación en la última compilación. Cómo realizar una prueba de humo está más allá del alcance de este artículo, pero puede encontrar mucho material en la web al respecto. El resultado de la prueba de humo se puede integrar en la lista de verificación/hoja de cálculo de liberación, documentando todo lo que salió mal.

En este punto, está listo para implementar los cambios y ponerlos en marcha. Continúe e implemente la rama maestra . Este paso dependerá de la pila de infraestructura que esté utilizando. Puede implicar conectarse a su instancia Amazon EC2 para cargar su aplicación, o presionar un control remoto Heroku, o conectarse a través de ssh a su VPS para copiar la nueva versión, o cualquier otro proceso.

Después de cargar la aplicación, asegúrese de que se implementó correctamente y de que funciona como se esperaba.

5. Vuelva a fusionarse con la rama de desarrollo y eliminación de versión

Ahora que el lanzamiento está casi completo, querrá fusionar la rama de lanzamiento en la de desarrollo , para actualizar el número de versión en este último y para transferir todas las correcciones de errores realizadas a la rama de desarrollo principal:

 $ git checkout develop $ git merge release/xyz

Ahora es el momento de eliminar la rama de liberación :

$ git branch -d release/xyz

6. Generación de registro de cambios

Debe haber un archivo en la raíz de su proyecto llamado CHANGELOG.md (o un equivalente) donde debe agregar una nueva entrada cada vez que haya una nueva versión para documentar todo lo que se incluye en él, como correcciones de errores, nuevas características, problemas conocidos y cualquier otra información relevante en forma de notas de la versión. Esto es realmente útil para que los usuarios y colaboradores vean qué cambios se han realizado entre cada lanzamiento (o versión) del proyecto.

La entrada del registro de cambios incluye la fecha, el número de versión y algunas notas sobre el lanzamiento. Las entradas deben mantenerse en orden cronológico inverso. Aquí hay una plantilla simple que he estado usando que puedes adaptar a tu proyecto:

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

Además, este paso se puede automatizar completamente codificando un script básico que atraviesa el registro de git y genera automáticamente la entrada del registro de cambios, o usando una herramienta que hace lo mismo, como:

• Generador de registro de cambios de Github, por skywinder,
• Léame Gen por fojuth
• cambios en github, por lalitkapoor

Sin embargo, tenga en cuenta que el grado de automatización que obtiene es directamente proporcional a la rigurosidad del formato de su mensaje de confirmación. Creo que siempre es una buena práctica acordar un formato específico para los mensajes de confirmación con el equipo. Al seguir las pautas sobre el estilo de los mensajes de confirmación, serán más fáciles de analizar y, por lo tanto, es más probable que pueda automatizar la generación del registro de cambios.

7. Comuníquese con las partes interesadas

Aquí es donde normalmente harías algunas de las siguientes cosas:

• Informe al equipo a través de una herramienta de mensajería interna (p. ej., Slack) que se ha completado una nueva versión. Recomiendo crear un nuevo canal (es decir, #lanzamientos ) con el único propósito de comunicar eventos relacionados con el lanzamiento. Es fácil agregar ganchos en un canal de Slack para publicar un mensaje después de que se haya realizado una acción.
• Como alternativa, envíe un correo electrónico a las partes interesadas con un enlace al registro de cambios o al archivo de registro de cambios adjunto.
• Escriba una publicación de blog (si tiene un blog para su aplicación o producto) o un tweet.

Se pueden tomar más acciones dependiendo de la naturaleza de su organización. Lo importante es no olvidar comunicar que está disponible una nueva versión de su producto.

8. Preparación del rastreador de problemas

Después de ejecutar un lanzamiento, probablemente necesite actualizar el estado de algunos de sus tickets para realizar un seguimiento de las correcciones de errores o funciones que se encuentran actualmente en producción. En general, esto implica cambiar algunas etiquetas (para proyectos pequeños, uso una etiqueta pendiente de lanzamiento , que elimino una vez que se completa el lanzamiento).

Si usa hitos para cada nueva versión, probablemente necesite actualizar su estado o marcarlos como completados. Algunos rastreadores de problemas incluso le permiten planificar el lanzamiento y alinearlo con los sprints, rastrear si un error está bloqueando un lanzamiento y otra información útil.

Todo depende de cómo uses la herramienta. Simplemente quiero señalar que la tarea de actualizar la información en el rastreador de problemas debe incluirse en su lista de verificación de lanzamiento.

Acerca de la automatización del proceso de liberación

El lector habrá notado que, además del paso de registro de cambios descrito anteriormente, muchos de los pasos mencionados anteriormente también se pueden automatizar.

La capacidad de automatizar algunas partes del proceso de lanzamiento es una gran ventaja y ahorra mucho tiempo. Sugiero crear guiones o descubrir cómo automatizar pasos individuales y luego trabajar hacia un objetivo de entrega continua. La entrega continua puede reducir el riesgo, reducir los costos y reducir el tiempo que los desarrolladores deben dedicar a administrar el lanzamiento. En consecuencia, podrá realizar lanzamientos con mayor frecuencia y ser más productivo en términos de las horas asignadas para el desarrollo.

El santo grial de las empresas DevOps es poder lanzar una nueva versión presionando un botón (o ejecutando un comando) que activaría el proceso de lanzamiento automáticamente, o mejor aún, un sistema que lanzaría una nueva versión de su software en un momento. hora designada. Por supuesto, esto es difícil de lograr porque también necesita automatizar gran parte del proceso de prueba, pero no es imposible.

Adoptar las mejores prácticas

En esta sección, describiré un par de prácticas recomendadas que he encontrado convenientes, ya sea para facilitar el proceso de lanzamiento o para tomar medidas de seguridad en caso de que algo salga mal.

Encuentra el día más adecuado para realizar la liberación

Por lo general, lanzo las aplicaciones en las que estoy trabajando los jueves, entre el mediodía y el cierre de la jornada laboral.

Si trabajas de lunes a viernes, no es buena idea lanzar un viernes. Si algo falla después del lanzamiento, no tendrás tiempo de arreglarlo hasta el lunes (a menos que quieras trabajar durante el fin de semana). Es por eso que es más conveniente hacer lanzamientos el jueves, porque tiene el viernes para monitorear la nueva versión después de implementarse, solucionar cualquier problema o hacer una reversión.

Otra cosa importante que debe mencionar si está administrando una aplicación web es conocer la zona horaria en la que se encuentran la mayoría de sus usuarios. Debe programar el lanzamiento durante un período de poco tráfico para minimizar el daño potencial si algo falla. A veces, esto puede ser complicado cuando su base de usuarios se extiende por todo el mundo, pero de todos modos, debe investigar un poco y decidir cuál es el mejor momento.

Haga una copia de seguridad de su base de datos antes de una nueva versión

Si no tiene copias de seguridad periódicas de su base de datos programadas, le recomiendo que agregue un paso en su proceso de lanzamiento para realizar una copia de seguridad antes de comenzar el lanzamiento.

Lanzamientos por etapas

¿Alguna vez se preguntó por qué, cuando un editor anuncia que ha lanzado una nueva función, tarda días, o incluso semanas, en estar disponible en su teléfono? Esto se debe a que muchas empresas utilizan implementaciones por etapas.

Facebook ha estado haciendo esto durante mucho tiempo. Prueba una nueva característica en el cinco o el 10 por ciento de sus usuarios, aumentándola gradualmente hasta llegar al 100 por ciento de la base de usuarios. Durante la fase de implementación por etapas, deberá observar detenidamente los comentarios de los usuarios y los informes de fallas. Con esta información, puede posponer el lanzamiento o corregir errores antes de que afecten a todos los usuarios.

Hay una buena herramienta en la Consola para desarrolladores de Android que implementa implementaciones por etapas para sus aplicaciones de Android.

Integración continua

La integración continua es una práctica que vale la pena adoptar por muchas razones. En primer lugar, le permite detectar errores de manera temprana, lo que aumenta la tasa de lanzamientos exitosos. En segundo lugar, es el primer paso lógico antes de implementar la entrega continua y la automatización completa como se describió anteriormente.

Martin Fowler es un gran defensor de la integración continua. Él describe una gran cantidad de beneficios que se pueden agregar a su proceso de lanzamiento al usar esta práctica. Este es un tema amplio y hay muchos libros y publicaciones de blog al respecto, y lo menciono aquí porque creo que le dará mucha más confianza en sus operaciones. Entre las muchas ventajas de usar CI, encontrará: riesgo reducido, mayor visibilidad para saber qué funciona y qué no, detección temprana de errores, mayor frecuencia de implementaciones y muchas más.

El punto de partida para implementar CI es configurar un "servidor de integración continua"; Algunas buenas herramientas para probar son: CruiseControl, Bamboo, Jenkins y Travis.

Exitlude: todo saldrá bien

Agresivamente, todos defendemos el papel que desempeñamos Lamentablemente, llegan tiempos para enviarte en tu camino Lo hemos visto todo, hogueras de confianza, inundaciones repentinas de dolor Realmente no importa, no te preocupes, será todo funciona

Exitlude, los asesinos

Para concluir, diría que es muy importante tener un proceso de lanzamiento bien definido para su aplicación, independientemente de su complejidad, base de usuarios o cuán pequeña sea su organización.

Si no es así, le sugiero que empiece a pensar en algunos pasos básicos, utilizando esta guía y otras similares, y haciendo una lluvia de ideas con su equipo para llegar a un primer borrador. Pruébelo en su próximo lanzamiento, luego itere. Eventualmente, terminará construyendo su propio proceso de lanzamiento.

Después de eso, empieza a pensar en cómo automatizar partes del proceso . Piense en las áreas que se pueden mejorar. Explore formas de reducir el tiempo de lanzamiento mediante la incorporación de pequeñas optimizaciones. La automatización debe ser su objetivo final; sin embargo, no planees eso desde el principio, o fracasarás al intentar dar un salto tan grande. Como todo proceso, es mejor mejorarlo gradualmente.

¿Tienes algún otro truco o guía que uses para lanzar nuevas versiones de tu aplicación? Si es así, házmelo saber. No vengo del mundo DevOps, solo soy un desarrollador bastante organizado y estructurado, pero en comparación con muchos veteranos, todavía soy un novato en este sentido, así que no dude en comentar o contactarme si tiene algo que agregar