Inicio / Reportajes / ¿Qué es DevOps?

¿Qué es DevOps?

¿Qué es DevOps?

Como es evidente por el aumento de las conferencias, libros y herramientas de software, hay un creciente énfasis en la mejora de DevOps dentro de las organizaciones de desarrollo de software, independientemente de su tamaño.

La pregunta que sigue es típicamente: “¿Qué es DevOps?” Esta es una pregunta absolutamente comprensible. No sólo es un movimiento relativamente reciente dentro de la comunidad del software, pero la máquina de marketing comercial se ha hecho cargo de la propiedad del término, adaptándolo a sus necesidades.

Esto no es nada nuevo. SOA, ESB, y el cloud computing han recibido tratamientos similares. Hace cuatro o cinco años, una gran cantidad de productos de integración se renombró rápidamente ESB y SOA fue infamemente declarado muerto debido al nivel del bombo de la comercialización. Ni siquiera había empezado la Campaña publicitaria de Microsoft “a la nube!” para su software de edición de imágenes.

Sí, pero en realidad, ¿Qué es DevOps?

Históricamente, los gerentes de producto, analistas de negocio y los ingenieros de software trabajarían juntos para organizar un plan de lanzamiento, con historias de usuarios secuenciadas en iteraciones que se podría volver a priorizar en cada límite de iteración. Mientras que cada iteración se supone que terminará con una versión del sistema “lista para la producción”, aunque no ha sido tanto así como se puede constantar con la producción regular.

Más a menudo, la salida de una iteración hace que sea sólo hasta una “prueba” o “puesta en escena” del medio, porque en realidad llevar a la producción requiere muchos más pasos: agrupación del código, empaquetado del producto, aprovisionamiento del medio ambiente, e interminables horas de coordinación con el personal de operaciones.

La gente comenzó a darse cuenta de que una mentalidad del tipo “tiro por encima del muro” del desarrollo a las operaciones era apenas una parte de un desafío, ya que solía conformarse con tener que tirar los requisitos sobre la pared y sentarse a la espera de que esta le devuelva el código. La gente empezó a desdibujar las líneas entre las tareas de desarrollo, como las tareas de codificación y de despliegue operacional, tales como el aprovisionamiento de servidores, de ahí el nombre “DevOps.”

Lo siento pero todavía no veo una clara definición.

Como se mencionó anteriormente, el término DevOps se ha utilizado para muchas áreas: herramientas de aprovisionamiento de infraestructura automatizada (por ejemplo, Chef y Puppet) y automatización de herramientas (por ejemplo, la integración continua como Jenkins), así como para el establecimiento de entornos de trabajo de desarrolladores para reflejar la producción (por ejemplo, Vagrant).

Personalmente utilizo el término “DevOps” para definir un conjunto de prácticas, herramientas y políticas que conduzcan a la mejora de la calidad y la entrega automatizada (EA). En muchos sentidos, el despliegue rápido y frecuente a la producción reduce el riesgo, como cualquier comunicado que contiene menos cambios. Y soluciones las soluciones que se encuentran para los problemas son más fáciles de implementar o, en su defecto, los cambios más pequeños suelen ser más fáciles de revertir.

Así, DevOps ¿es lo mismo que Automatizado o Despliegue Continuo?

Casi lo entiendes. DevOps, en cierto modo, es todo lo que va a hacer el TDA/CD posible. En muchos sentidos, DevOps trata de asegurar la calidad en todas las etapas.

Puedes visualizar DevOps como una cinta transportadora, donde muchos pesos y contrapesos están en su lugar, en todas las etapas, para asegurar que cualquier paquete que transporta la cinta se retira si no es lo suficientemente bueno, y entregado al final de la cinta (por ejemplo, la producción) si es realmente seguro y fiable.

¿Por qué debería importarme? ¿Qué hará DevOps por mí?

Las prácticas y procedimientos en DevOps conducen a aligerar los aspectos típicamente pesados en el desarrollo de software y la implementación. Tirando de la instalación y la conciencia más temprano en el ciclo de desarrollo de la infraestructura, las sorpresas de las diferencias de un ambiente a otro se reducen significativamente.

Mediante el establecimiento de los despliegues automatizados consistentes, confiables y repetibles, los errores humanos y la necesidad de expertos bomberos se reducen. El Proyecto Phoenix (Kim, Behr, Spafford) es un buen material de lectura sobre el tema y narra el cambio de una organización para adoptar estas prácticas de manera gradual y priorizada. Uno de los puntos clave del libro es que si bien llevar a cabo el primer paso puede resultar bastante difícil, pero permite que el siguiente paso sea más fácil.

Definiendo DevOps y su integración en todos los niveles del Proceso

La mayor parte de las charlas, herramientas y procesos en torno a DevOps pueden resultar intimidantes. La hercúlea tarea de la transición hacia la automatización total, el trabajar con múltiples versiones de producción por día puede ser desalentador. La verdad es que simplemente no se necesita nivel de automatización para todos los productos o empresas.

La forma en que los clientes incorporan DevOps en sus prácticas varía enormemente; algunos todavía quieren un proceso formal “hand off”, que los puristas se muestran en contra del DevOps. Para estos clientes, un sistema final totalmente automatizado en extremo puede transmitir demasiado riesgo. Haz lo necesario para aliviar el dolor más grande para su organización en el desarrollo de liberar el proceso. Al igual que en la programación ágil, realizar pasos graduales hacia la meta final es la forma más eficaz y fiable de llegar a la meta.

Las empresas de productos de software comúnmente pretenden estar por delante de su competencia con el lanzamiento de nuevos productos y características rápidamente al mercado. Cuando lo que se espera es que los ágiles equipos de desarrollo de productos puedan adaptarse a los cambios del negocio y retos, manteniendo altos estándares de calidad.

Más clientes están reconociendo la necesidad de, y pedir ayuda con, el desarrollo de estrategias efectivas para implementar continuamente nuevo software actualizado; aunque no lo crea hay demandas de mantenimiento de sistemas de hasta durante las veinticuatro horas del día; y de forma rápida y sin problemas para resolver problemas operativos rápidamente.

Si a decidido aprovechar las prácticas DevOps para ayudar a suavizar el peor momento en su ciclo, usted puede descubrir que su nivel de dolor se ha reducido hasta el punto más bajo ya que sus comunicados están en sincronía con la velocidad de la retroalimentación de los clientes, y puede mantener y/o afilar la piedra angular de sus procesos existentes.

Al igual que el desarrollo de software tradicional, la introducción de capacidades que no son necesarias o que tienen un alto valor siempre resultará en una pérdida de recursos para el desarrollo. Usted ya sabe que muchas demandas de negocio pueden ser manejados con prácticas y procesos DevOps. Es por eso que estoy emocionado por las iniciativas DevOps.

Acerca de Raul Romero

Me considero una persona Responsable y Pro-Activa, mis géneros preferidos son los juegos de estrategia y los shooter bélicos, mi gran pasión el mundo SEO.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *