Contacto: 881 94 19 61 - info@openinnova.es

DevOps Qué Es? Desarrollo Software. Descúbrelo

DevOps Qué Es? Desarrollo Software. Descúbrelo

DevOps Qué Es? Vamos a responder a esta fundamental pregunta. Para ayudarte a impulsar a tu empresa al éxito en los negocios. En el mundo de hoy en día. Tan cambiante y que tantos retos nos obliga a enfrentar continuamente.

DevOps nos ha ayudado a hacer lanzamientos muy frecuentes. Lo que nos ha dado una ventaja en el mercado. Ahora podemos realizar lanzamientos diarios de productos en lugar de lanzamientos de 6 meses y enviar correcciones a nuestros clientes en un lapso de pocas horas.

DevOps es un conjunto de prácticas que automatiza los procesos entre el desarrollo de software y los equipos de TI, para que puedan construir, probar y lanzar software de forma más rápida y confiable. El concepto de DevOps se basa en la construcción de una cultura de colaboración entre equipos que históricamente funcionó en silos separados. Los beneficios prometidos incluyen mayor confianza, versiones de software más rápidas, capacidad para resolver problemas críticos rápidamente y administrar mejor el trabajo no planificado.

En su Esencia. DevOps es una Cultura, un Movimiento, una Filosofía.

Es un firme apretón de manos entre el desarrollo y las operaciones que enfatiza un cambio de mentalidad. Una mejor colaboración y una integración más estrecha. Unifica la entrega ágil, continua, la automatización y mucho más. Para ayudar a los equipos de desarrollo y operaciones a ser más eficientes, innovar más rápido y brindar mayor valor a las empresas y a los clientes.

Historia de DevOps

El movimiento DevOps comenzó a unirse en algún momento entre 2007 y 2008. Cuando las comunidades de desarrollo de software y operaciones de TI se dieron a conocer acerca de lo que consideraban un nivel de disfunción fatal en la industria.

Se opusieron al modelo de desarrollo de software tradicional. Que requería que quienes escriben el código estén organizados y separados aparte de quienes implementan y aceptan ese código.

Los desarrolladores y los profesionales de TI / Operaciones tenían objetivos separados (ya menudo competidores). Líderes de departamentos separados, indicadores clave de desempeño por los cuales fueron juzgados y, a menudo, trabajaban en pisos separados o incluso en edificios separados. El resultado fue que los equipos en silos se preocuparon sólo por sus propios feudos, largas horas, lanzamientos fallidos y clientes insatisfechos.

Hablar

Seguramente hay una mejor manera. Dijeron. Así que las dos comunidades se juntaron y comenzaron a hablar, con personas como Patrick Dubois, Gene Kim y John Willis dirigiendo la conversación.

Estás utilizando metodologías ágiles para la planificación y el desarrollo. Pero aún luchas por sacar ese código de la puerta sin un montón de drama. Has escuchado algunas cosas sobre DevOps y el efecto aparentemente mágico que puede tener en los equipos y piensa «Quiero algo de esa magia».

La mala noticia es que DevOps no es magia. Y las transformaciones no ocurren de la noche a la mañana. La buena noticia es que no tiene que esperar a que la alta gerencia lance una iniciativa a gran escala. Al comprender el valor de DevOps y realizar pequeños cambios incrementales. Su equipo puede embarcarse en el viaje de DevOps de inmediato. Echemos un vistazo a cada uno de estos beneficios en detalle.

La infraestructura como código nos permitió realizar 10 veces más construcciones sin agregar una sola persona a nuestro equipo.

Colaboración y Confianza

La cultura es el factor primero de éxito en DevOps. La creación de una cultura de responsabilidad compartida. Transparencia y retroalimentación más rápida es la base de todo equipo de alto rendimiento de DevOps.

Los equipos que trabajan en silos a menudo no se adhieren al ‘pensamiento de sistemas’ de DevOps. ‘Pensamiento sistémico’ es ser consciente de cómo sus acciones no solo afectan a su equipo, sino a todos los demás equipos involucrados en el proceso de lanzamiento. La falta de visibilidad y los objetivos compartidos significan una falta de planificación de la dependencia, prioridades desalineadas, señalar con el dedo y la mentalidad de «no es nuestro problema». Lo que resulta en una velocidad más lenta y una calidad inferior a la normal. DevOps es el cambio en la mentalidad de ver el proceso de desarrollo de forma integral y romper la barrera entre Dev y Ops.

