El presentar al mundo nuestras creaciones puede ser uno de nuestros más grandes temores. Publicar una canción, postear una foto en Instagram, poner en linea un Sitio Web o incluso publicar un Blog Post (como este), están cargados de una sentimiento que mezcla temor y expectación simultáneamente.
En el caso de la tecnología, y en específico del Software, los que tenemos el privilegio de trabajar en este arte experimentamos esa sensación en cada ocasión que “nuestros bebés van a salir al mundo”, ó en otras palabras, cuando colocamos nuestro Software en Producción!
Y preguntarás: “Pero JJ, cómo lidiar con esto?”…..¡Qué bueno que preguntas! :). La filosofía DevOps tiene algunos secretos para minimizar el dolor de este “parto”.
Pausa para entender la Jerga DevOps
Product Release = Hacer pública de la versión más reciente de un producto (obviamente, en Producción).
Deployment = Instalar, testear y configurar el producto en un ambiente, por ejemplo: Desarrollo o Pre-Producción. Un Deployment puede realizase incluso a Producción, sin hacerlo visible para el público hasta el momento del Product Release.
Ejemplos:
- “Dale, hagamos el Deployment de la versión 2.0.3 a Producción.”
- “El Deployment del Release 2.0.3. fue un éxito!” (Sí, con un poco de esfuerzo, esas palabras saldrá de tu boca con frecuencia 🙂 )
Ya que tenemos las cosas claras, prosigamos:
Estos son algunos de los síntomas de un Product Release doloroso:
- Releases poco frecuentes
- Cuando mencioné “partos”, hablaba figurativamente!. No quiere decir que tienes que esperar 9 meses para tener Releases.
- Menos de 4 Releases por año es un pecado.
- Cuando mencioné “partos”, hablaba figurativamente!. No quiere decir que tienes que esperar 9 meses para tener Releases.
- Deployments Manuales
- Los humanos no están hechos para realizar tareas repetitivas. Punto.
- Tener a un humano copiando/pegando manualmente una App en Producción tiene un riesgo altísimo, especialmente si es alguien que está cansado o distraído (o hambriento! #trueStory).
- Bugs encontrados en Producción inmediatamente luego del Release.
- Solo puedo preguntar: “Y….qué pasó con el testeo?”
- Solo puedo preguntar: “Y….qué pasó con el testeo?”
- Dev Box: el Ambiente de Pruebas
- Me dices que el testing fue realizado en las máquinas de los Desarrolladores?
Estas consciente de que ese “ambiente” tiene el mismo grado de higiene que un toilet público en un concierto? 
- Me dices que el testing fue realizado en las máquinas de los Desarrolladores?
- Viernes de Release
- “Release en Viernes por la noche …por si algo sale mal“. ¿Realmente tienes tan poca confianza en tu deployment (el cual ya debería estar automatizado) como para darte 30+ horas por si “algo sale mal”?
“Si algo duele, hazlo más frecuentemente.“
Cuando Martin Fowler dice “Si algo duele, hazlo más frecuentemente“1 , se refiere a la búsqueda continua de los estresores que aportan al progreso. Ejemplo de la vida no-digital:
- Después de un mes de inactividad física, volver a entrenar en el gimnasio causará dolor muscular intenso, el mismo que será reducido considerablemente al mantener una frecuencia de entrenamiento regular.
- Al aprender la parte complicada de una canción en guitarra o piano, nuestras neuronas son expuestas a un estrés que, mientras más veces sea repetido – de manera enfocada
– , hará la tarea más sencilla hasta lograr dominarla.
A pesar de sonar contraproducente, estas son pruebas tangibles de los beneficios de desafiar nuestros temores e incomodidades frecuentemente. Y, mientras más lo hacemos, más confianza en nosotros mismos tenemos, por ende, pasamos del temor a la curiosidad por saber qué más somos capaces de lograr.
La mentalidad de Continuous Delivery permite a empresas como Amazon ejecutar Releases cada 11.6 segundos. Tal vez tu no requieras realizar deployments a esa velocidad, pero definitivamente quieres utilizar Continuous Delivery para para automatizar aquello que te causa dolor y así evitar problemas y horas extras en el día del Release.
Consejos para lograr Continuous Delivery
Planifica Releases frecuentes
- La cadencia recomendable de los Releases es entre 2 semanas a 2 meses. Coincidentemente es lo recomendado por Metodologías Ágiles – Principio #3.
- Si la organización de tu Equipo de Desarrollo está en base a Historias de Usuario y estas no caben en un Sprint, tienes dos alternativas:
- Haz tus historias más pequeñas. Siempre hay forma de reducirlas.
- Utiliza la técnica de Dark Launch para ocultar funcionalidad que no esta lista.
Automatiza el Deployment al 100%
- La instalación de Apps – especialmente si es algo tan sencillo como copiar/pegar archivos -, su configuración y verificación deben ser completamente automatizados.
- No existe una sola herramienta que cubra las necesidades particulares de cada App, pero sí existen bastantes lenguajes de Scripting que te ayudarán a personalizar el Deployment según tus necesidades. Ej: Python, PowerShell, Ruby, etc.
Ejecuta Tests antes del Deployment
- El proceso automatizado de Deployment (CD Pipeline) es como el muchacho de las pizzas
. Si los cocineros preparan una pizza gourmet, el muchacho la entregará rápidamente. Si los cocineros preparan 
, el muchacho la entregará…rápidamente 
. - No olvides que un Continuous Delivery exitoso va de la mano de Continuous Testing cuando las pruebas están automatizadas.
Utiliza “Placeholders” en tus archivos de configuración.
- Supongamos que planeas realizar el deployment de un Website, lo más probable es que este contenga un archivo web.config. Puesto que ya sigues la filosofía DevOps y la comunicación entre tus Devs y Ops es fluida, puedes coordinar con ambos equipos para tener “Placeholders” como el de este ejemplo:
<connectionString Server=”{APP-SERVER}” Database=”{APP-DB}”> - Donde {APP-SERVER} y {APP-DB} son los Placeholders que serán reemplazados con valores propios para los Ambientes donde dicho Website vivirá.
Crea un Ambiente de Testing o PreProduccion
- Ten por lo menos un ambiente sanitizado de Testing o PreProduccion que es una mini-versión de Producción.
- Como ya tienes tu deployment automatizado y además utilizas Placeholders para personalizar configuración por Ambiente, hacer el deployment en ambientes es pan comido.
Nadie se salva de empezar con Releases dolorosos, esta una especie de de “Bautismo de Fuego”. Siendo así, recuerda que desde el momento que los humanos dominamos al fuego
, nuestra evolución fue para arriba 
.
Cuál es tu experiencia con Deployments y Releases? Que otras sugerencias tienes?
Deja tu comentario y hagamos que más personas se beneficien.
Keep on learning…and Delivering!
