Cómo triunfa DevOps

Los enfoques DevOps se remontan a finales de la década de 1990, por lo que en principio no son nada nuevo. Sin embargo, muchos proyectos siguen sin dar el resultado deseado. Basándose en su propia experiencia de numerosos proyectos DevOps de clientes, Consol muestra qué cinco puntos deben tenerse siempre en cuenta.

1. abordar activamente el cambio cultural

Está claro que, en un principio, existe un conflicto de intereses entre el desarrollo y la explotación. Mientras que la creatividad y la flexibilidad son importantes para el desarrollador, los principales criterios para las operaciones informáticas son la estabilidad y la disponibilidad.

Si, como parte de una estrategia DevOps, los desarrolladores y los responsables de las operaciones de TI ahora trabajan juntos en equipos en el diseño, el desarrollo, las pruebas y el funcionamiento de las aplicaciones, esto requiere no solo cambios organizativos, sino también un cambio cultural.

Esto también significa, por ejemplo, que los miembros del equipo tienen que familiarizarse con los requisitos y procesos respectivos tanto de desarrollo como de operaciones.

El tema del cambio en la cultura corporativa debe abordarse activamente con la implicación de la dirección al inicio del proyecto DevOps para descartar de forma fiable futuras pérdidas por fricción en los equipos interdisciplinares.

2. considerar el volumen de inversión

Está claro que los proyectos DevOps implantados con éxito aportan numerosos beneficios a medio y largo plazo: desde mayor calidad y flexibilidad hasta ciclos de lanzamiento de software más rápidos y ahorro de costes.

Sin embargo, esto sólo puede lograrse si se realiza la inversión inicial necesaria. A menudo este no es el caso. Todas las empresas deben ser conscientes de que la introducción de DevOps siempre va asociada inicialmente a un aumento de los costes de TI.

Por lo tanto, la dirección de la empresa debe participar en los proyectos DevOps desde el principio y proporcionar apoyo a largo plazo para todas las decisiones de inversión necesarias.

3. utilizar un entorno de simulación

Los procesos de desarrollo y producción difieren considerablemente. Por ejemplo, las aplicaciones en producción siempre están integradas en un entorno de sistemas más amplio.

Los desarrolladores, por su parte, suelen trabajar de forma completamente independiente con software en su PC de sobremesa o portátil, sin que éste disponga de la conexión necesaria a un sistema SAP, por ejemplo.

Proporcionar al desarrollador una licencia SAP monopuesto en tal caso no suele ser una opción viable sólo por razones de coste, por lo que no suele hacerse y los errores en el software están prácticamente programados.

La alternativa es utilizar un entorno de simulación. Sin embargo, muchas empresas siguen sin hacerlo, aunque no esté necesariamente asociado a costes elevados.

También existen productos económicos de código abierto como Citrus de Consol (www.citrusframework.org), un marco independiente de la plataforma que puede utilizarse de forma flexible para una amplia variedad de tecnologías y protocolos.

4. eliminar los pasos manuales del proceso

Para aprovechar todas las ventajas de DevOps, todos los procesos deben automatizarse en la medida de lo posible. Sin embargo, las actividades manuales siguen estando a menudo a la orden del día, especialmente en el ámbito de las pruebas.

No es infrecuente que los departamentos especializados comprueben manualmente la integridad funcional de una aplicación, lo que requiere mucho trabajo. Sin embargo, esto contradice el enfoque DevOps, cuyo objetivo es contribuir a un suministro más rápido de software.

Algunas empresas también siguen fieles al enfoque manual porque una serie de herramientas de pruebas también llevan asociados unos costes nada desdeñables. Sin embargo, es evidente que esto no basta, ya que también existen soluciones de código abierto en este ámbito que ofrecen una funcionalidad de pruebas completa: desde pruebas funcionales, de carga y de rendimiento hasta pruebas de extremo a extremo.

5. reducir las roturas del sistema

Incluso en las estructuras DevOps, los entornos de desarrollo, integración y producción suelen considerarse de forma aislada. Se utilizan herramientas independientes en cada área, pero no se vinculan entre sí como soluciones aisladas.

Esto tampoco se corresponde con el concepto integrador real de DevOps. El objetivo debe ser garantizar una interconexión centralizada. También aquí muchas empresas -a menudo por ignorancia- no ven posibilidades.

Sin embargo, esto también es una falacia; solo hay que pensar en las herramientas del entorno OpenShift o Ansible.