Libera Más Rápido y Trabaja de Forma más Inteligente

La velocidad lo es todo. Los equipos que practican DevOps lanzan más frecuentemente. Con mayor calidad y estabilidad.

La falta de ciclos automatizados de prueba y revisión bloquea el lanzamiento a la producción y el mal tiempo de respuesta a incidentes mata la velocidad y la confianza del equipo. Las herramientas y procesos dispares aumentan el OPEX, conducen a un cambio de contexto y ralentizan el impulso. A través de la automatización. Las herramientas y procesos estandarizados, los equipos pueden aumentar la productividad y lanzar con más frecuencia con menos contratiempos.

Acelerar el Tiempo de Resolución

El equipo con el bucle de retroalimentación más rápido es el equipo que prospera. La transparencia total y la comunicación perfecta permiten a los equipos de DevOps minimizar el tiempo de inactividad y resolver problemas más rápido que nunca.

Si los problemas críticos no se resuelven rápidamente. Los problemas clave se escapan a través de las grietas en ausencia de comunicación abierta. Lo que resulta en una mayor tensión y frustración entre los equipos. La comunicación abierta ayuda a los equipos de desarrollo y operaciones a resolver problemas. Corregir incidentes y desbloquear el flujo de lanzamiento más rápido.

Gestionar Mejor el Trabajo no Planificado.

El trabajo no planificado es una realidad que enfrenta cada equipo. Una realidad que con mayor frecuencia afecta la productividad del equipo. Con procesos establecidos y una clara asignación de prioridades, los equipos de desarrollo y operaciones pueden gestionar mejor el trabajo no planificado mientras continúan centrándose en el trabajo planificado.

La transición y la priorización del trabajo no planificado en diferentes equipos y sistemas es ineficiente, además distrae del trabajo en cuestión. Sin embargo, a través de una mayor visibilidad y una retrospección proactiva, los equipos pueden anticipar y compartir mejor el trabajo no planificado.

Cultura

Si pudiéramos resumir la cultura de DevOps en una palabra, sería «colaboración«, y si se nos permitieran dos palabras, serían «colaboración multifuncional«.

Todas las herramientas y la automatización en el mundo son inútiles si no están acompañadas por un deseo genuino por parte de los profesionales de desarrollo y TI / Operaciones de trabajar juntos. Porque DevOps no resuelve problemas de herramientas. Resuelve problemas humanos. Por lo tanto, es poco probable que un día saques la cabeza del cubículo, mires a tu alrededor y descubras que los equipos de tu empresa representan la cultura de DevOps. Pero hay cosas simples que puedes hacer para nutrirlo.

Piense en DevOps como ágil. Pero con las operaciones incluidas. La formación de equipos orientados a proyectos o productos para reemplazar equipos basados ​​en funciones es un paso en la dirección correcta. Incluya desarrollo, control de calidad, gestión de productos, diseño, operaciones, gestión de proyectos y cualquier otro conjunto de habilidades que el proyecto requiera. En Openinnova, incluso integramos el marketing con nuestros equipos de productos.

Colaboración

Pocas cosas fomentan la colaboración como compartir un objetivo común y tener un plan para alcanzarla juntos. En algunas compañías, cambiar repentinamente a equipos basados ​​en proyectos es demasiado, demasiado pronto. Así que toma pasos más pequeños. Los equipos de desarrollo pueden, y deben, invitar a los miembros apropiados del equipo de operaciones a unirse a las sesiones de planificación de sprint, las reuniones diarias y las demostraciones de sprint. Los equipos de operaciones pueden invitar a desarrolladores clave.

Es una forma ágil y orgánica de mantenerse al tanto de los proyectos. Ideas y luchas de los demás. El tiempo dedicado a la escucha y la polinización cruzada del conocimiento del área temática se amortizan al hacer que la administración de lanzamientos y la resolución de problemas de emergencia sean mucho más eficientes.

Emergencias

Y hablando de emergencias, son una prueba efectiva de la cultura de DevOps. ¿Los desarrolladores, las operaciones y la atención al cliente se enredan en el problema y lo resuelven en equipo? ¿Todos comienzan con la suposición de que sus compañeros de equipo tomaron las mejores decisiones posibles con la información y los recursos que tenían en ese momento? ¿Es el incidente post-mortem sobre los procesos de fijación en lugar de señalar con el dedo? Si la respuesta es «sí». Es una buena indicación de que su equipo funciona con la cultura DevOps en su núcleo.

