IMO DevOps es cultura, al igual que Agile (sin elegir una metodología ágil). Por lo tanto, no "hace" DevOps.
Usted "hace" una metodología de lanzamiento llamada Entrega continua como parte de una Cultura DevOps. (divulgación completa, no creo que me haya referido al CD como una metodología de lanzamiento antes, pero en mi estado de jetlagged creo que funciona)
Si va a comprar eso, esta es la definición de Entrega continua de una de las personas que escribió el libro con el mismo título, Jez Humble .
La entrega continua es la capacidad de obtener cambios de todo tipo, incluidas nuevas características, cambios de configuración, correcciones de errores y experimentos, en producción o en manos de los usuarios, de forma segura y rápida de manera sostenible.
Nuestro objetivo es hacer implementaciones, ya sea de un sistema distribuido a gran escala, un entorno de producción complejo, un sistema integrado o una aplicación, asuntos predecibles y rutinarios que se pueden realizar a pedido.
Logramos todo esto asegurando que nuestro código esté siempre en un estado desplegable, incluso frente a los equipos de miles de desarrolladores que realizan cambios a diario. De este modo, eliminamos por completo las fases de integración, prueba y endurecimiento que tradicionalmente seguían a "dev complete", así como las congelaciones de código.
Entonces, puede trabajar en una metodología ágil, con un software que pueda demostrar al negocio, asegurándose de que esté realizando las pruebas automatizadas adecuadas, reaccionando bien el cambio y todas las cosas que lo hacen mejor que la cascada. Con demasiada frecuencia, eso no significa que realmente pueda implementarlo en producción.
Terminas con algo como esto:
Entonces, el software (probablemente) será mejor cuando haya terminado, si no tenía algún tipo de enfoque iterativo, pero realmente no lo sabe porque los usuarios reales nunca lo han visto.
Lo que realmente quieres es algo que se parezca más a esto:
Cada iteración, algo se implementa en producción. Entonces, el software está implementado . Si decide crear descargas, abrir el servidor web, o como se obtiene de software en manos de usuarios que ha lanzado .
¿¡Que demonios!? ¡Pregunté por DevOps! ¡Nadie preguntó sobre la entrega continua!
Entonces, ¿qué tiene que ver DevOps con esto?
Es muy, muy difícil (casi imposible) tener realmente su software en un estado en el que pueda implementarlo cuando lo desee a menos que ese equipo esté trabajando en una cultura DevOps. Una cultura en la que los administradores del sistema, DBA, SRE, personas de seguridad, desarrolladores, QA, etc., etc., son parte de un solo equipo y no forman parte de una organización con traspasos.
Nota :
Sobre parte de un comentario publicado en esta respuesta, que era así:
Acerca de su "... software en un estado en el que podría implementarlo cuando lo desee ...": eso me recuerda sobre el software "piloto automático" (en un avión) ... Mi pregunta favorita al respecto: " Imagine una actualización se aplica a dicho software ... ¿Cómo te sentirías al hacerlo durante el vuelo ... mientras estás a bordo? ".
¡Me encanta esa pregunta (en negrita, en la cita anterior)! La idea de "¿está realmente lista?" es algo que despotrica todo el tiempo: blog . En mi opinión, es vital que confíes en la seguridad, el rendimiento y otras pruebas "secundarias" con demasiada frecuencia para practicar CD. Las funciones se realizan cuando están listas, pero los hackers siempre están ahí.
No estoy seguro si no hay otros, pero estos son los criterios que uso:
Y si realmente desea experimentar la diferencia usted mismo como usuario de algún software, piense en usar algún software (como una distribución de Linux), donde puede elegir entre usar cualquiera de esas versiones:
un "
Rolling
" lanzamiento (==> ágil).un "
Long Term Support
" lanzamiento (==> Cascada).fuente