He practicado y asesorado en DevOps como consultor con diferentes clientes durante casi cinco años, antes de ocupar mi puesto actual, desempeñaba funciones en desarrollo de software, operaciones web y administración de sistemas. En mi experiencia personal , DevOps viene en muchos sabores.
Patrones de organización
Antipatrones DevOps:
NoOps y NoDevs : no estrictamente DevOps en el sentido más estricto, sin embargo, estos equipos construyen y operan software sin una línea divisoria entre Desarrollo y Operaciones. Los desafíos con estos equipos se reducen a la madurez, los equipos de desarrollo pueden ser desarrolladores de software expertos pero operadores novatos y viceversa.
El puente DevOps : aquí es donde uno o más equipos tienen la responsabilidad de tomar el trabajo de los equipos de desarrollo y " Producirlo " para hacerlo operativo. El desafío se reduce a que ahora hay dos transferencias, es decir, Desarrollo → DevOps y DevOps → Operaciones.
El equipo de DevOps : podría decirse que esto puede funcionar si el equipo tiene la responsabilidad de crear herramientas que admitan el modelo operativo habilitado para DevOps; sin embargo, probablemente debería llamarse "Equipo de herramientas" o "Equipo de plataforma".
Patrones de DevOps:
DevOps integrado : más comúnmente conocido como Ingeniería de plataforma, por lo que hay alguien dentro del equipo que es responsable pero no responsable de entregar automatización, herramientas e infraestructura para el aprovisionamiento y la implementación de la solución, a veces también incluyendo el funcionamiento del software, en mi opinión. , este último es realmente representativo de DevOps.
DevOps institucionalizado : donde un equipo de proyecto es responsable conjuntamente del desarrollo y la operación de un paquete de software que crea propiedad compartida y circuitos de retroalimentación positiva.
Practicas
La práctica real de DevOps se basa en varias otras prácticas, a saber:
Cada una de las prácticas anteriores se basa en la otra, es posible no seguir una práctica, sin embargo, significa que falta un ciclo de retroalimentación importante que puede ser indicativo de una "oportunidad perdida". El diferenciador clave entre seguir cualquiera de las otras prácticas y DevOps es la operación del software en producción .
Las tres formas
En The Phoenix Project, Gene Kim y sus coautores describen las tres formas de DevOps :
Pensamiento sistémico
The First Way enfatiza el desempeño de todo el sistema, en oposición al desempeño de un silo específico de trabajo o departamento; esto puede ser una división tan grande (p. Ej., Desarrollo u Operaciones de TI) o tan pequeña como un contribuyente individual (p. Ej. , desarrollador, administrador del sistema).
En mi experiencia, comenzar a lograr que los Desarrolladores consideren las preocupaciones operativas y los requisitos no funcionales logra este objetivo. Esto forma parte de los aspectos culturales de DevOps.
Amplificación de bucles de retroalimentación
La segunda forma consiste en crear bucles de retroalimentación de derecha a izquierda. El objetivo de casi cualquier iniciativa de mejora de procesos es acortar y amplificar los circuitos de retroalimentación para que las correcciones necesarias puedan realizarse continuamente.
En general, esto lo logro a través de la Integración / Entrega / Implementación Continua y el monitoreo y alertas compartidos, por lo que encaja perfectamente con el componente de herramientas de DevOps.
Cultura de experimentación continua y aprendizaje
La tercera vía consiste en crear una cultura que fomente dos cosas: experimentación continua, asumir riesgos y aprender del fracaso; y comprender que la repetición y la práctica son el requisito previo para el dominio.
Esto encaja mucho en el espacio cultural , aunque depende en gran medida de las herramientas y el proceso para permitir que la cultura crezca.