Tenga en cuenta que las compañías más exitosas están en la cultura de DevOps en todos los departamentos y en todos los niveles del organigrama. Cuentan con canales abiertos de comunicación, y hablan regularmente. Se aseguran de que los objetivos de todos estén alineados y se ajusten según sea necesario. Suponen que mantener contentos a los clientes es tan responsabilidad de la gerencia del producto como responsabilidad del equipo de desarrollo. Entienden que DevOps no es el trabajo de un equipo. Es el trabajo de todos.

Los equipos que practican DevOps implementan 30 veces más frecuentemente. Tienen 60 veces menos fallas y se recuperan 160 veces más rápido.

Automatización

Invertir en automatización elimina el trabajo manual repetitivo. Produce procesos repetibles y crea sistemas confiables.

La automatización de compilación, prueba, despliegue y aprovisionamiento son puntos de partida típicos para los equipos que aún no los tienen en su lugar. ¿Qué mejor razón para que los desarrolladores, evaluadores y operadores trabajen juntos que los sistemas de construcción para beneficiar a todos?

Los equipos nuevos en automatización generalmente comienzan con la entrega continua: la práctica de ejecutar cada cambio de código a través de un conjunto de pruebas automatizadas, a menudo facilitadas por la infraestructura basada en la nube. Luego empaquetando las compilaciones exitosas y promoviéndolas hacia la producción mediante implementaciones automatizadas. Como puede imaginar. La entrega continua no es una tarea rápida y fácil de configurar. Pero el retorno de la inversión vale la pena.

¿Por qué? Las computadoras ejecutan las pruebas de forma más rigurosa y fiel que los humanos. Estas pruebas detectan errores y fallas de seguridad antes, lo que permite a los desarrolladores solucionarlos más fácilmente. Y las implementaciones automáticas alertan a los operadores de TI / Operaciones a la «deriva» del servidor entre entornos. Lo que reduce o elimina las sorpresas cuando llega el momento de la publicación.

Nuevas Ideas

Otra de las principales contribuciones de DevOps es la idea de “configuración como código”. Los desarrolladores se esfuerzan por crear aplicaciones modulares y compactables porque son más confiables y mantenibles. Ese mismo pensamiento se puede extender a la infraestructura que los hospeda. Ya sea que viva en la nube o en la red propia de la empresa.

Es cierto que los sistemas siempre están cambiando. Pero podemos crear una fachada de inmutabilidad mediante el uso de código para el aprovisionamiento, de modo que el reabastecimiento de un servidor comprometido sea más rápido que repararlo. Sin mencionar que es más confiable. También reduce el riesgo. Tanto el desarrollo como las operaciones pueden incorporar nuevos lenguajes o tecnologías a través del código de aprovisionamiento y compartir las actualizaciones entre sí. Los problemas de compatibilidad se hacen evidentes de inmediato. En lugar de manifestarse en medio de una versión.

Configuración como Código

La «configuración como código» y la «entrega continua» no son los únicos tipos de automatización vistos en el mundo de DevOps. Pero merecen una mención especial porque ayudan a romper el muro entre el desarrollo y las operaciones. Y cuando DevOps usa implementaciones automatizadas para enviar código probado exhaustivamente a entornos aprovisionados de forma idéntica, «¡Funciona en mi máquina!» Se vuelve irrelevante.

Apoyarse

Cuando escuchamos «lean» en el contexto del software. Generalmente pensamos en eliminar actividades de poco valor y movernos rápidamente, escalar, ser ágiles. Aún más relevantes para DevOps son los conceptos de mejora continua y la aceptación de fallas.

Una mentalidad de DevOps ve oportunidades de mejora continua en todas partes. Algunos son obvios. Cómo mantener retrospectivas regulares para que los procesos de su equipo puedan mejorar. Otros son sutiles, como A / B que prueba diferentes enfoques de incorporación para los nuevos usuarios de su producto.

Tenemos un desarrollo ágil que agradecer por hacer de la mejora continua una idea general. Los primeros en adoptar la metodología ágil demostraron que un producto simple en manos de los clientes de hoy es más valioso que un producto perfecto en manos de los clientes dentro de seis meses. Si el producto se mejora continuamente, los clientes se quedarán.

Fracaso

Y adivina qué: el fracaso es inevitable. Por lo tanto. Podría configurar su equipo para que lo absorba, se recupere y aprenda de él. En Openinnova. Creemos que si no estás fallando de vez en cuando. No te estás esforzando lo suficiente.

Contratamos personas inteligentes y ambiciosas y esperamos que fracasen a veces.

