驴Qu茅 es Release Management?
La gesti贸n de versiones cubre todas las fases de la versi贸n de software, desde el desarrollo y las pruebas hasta la implementaci贸n. La gesti贸n de versiones es necesaria cada vez que se solicita un nuevo producto, o incluso cambios en un producto existente. Hay cinco pasos b谩sicos de administraci贸n de versiones que tomamos en esta situaci贸n:
- Planificaci贸n de lanzamiento
- Versi贸n de lanzamiento
- Prueba de aceptaci贸n del usuario
- Preparaci贸n de lanzamiento
- Implemente la versi贸n.
Planificaci贸n de lanzamiento
La fase de planificaci贸n es en la mayor铆a de los casos intensiva, ya que es en esta etapa que se organiza todo nuestro lanzamiento de principio a fin. Un plan de lanzamiento s贸lido lo ayuda a mantenerse encaminado y garantizar que los est谩ndares y requisitos se cumplan correctamente.
Al planificar lanzamientos, creemos que las aplicaciones desarrolladas por varios equipos necesitan un enfoque coherente que debe lanzarse con anticipaci贸n. Aqu铆 es donde entra en juego el concepto de "liberaci贸n de trenes". Al seguir un enfoque de lanzamiento de trenes, los equipos pueden programar cambios seg煤n los lanzamientos y enviarlos a Play Store.
El primer paso, incluso antes de que comencemos a implementar la versi贸n del tren, es definir los intervalos de tiempo para cada etapa. En nuestro caso, la etapa de desarrollo es de dos semanas. A continuaci贸n, debe determinar cu谩nto tiempo desea dedicar a las pruebas de integraci贸n y los pasos de implementaci贸n. A continuaci贸n se muestra nuestro ejemplo de espaciado:
- Recorte: comienza el d铆a 1.
- Pruebas internas de versiones alfa / UAT: tres d铆as.
- Despliegue por fases [1%] Env铆o para revisi贸n.
- Duraci贸n de la revisi贸n: 3 d铆as.
- Un d铆a al 20% de usuarios.
- Un d铆a con el 50% de los usuarios, el mismo d铆a crece al 100% de los usuarios.
Seg煤n el ejemplo anterior, tomar谩 un total de 10 d铆as hasta que una nueva versi贸n de la aplicaci贸n est茅 disponible de forma generalizada.
El siguiente paso hacia los lanzamientos es crear un flujo de trabajo al que tanto nuestros equipos como las partes interesadas clave puedan consultar durante el lanzamiento.
El flujo de trabajo explica de inmediato c贸mo funciona toda la versi贸n y qu茅 papel desempe帽a cada miembro del equipo. Usamos la herramienta de Asana para mostrar estos detalles como se indica a continuaci贸n:
- Sincronizaci贸n
- Tiempo de entrega estimado
- Requisitos
- Alcance general del proyecto
Despu茅s de desarrollar el plan, lo enviamos a todas las partes interesadas (grupo de lanzamiento, gerente de producto y l铆deres de alto nivel) para su consideraci贸n. Luego recibimos sus comentarios sobre cualquier brecha o problema que vean en los requisitos o la aplicaci贸n.
Una vez que se aprueba y finaliza el plan, 隆comienza la diversi贸n!
Aspectos importantes de la planificaci贸n del lanzamiento
Crear y utilizar una entrega de tren suena genial, pero mantener el proceso en funcionamiento mientras se planifica una entrega de tren puede ser complicado. A continuaci贸n, se muestran algunos detalles de este proceso:
- El administrador de lanzamientos gestiona y coordina el lanzamiento.
- Solo aceptamos c贸digo revisado y probado.
- Hay una etapa de implementaci贸n en el proceso.
- Estamos monitoreando la versi贸n publicada de la aplicaci贸n.
Edificio de lanzamiento
Una vez que el plan de lanzamiento est茅 listo, puede comenzar a probar el producto para su lanzamiento. Esta ser谩 la "prueba a nivel de usuario" real del producto seg煤n los requisitos descritos en el plan de lanzamiento.
Un d铆a y una hora determinados (por ejemplo, el lunes a las 15:00), el c贸digo se congela / recorta. Hasta este punto, los equipos tienen tiempo para buscar, probar y fusionar caracter铆sticas en la rama de desarrollo, que deber铆a ser parte del lanzamiento del tren. A las 15:00, el administrador de versiones crear谩 una rama de la versi贸n de desarrollo. Este paso est谩 automatizado con Jenkins.
Al automatizar la transici贸n de sucursales, verificamos que todos los umbrales de rendimiento, los puntos de referencia y la automatizaci贸n de lanzamientos anteriores al mercado se establezcan en el actual como base para la comparaci贸n, y que el lanzamiento del tren est茅 bloqueado para otros cambios.
Una vez que el c贸digo est谩 congelado, comienza un nuevo ciclo de desarrollo y todos los equipos participantes comienzan un nuevo sprint y contin煤an con el desarrollo. Lo mejor de un lanzamiento de tren es que todos conocen el pr贸ximo lanzamiento planificado y ayuda a las personas a planificar su trabajo en consecuencia.
Lanzamiento de sucursales y control de versiones
El desarrollo de productos generalmente no se detiene cuando finaliza el desarrollo de una versi贸n, por lo que lo primero en lo que pensamos es en c贸mo congelar la compilaci贸n bajo prueba y, al mismo tiempo, trabajar en nuevas funciones para la pr贸xima versi贸n. 驴Qu茅 sucede si aparece un error en la versi贸n de la versi贸n? 驴C贸mo corrige el error si ya ha agregado un mont贸n de cosas nuevas antes de que se encontrara el error?
Aqu铆 es donde entra la inteligente estrategia de ramificaci贸n, que tiene el concepto de ramificaci贸n. Como sugiere el nombre, el c贸digo de ramificaci贸n significa que, al igual que las ramas de un 谩rbol, el c贸digo de las ramas coincide hasta cierto punto y luego se divide en dos copias.
Cada rama puede desarrollarse independientemente de la otra. En este caso, una copia, la rama de lanzamiento, permanece congelada donde la dej贸. Esto es lo que llamamos una rama recortada. Otra rama (rama de desarrollo) se puede cambiar con nuevo c贸digo y correcciones de errores sin afectar la rama de lanzamiento en absoluto. Si se encuentra un error en una versi贸n candidata, se puede desarrollar y agregar una soluci贸n a la rama de la versi贸n. Por lo tanto, la siguiente compilaci贸n que cree a partir de la rama de lanzamiento nuevamente puede ser id茅ntica a la primera, excepto por una correcci贸n de error. De esta manera, puede minimizar el riesgo de nuevos errores en una versi贸n y aislar los errores del nuevo c贸digo. Tambi茅n se aplica una correcci贸n a la rama de desarrollo para garantizar que el mismo error no llegue a la pr贸xima versi贸n.Otro beneficio de la bifurcaci贸n de versiones es que una vez que publicas tu c贸digo, tienes una bifurcaci贸n "congelada", que es una copia exacta del c贸digo base publicado. Puede volver a este c贸digo en cualquier momento como referencia.
Pruebas de aceptaci贸n del usuario
Las pruebas de aceptaci贸n del usuario son el paso m谩s cr铆tico para la gesti贸n de versiones debido a la cantidad de datos recopilados y las correcciones necesarias para que la compilaci贸n sea exactamente lo que deber铆a ser para el lanzamiento oficial.
Como sugiere el nombre, cuando se trata de este tipo de pruebas, la figura clave es el usuario. Los usuarios son exactamente las personas que utilizar谩n la aplicaci贸n. Por lo tanto, es imperativo que los usuarios formen parte de la estrategia general de garant铆a de calidad en el proceso de desarrollo de software. Aqu铆 es donde UAT resulta 煤til. Este tipo de prueba coloca las necesidades del usuario en el centro del desarrollo de productos como ning煤n otro. Estas son algunas de las preguntas que tales pruebas intentan responder:
- 驴Pueden los usuarios trabajar con la aplicaci贸n?
- 驴La aplicaci贸n se comporta como se esperaba?
- 驴La aplicaci贸n resuelve el problema del usuario?
Sin UAT (User Acceptance Testing) eficaz, las posibilidades de 茅xito del proyecto que se est谩 desarrollando se reducen significativamente. Por eso, la costumbre es una parte tan importante del proceso de entrega. Como se se帽al贸 anteriormente, UAT es parte de un proceso iterativo. A medida que se identifican los errores, el equipo regresa para corregirlos. El error se corrige en la rama de lanzamiento y luego se fusiona con la rama de desarrollo. La compilaci贸n debe pasar por la etapa UAT para que pueda examinarse para su implementaci贸n final y lanzamiento.
Consejo profesional: 隆Incluya siempre las pruebas internas en la planificaci贸n de UAT!
Una forma de acelerar el lanzamiento de UAT fue utilizar las pistas de prueba internas proporcionadas por Google. Esto nos ayuda a distribuir r谩pidamente los tickets a los colegas y a capturar sus comentarios generando autom谩ticamente tickets JIRA. El equipo tambi茅n se asegura de que se tengan en cuenta los comentarios antes de enviar la prueba final.
Preparaci贸n y liberaci贸n
Este paso es para darle los toques finales al producto, teniendo en cuenta todo lo que se entendi贸 en UAT. La preparaci贸n del lanzamiento tambi茅n incluye un control de calidad final por parte del equipo de control de calidad. Durante la inspecci贸n, el equipo de control de calidad realiza verificaciones finales para garantizar que el ensamblaje cumpla con los est谩ndares m铆nimos de aceptaci贸n y los requisitos comerciales del plan de lanzamiento.
Una vez finalizada la revisi贸n, el grupo de versiones completar谩 la versi贸n para comenzar la implementaci贸n. Antes de que un ensamblaje se pueda implementar en un entorno en vivo, debe ser aprobado por los equipos responsables relevantes, como el equipo de dise帽o. UAT asegura que el resultado se valida antes de pasar a la siguiente etapa.
Implementar una versi贸n
Finalmente, lleg贸 el gran d铆a en el que todo el arduo trabajo de nuestro equipo dio sus frutos. Es hora de lanzar nuestro producto a la naturaleza para su producci贸n. Adem谩s de simplemente enviar el ensamblaje al entorno de producci贸n, la fase de implementaci贸n tambi茅n contiene capacitaci贸n sobre c贸mo trabajar con el producto tanto para el usuario final como para la empresa en su conjunto. Por ejemplo, los usuarios deben ser notificados de los cambios en una versi贸n, y aqu铆 es donde "Novedades" no aparece en el campo de visi贸n. Tenemos un proceso Jenkins automatizado que contiene los siguientes pasos:
- Creaci贸n del ensamblaje final [especificando rama y nombre de la versi贸n].
- "Novedades" a帽adido en la versi贸n.
- Agregar un porcentaje de implementaci贸n.
- Cada etapa tiene entrada manual de se帽ales (rojo / verde) de cada uno de los comandos [UAT, benchmark, performance, automatizaci贸n].
Tan pronto como las se帽ales permitan la compilaci贸n, la compilaci贸n se carga autom谩ticamente en Play Store con un porcentaje de implementaci贸n definido. Los pasos internos de confirmar y configurar la etiqueta de versi贸n, guardar ensamblados en Dropbox, publicar y actualizar en el canal de Slack apropiado tambi茅n se realizan a trav茅s de la misma canalizaci贸n.
En este caso, comenzamos implementando al 1%. En cada etapa, es necesario seguir la revisi贸n, as铆 como las herramientas para monitorear las ca铆das de versiones con el fin de identificar posibles problemas.
Si el error se nota en un 1%, el equipo tiene la oportunidad de reaccionar al problema y decidir si lo arregla r谩pidamente. Si es as铆, la liberaci贸n del tren no deber铆a alcanzar el siguiente paso de implementaci贸n del 5%. En cambio, el problema se resuelve para el 1% de los usuarios. Una vez que se soluciona el problema y se verifica la soluci贸n, la liberaci贸n del tren puede pasar a la etapa del 5%.
Al igual que con la versi贸n simple del lanzamiento del tren, solo el ingeniero de lanzamiento o el equipo de lanzamiento se encarga del proceso de lanzamiento despu茅s de que se congela el c贸digo. Todos los dem谩s equipos contin煤an con un desarrollo "normal".
An谩lisis posterior al lanzamiento
El trabajo de administraci贸n de versiones no termina cuando se publica el c贸digo, y contin煤a hasta que est茅 listo para publicar la versi贸n nuevamente. Si desea que su aplicaci贸n tenga 茅xito, necesita una buena revisi贸n, tambi茅n debe seguir el lanzamiento en producci贸n para corregir errores, implementar funciones que las personas necesitan y resolver los problemas de los usuarios. Para hacer esto, usamos Firebase Crashlytics, donde rastreamos cualquier falla que requiera una soluci贸n inmediata.
Adem谩s, las revisiones de aplicaciones brindan informaci贸n sobre su producto que es mucho m谩s dif铆cil de obtener con otros enfoques. Tanto Google Play como la App Store brindan a los desarrolladores de aplicaciones la capacidad de responder a las rese帽as, lo que puede ser una herramienta incre铆blemente 煤til para obtener m谩s informaci贸n de los usuarios sobre los problemas de las aplicaciones. Los testimonios pueden identificar problemas que los usuarios est谩n experimentando con su aplicaci贸n e informar sobre cambios futuros.
Resumamos
La gesti贸n de versiones supervisa un proceso extremadamente din谩mico. Cada lanzamiento es una oportunidad para refinar todo, desde nuestro flujo de trabajo hasta nuestra lista de verificaci贸n, a medida que descubrimos 谩reas de mejora con 茅l. Estos son algunos de los beneficios que obtuvimos:
- Mejoramos nuestra productividad mejorando la comunicaci贸n y la coordinaci贸n.
- Nuestras versiones se entregan m谩s r谩pido, lo que tambi茅n reduce los riesgos. Estos cambios involucran a un equipo que puede entregar lanzamientos de calidad a alta velocidad de manera regular.
- La gesti贸n de versiones tambi茅n apoya la sistematizaci贸n y optimizaci贸n del m茅todo de desarrollo y operaci贸n.
Tambi茅n vimos que nuestro proceso de administraci贸n de lanzamientos facilit贸 a las personas en general, desde desarrolladores y propietarios de productos hasta ejecutivos, revisar el plan de alto nivel y obtener una instant谩nea de su progreso, trabajar en sincron铆a.
- Curso de DevOps
- Formaci贸n profesional en ciencia de datos
- Formaci贸n de analista de datos
- Curso de Python para desarrollo web