5 pasos para implementar una estrategia DevOps con menos fricción

Los equipos que buscan aumentar la colaboración y acelerar los despliegues están entusiasmados con la idea de Low-Ops. Es la combinación ideal entre la seguridad de Git y la rapidez de los clics. Sin embargo, pasar de cambios manuales a un flujo de entrega unificado puede parecer abrumador. Cambiar de proceso puede ser complicado para los integrantes del equipo y provocar más errores a corto plazo.

Por eso creamos esta guía. No necesitas transformar todo el proceso en un día. Todo cambio exitoso y duradero se logra de forma gradual y con una amplia adopción. Esta guía te ayudará a enfocarte en las personas y los procesos antes de cambiar de herramientas. Juntos, veremos cómo hacer cambios realistas y manejables en tu proceso DevOps a partir de hoy.

Paso 1: Audita tus puntos de fricción actuales

Es difícil saber qué queremos cambiar sin entender bien de dónde surge el problema. La mejor forma de iniciar la transición a un proceso nuevo es auditar el anterior. Empieza por revisar tus últimos tres lanzamientos. ¿Dónde se produjeron los retrasos?

Para la mayoría de los equipos, los retrasos provienen de una de tres áreas clave. Veamos cada una:

• Primero, revisa el seguimiento de metadatos. ¿Todavía se usan hojas de cálculo para registrar los cambios? Esta es una fuente importante de errores.
• Segundo, revisa las divergencias entre entornos. ¿Tus sandboxes reflejan tu organización de producción? Si no es así, los despliegues siempre serán complicados.
• Tercero, revisa el traspaso de trabajo. ¿Cómo entregan los administradores su trabajo a los desarrolladores? Si se requiere un documento manual, tienes un punto de fricción.

Si tienes fricción en una o más de estas áreas, ¡no te preocupes! No puedes mejorar lo que no mides.

Paso 2: Establece una única fuente de verdad

Para la mayoría de las empresas, esta “fuente de verdad” es su organización de producción. Eso funciona para equipos pequeños o que no despliegan cambios con frecuencia. No es sostenible usar tu código EN PRODUCCIÓN para experimentar y hacer pruebas. En un entorno Low-Ops, lo ideal es que la “fuente de verdad” sea algo que todos puedan ver y con lo que puedan interactuar sin tener que hacer cambios en producción. Recomendamos Git.

A tu administrador no le gustará este cambio. Está acostumbrado a ver su trabajo directamente en la organización. Pasar a un sistema nuevo le generará temor. Pero es importante dejar claro que ni él ni Git son el problema.

En lugar de frustrarte constantemente por datos incorrectos, tendrás un flujo continuo de datos precisos para consultar. Git asume el papel de una máquina del tiempo. Sin esfuerzo ni tiempo adicional para tus administradores, registrará cada cambio. Así, nunca tendrás que preguntarte qué cambió y cuándo: podrás consultar los cambios cuando lo necesites.

En el aspecto técnico, cada integrante del equipo necesitará acceso a Git. Sin embargo, no todos necesitan usar la línea de comandos. Recomendamos una herramienta que conecte tus sandboxes directamente con las ramas de Git.

Así, tus administradores pueden guardar un pequeño cambio sin problemas. Git se actualizará automáticamente. Esto mantiene la fuente de verdad precisa sin esfuerzo adicional.

Paso 3: Alinea tu estrategia de entornos

Low-Ops requiere una estrategia clara de sandboxes. Recomendamos usar una rama por sandbox para mantener una separación clara.

¿Cómo funciona esto en la práctica? Cada integrante del equipo tiene su propio sandbox, vinculado a su propia rama de Git. Las ramas y los sandboxes individuales ayudan a evitar que las personas sobrescriban el trabajo de los demás o interfieran entre sí.

Cuando se realiza una actualización, el usuario la mueve a un sandbox de integración compartido. Con un flujo de trabajo Low-Ops, basta un clic para enviar el trabajo a su nuevo destino.