En el contexto de DevOps. El fracaso no es un delito punible. Los equipos asumen que las cosas van a tener forma de pera en algún momento, por lo que se desarrollan para una detección rápida y una recuperación rápida. Los postmortems se centran en dónde cayeron los procesos y cómo fortalecerlos, no en qué miembro del equipo completó el código. ¿Por qué? Porque la mejora continua y el fracaso van de la mano.

DevOps ha evolucionado para que el desarrollo posea más operaciones. Nuestros ingenieros son responsables del control de calidad, la escritura y la ejecución de sus propias pruebas para distribuir el software a los clientes.

Medición

Es difícil demostrar que sus esfuerzos de mejora continua realmente están mejorando cualquier cosa sin datos. Afortunadamente, hay un montón de herramientas y tecnologías para medir el rendimiento, como cuánto tiempo pasan los usuarios en su producto. Si la publicación del blog generó ventas o la frecuencia con la que aparecen alertas críticas en sus registros.

Aunque puede medir casi cualquier cosa. Eso no significa que tenga (o deba) medir todo. Toma una página de desarrollo ágil y comienza con lo básico:

  • ¿Cuánto tiempo se tardó en pasar del desarrollo al despliegue? 
  • ¿Con qué frecuencia ocurren errores o fallas recurrentes?
  • ¿Cuánto tiempo lleva recuperarse después de una falla del sistema?
  • ¿Cuántas personas están usando tu producto en este momento?
  • ¿Cuántos usuarios ganó / perdió esta semana?

Base Sólida

Con una base sólida en su lugar. Es más fácil capturar métricas más sofisticadas sobre el uso de funciones. Los viajes de los clientes y los acuerdos de nivel de servicio (SLA). La información que obtiene es útil cuando llega el momento de trazar mapas y especificar su próximo gran movimiento.

Todos estos datos jugosos ayudarán a su equipo a tomar decisiones. Pero es aún más poderoso cuando se comparte con otros equipos, especialmente equipos en otros departamentos. Por ejemplo, su equipo de marketing quiere nuevas funciones brillantes que puedan vender. Pero mientras tanto. Está viendo una alta rotación de clientes porque el producto está inundado de problemas técnicos. Proporcionar datos de usuario que respalden su hoja de ruta, incluso si tiene pocas características y muchas correcciones, facilita la creación de consenso y la participación de los interesados.

Conclusión

La larga fricción entre los equipos de desarrollo y operaciones se debe en gran medida a la falta de un terreno común. Creemos que compartir la responsabilidad y el éxito contribuirá en gran medida a superar esa brecha. Los desarrolladores pueden ganar una buena voluntad instantánea ayudando a llevar una de las mayores cargas de las operaciones: el buscapersonas. A DevOps le gusta la idea de que las mismas personas que crean una aplicación deberían involucrarse en el envío y la ejecución.

Esto no significa que usted contrate desarrolladores y simplemente espere que sean excelentes operadores también. Significa que los desarrolladores y los operadores se emparejan entre sí en cada fase del ciclo de vida de la aplicación.

Evolución Continua

Los equipos que adoptan DevOps a menudo tienen un rol rotativo en el que los desarrolladores resuelven los problemas detectados por los usuarios finales y, al mismo tiempo, solucionan problemas de producción. Esta persona responde a los problemas urgentes informados por el cliente. Creando parches cuando sea necesario y resuelve el problema de los defectos informados por el cliente. El «desarrollador en soporte» aprende mucho sobre cómo se utiliza la aplicación en la naturaleza. Y al estar altamente disponibles para el equipo de operaciones, los equipos de desarrollo generan confianza y respeto mutuo.

Atravesar los momentos difíciles hace que celebrar éxitos sea aún más dulce. Sabrá que la cultura de DevOps se ha afianzado en su empresa cuando vea que el equipo de desarrollo trae donuts para el equipo de operaciones el día del lanzamiento.

La retroalimentación positiva de nuestros compañeros nos motiva tanto como nuestras nóminas y nuestras ambiciones profesionales. Reconocer públicamente a un compañero de equipo que detectó un error desagradable antes de que se activara significa mucho. Si su departamento tiene un presupuesto discrecional para las felicitaciones de los empleados. ¡No lo deje ir sin usar!

Openinnova
Soluciones Software Libre para Empresas. Nuestro Trabajo. Tu Éxito. Somos Artesanos del Software.

0 Comentarios

Dejar una respuesta

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

*