Las mejores buenas prácticas en DevOps

Cuando me pidieron que escribiera este artículo, la idea era escribir sobre lo que se debería hacer en DevOps frente a lo que no se debería hacer, pero, llamadme optimista: el simple hecho de usar DevOps en un proyecto reduce, y mucho, las posibilidades de cometer errores durante el desarrollo de un proyecto. Aun así, en este texto vamos a repasar las prácticas «menos buenas» en DevOps.

  • No apliques siempre la misma fórmula a todos los proyectos: A menudo veo cómo se aplican los mismos métodos entre clientes y proyectos, pero lo que muchas veces se pasa por alto es lo poco que tienen que ver entre sí. En DevOps, lo que funciona genial para un proyecto puede no servir para otro, y siempre es necesario un análisis previo de las necesidades. Entre otras cosas, se debe tener en cuenta cuántos programadores trabajarán al mismo tiempo, que entornos son los adecuados, si tiene un equipo de control de calidad, la frecuencia de las implementaciones de producción, si va a trabajar en Cloud u on premise… estos son solo algunos de los muchos factores a considerar y que no nos permiten reutilizar los mismos métodos entre proyectos.
  • Automatiza lo que puedas: En DevOps, siempre podrás automatizar todo lo que puedas para reducir los tiempos de liberación y evitar errores humanos. Por lo tanto, cuando sea posible, deben evitarse las implementaciones manuales de entornos, así como la actualización manual de las bases de datos. Básicamente, todo lo «manual» debe ser evitado.
  • Tu trabajo no se detiene en el despliegue: Puedes llegar allí, analizar las necesidades de tu cliente, implementar una metodología adecuada que se adapta al proyecto, pero… siempre se podrá mejorar el flujo para que las entregas sean más constantes y de mejor calidad. Por ello, no solo se debe introducir una buena metodología para el proyecto, también hay que hacerle un seguimiento constante, ya sea analizando registros, métricas, retroalimentación de desarrolladores o personas del sistema… hasta llegar a un punto en el que resulte muy difícil mejorarlo aún más.
  • Usa la administración de paquetes: En mi caso, uso VSTS, refiriéndome a Nuget y al feed VSTS, pero hay muchas otras herramientas disponibles. Siempre se debe evitar cargar dlls en proyectos, por lo que un sistema ideal sería el uso de paquetes Nuget y saber cómo crear las compilaciones necesarias para que se generen automáticamente (recuerda mi punto anterior: evita todo lo “manual”). En este punto, la mejor práctica será el uso de feeds para controlar la seguridad, la distribución y la automatización de nuestros paquetes.
  • Protege tus sucursales: Consume mucho tiempo sincronizar la sucursal y, una vez hecho, que no cumpla y buscar a la persona que no colocó el «;» para que puedan arreglarlo y cargarlo. Una buena práctica es tener tantas sucursales como entornos (aunque esto es discutible y depende de las preferencias). Sin embargo, lo que no debería ser negociable es si debes o no aplicar una política de integración continua en tu sucursal e iniciar varias compilaciones, para verificar que el código cumple y que todas las pruebas se hayan aprobado correctamente (hablaré sobre esto más tarde). Esto garantiza que la calidad del código que cargues en la rama principal sea el mínimo aceptable.
  • Utiliza correctamente compilaciones y lanzamientos: Las compilaciones son para la integración continua y las versiones para implementaciones en entornos. Esto nos permite poder organizar todo correctamente y regresar a los estados anteriores con muy poco esfuerzo.
  • Las pruebas son fundamentales: Debes exigir que se realicen las pruebas antes de validar nada. La mejor práctica es que las pruebas acompañen al desarrollo para poder encontrar errores en las etapas iniciales y que no los encuentren los usuarios en producción, por lo que se debe hacer un esfuerzo especial para que los desarrolladores comprendan la importancia de las pruebas desde el principio.
  • Habla, habla, habla y, después, habla un poco más: Como mencionamos en el primer punto, no todos los proyectos son iguales, y DevOps tiene que estar en el medio de todo: los desarrolladores, que se quejan de que pierden mucho tiempo porque tienen que validar el código (lo que a nadie le gusta hacer); sistemas e infraestructura, que quieren que todo esté seguro y no les gusta que estés allí en el medio; el cliente, que desea ver su proyecto un mes en producción; y tú mismo, con la responsabilidad de hablar con todas las partes, tratar de hacerles la vida más fácil a veces, o complicada en otras ocasiones. El bien del proyecto.

Podría seguir y seguir, y como mencioné al principio, cada proyecto es un mundo diferente y las cosas consideradas importantes en algunos proyectos no serán importantes en otros, pero a priori, creo que hemos cubierto los puntos más importantes. Os dejaré con mi primera reflexión solo por el mero hecho de incluir DevOps en su proyecto: es beneficioso, y lo único que tendrás que hacer es mejorar el flujo para mejorar la calidad, la velocidad de entrega y las reducciones en el mantenimiento de la producción ?