Git se encargará de la fusión en segundo plano. Si hay un conflicto, se resaltará claramente. Una plataforma como Blue Canvas te permite comparar el código lado a lado para ver qué cambió y dónde está el conflicto, y así encontrar una solución.

Paso 4: Automatiza las “tareas tediosas”

DevOps no se trata solo de código nuevo y despliegues emocionantes; también hay muchas tareas repetitivas. Es la parte de “operaciones” del desarrollo. Estas tareas, a menudo tediosas y recurrentes, incluyen:

• Validar paquetes
• Ejecutar pruebas unitarias
• Comprobar conflictos de perfiles y permisos
• Y más

Para convertir tu “DevOps” en “Low-Ops”, debes automatizar estas tareas. El escenario ideal sería:

• El usuario envía su trabajo
• Se verifica de forma automática e inmediata

Estas verificaciones deben responder dos preguntas clave:

• ¿Este cambio rompe alguna dependencia?
• ¿Cumple con la cobertura de pruebas requerida?

Si la respuesta a cualquiera de las preguntas es no, el sistema debe avisar al usuario de inmediato. Las pruebas automatizadas que ofrecen resultados rápidos y claros ayudan a detectar errores a tiempo. Adoptar este tipo de pruebas evita que un pequeño error se convierta en una interrupción en producción.

Paso 5: Fomenta una cultura de revisión entre pares

Para crear con éxito una cultura Low-Ops, tu equipo deberá adoptar la revisión entre pares mediante las solicitudes de incorporación de cambios (PR) de Git. Al integrar las PR en tu flujo de trabajo, podrás revisar de forma rápida y eficaz el trabajo que tus compañeros están fusionando y comprobar la lógica con criterio humano.

En el enfoque tradicional de “DevOps”, los administradores quedan fuera de este proceso. En un flujo de trabajo Low-Ops, participan junto con los desarrolladores.

La ventaja es que un desarrollador sénior puede revisar la lógica de los flujos de un administrador, mientras que un administrador puede verificar que el código Apex de un desarrollador esté alineado con el negocio. Así, ambas partes realizan un trabajo productivo, acorde con su experiencia y conocimientos, e involucran a todo el equipo para mantener la motivación.

La mejor forma de usar las solicitudes de incorporación de cambios es centrar las revisiones en la calidad y el aprendizaje. Con la ayuda de una herramienta visual de comparación, puedes mostrar exactamente qué cambió en la interfaz. Esto permite que todos participen en el proceso de revisión.

Paso 6: Mide e itera

Cuando actualices tus procesos, es importante recordar que Low-Ops no es un destino final. Avanzamos hacia una mejor forma de trabajar y, como con cualquier mejora, siempre habrá más por hacer.

Un par de buenos puntos de partida son:

• Monitorea tu «frecuencia de implementación». ¿Con qué frecuencia lanzas a producción?
• Monitorea tu «tasa de fallas en los cambios». ¿Cuántas implementaciones causan un problema?

La buena noticia es que, a medida que tu equipo se sienta más cómodo con este proceso, ¡verás que estas cifras mejoran! Una mayor velocidad es el resultado natural de una confianza sólida en el sistema. Construirla tomará tiempo al principio, pero permitirá optimizar los resultados a medida que el sistema crezca.

Resumen de la implementación de Low-Ops

Conclusión: El objetivo es la fluidez

Aunque low ops puede sonar como si estuvieras preparando a tu equipo para fracasar, se refiere al esfuerzo continuo necesario para crear valor para tu equipo. El objetivo es que los administradores y desarrolladores puedan gestionar tickets y entregar código sin complicaciones.

La clave de este proceso es hacer que tus herramientas trabajen para tu equipo. Así, tu equipo puede trabajar para tus clientes. ¿La mejor noticia? No necesitas formar parte de un enorme equipo empresarial para querer optimizar y asegurar tu proceso de implementación. De hecho, te recomendamos hacerlo antes de llegar a ese punto. 😉

Solo necesitas un camino claro y la filosofía adecuada. Empieza poco a poco. Resuelve un punto de fricción a la vez. Pronto, tu equipo avanzará más rápido de lo que jamás imaginaste.