Cinturones en DevOps – ¿cuál es el tuyo?

(Este artículo corresponde a la serie dedicada a DevOps)

Así que decidiste poner en práctica la filosofía DevOps. ¡Genial! ¿Pero…por dónde empezar? Thinking Face on Apple iOS 11.3

(Si tu respuesta es: “utilicemos Docker!” , buen intento pero…¡Docker NO ES DEVOPS!Oncoming Fist on Apple ).

Bueno, volviendo al tema, este post te brindará un mapa y compás para saber por dónde empezar y cuales son los pasos a seguir para convertirte en un cinturón negro en DevOps.

Continue reading “Cinturones en DevOps – ¿cuál es el tuyo?”

Continuous Delivery: Partos Sin Dolor

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.Baby on Google Android 9.0
    • Menos de 4 Releases por año es un pecado.
  • 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?” Lady Beetle on Apple iOS 11.3Lady Beetle on Apple iOS 11.3Lady Beetle on Apple iOS 11.3
  • Dev Box: el Ambiente de Pruebas
    • Me dices que el testing fue realizado en las máquinas de los Desarrolladores?Desktop Computer on WhatsApp 2.17 Estas consciente de que ese “ambiente” tiene el mismo grado de higiene que un toilet público en un concierto? Toilet on Apple iOS 11.3
  • 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 frecuentemente1 , 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.Flexed Biceps on Apple iOS 6.0
  • 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 enfocadaDirect Hit on Samsung Experience 9.5– , hará la tarea más sencilla hasta lograr dominarla.Musical Notes on Apple iOS 11.3

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 #3Winking Face on Apple iOS 11.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:
  1. Haz tus historias más pequeñas. Siempre hay forma de reducirlas.
  2. 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 pizzasMotor Scooter on Apple iOS 11.3Pizza on Apple iOS 11.3. Si los cocineros preparan una pizza gourmet, el muchacho la entregará rápidamente. Si los cocineros preparan Pile of Poo on Apple iOS 11.3, el muchacho la entregará…rápidamente Confused Face on Apple .
  • 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} {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 fuegoFire on Apple iOS 11.3, nuestra evolución fue para arriba Rocket on Apple .

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!

{We Code}

Yes… You – the least techy person reading this – You Code.

Here are some examples of common scenarios where we all code:

  • When a couple listens to a song and makes it theirs, they are unconsciously programming themselves to later associate that song with the love they feel for each other.
  • When you kindly (and repeatedly) ask your kid to look both ways before crossing the road, you are programming him/her to keep her safe when you’re not there.
  • When mom cooks my favorite meal. Anytime that I smell or order that dish in a restaurant, who do you think comes to mind?
  • When you press snooze on your alarm every morning, your programming your body to procrastinate. (On the other hand, getting out of bed immediately programs your body to get ready for a new round!)
  • When you program yourself to score every time you catch the ball, like Jerry Rice – the greatest wide receiver in NFL history – did. (Bo Eason explains how/why Jerry did that in minute 20:10 of this video).
  • Last but not least, when you listen to/see a notification on your phone and you react reading to it immediately. …well, let me introduce you to Ivan Pavlov and his cute dogs to explain what is called Classical Conditioning – another type of programming.

As with technology, we always have the chance to refactor the process – to restructure our initial behavior and responses to certain triggers.

Keep on Learning…..and Refactoring.

 

Image Source

 

 

Stand Up and Fight

Stand up and fight.

The battlefield is not in other men’s land, but it’s in our own minds.

We fight against the egoic mind, the one that says “I can’t”, “I am too old”, “I am poor”, the one that yells: “I am superior to…”, “I am inferior to…”

Stand up and fight.

We will use our courage as the shield and our intelligence as the sword, always alert because our own enemy plays never overt.

Like software, we uninstall our personal tyrant using crafty weapons and upgrade ourselves to newer versions. That’s how we create upgraded versions of the world we live in.

Today…We Stand Up and Fight!

 

CI/CD in real life

CI/CD or Continuous Integration and Delivery is not related to software and technology exclusively.

CI/CD means – overall – Continuous Integration of lessons into our minds and Continuous Delivery of digested knowledge for the benefit of something bigger than us (our family, society, planet).

Both of them are enabled by a key principle – Continuous Learning – and their output is much more than simply mobile apps or websites; they create Kaizen (Continuous Improvement), that kicks dopamine in our brains and triggers curiosity to learn more in an infinite loop.

IMG_9465

Keep on learning…