¿Cómo implementar el paso manual al final de la entrega continua?

13

La respuesta aceptada a mi pregunta sobre " ¿Cómo se relaciona la integración continua con la entrega / implementación continua? " También explica la pequeña diferencia entre la entrega continua y la implementación continua . Parece estar relacionado con la respuesta a una pregunta como "¿Cómo desea implementar en la producción, mientras que estas son las opciones (exclusivas) para elegir:

Automático).
Manual.

No puedo imaginar que habrá un pobre "operador" al otro lado del muro de DevOps, que tendrá que hacer algo que corresponda a lo que sea que ese "manual" signifique ... Mis preguntas:

¿Mi referencia (en mi pregunta) a "distribuir" versus "instalar" está cerca de una posible implementación de tal "manual"? Aquí hay una cita relevante de mi pregunta relacionada:

distribuir a algún entorno de destino, utilizando algo como FTP (si las copias estándar no pueden cerrar la brecha), pero aún no lo active en el destino. ¿Eso es lo que debería ser similar / cercano a la entrega continua , o no?

instalar (o activar ) en algún entorno de destino, combinado con cosas como enlaces, operaciones de detención / inicio, etc. ¿Eso es lo que debería ser similar / cercano a la implementación continua , o no?

¿Cuáles son otras posibles implementaciones de la misma?

continuous-delivery continuous-deployment

— Pierre.Vriens
fuente

Para las implementaciones de AWS, creé un script de carga / implementación al que solo el administrador del equipo tiene acceso. Entonces, para implementarlo en producción, el administrador del equipo debe ejecutar el script.

— Turtle

Lamento romper sus sueños, pero todavía tenemos un equipo de "implementación", que Oek lanzará actualizaciones de DB en Db2-iSeries con ARCAD y luego chef en los servidores Tomcart para implementar versiones en producción cada 2 jueves entre las 8 p.m. y la medianoche. Entonces, lamentablemente, a veces hay un operador pobre (es de esperar que ese no sea su único trabajo)

— Tensibai

5

Personalmente, considero que el distributionsoftware para un objetivo es solo un paso intermedio de una implementación: la instalación / activación de ese software es necesaria para completar esa implementación.

Para mí, delivery(como en continuos delivery) se detiene cuando se crea el software que se va a implementar y está disponible para su implementación (es decir, para distribución, instalación y activación)

Entonces, para responder a su primera pregunta, no, no consideraría la distribución e instalación como un reflejo del paso manual que diferencia la entrega continua de la implementación continua.

Sí, en algunos casos (con suerte raros) ese paso manual es solo la decisión humana final para desplegarse en la producción, lo que refleja la desconfianza cultural en la automatización de procesos y la comodidad mental de tener una doble verificación humana y cerrar la decisión de implementación (asumiendo así responsabilidad por ello) incluso si esa decisión se toma únicamente en base a un algoritmo que puede automatizarse (como contar los resultados de las pruebas de aprobación / reprobación).

Pero, en general, simplemente refleja el hecho de que la decisión de realizar el despliegue en producción no es simplemente el resultado de un algoritmo automatizado. Aquí sería un ejemplo de tales casos:

la decisión automatizada se sobrescribe
- la implementación se puede cerrar incluso si no se cumplen todos los criterios de calidad (todos sabemos que este no es solo un caso teórico)
- el despliegue se lleva a cabo por cualquier motivo, incluso si se cumplen todos los criterios (debido a implicaciones de tiempo de mercado, por ejemplo)
el algoritmo automatizado no está (todavía) implementado / implementado
el algoritmo incluye verificaciones de algunos criterios dependiendo de las decisiones humanas (por ejemplo, resultados de pruebas manuales)
la implementación se realiza en un entorno de cliente de terceros, luego de verificaciones adicionales del cliente

Por lo tanto, no consideraría el paso manual simplemente como un problema de implementación.

— Dan Cornilescu
fuente

Merci (oeps: gracias) por compartir sus puntos de vista sobre esto. Parece que tenemos una percepción diferente de la "distribución". Así que permítanme agregar 1 escenario: tiene una ventana de 1 hora, para un sistema bancario en línea, un domingo temprano en la mañana, para "activar" 150,000 ejecutables actualizados. Y si por alguna razón se necesitara una reversión, entonces no es posible negociar para extender esa ventana. ¿Realmente querría perder su tiempo en "distribuir", en lugar de utilizar el tiempo necesario para "por si acaso se necesita la reversión? Piense dos veces: si tarda más de 1 hora ... está despedido ... Bueno ???

— Pierre.Vriens

Eso es en mi humilde opinión solo un detalle de optimización o implementación de la implementación en sí, aplicable en su caso, (pero eso no lo convierte en una regla). El hecho de que esté ejecutando parte de su implementación antes de cerrar realmente la ejecución anterior de sw no significa que el trabajo respectivo sea parte de la etapa de entrega. Tampoco significa necesariamente que una vez que comience la implementación, también necesite completarla. El sw se entrega de manera efectiva (es decir, disponible / listo para la implementación) incluso si realmente no se implementa.

— Dan Cornilescu

2

Una consideración adicional si está publicando algo que espera que otros proyectos consuman, la implementación también adquiere el significado de "publicar para que otros lo usen"

Considere un flujo de trabajo donde implemente una biblioteca en un repositorio de artefactos común. Esta parte del proceso podría ser parte de la implementación de otro componente que requiere ese artefacto en el momento de la compilación o podría ser simplemente una actualización de una biblioteca común. Pero independientemente, para ese artefacto, su ciclo de vida no necesariamente termina al estar disponible para el consumo de otros, pero el despliegue de ese artefacto en el repositorio de artefactos puede ser la etapa final en el trabajo de los desarrolladores después de que hayan decidido cortar un nueva versión de lanzamiento y antes de que otros puedan consumir con seguridad la nueva versión.

— hvindin
fuente