¿Cómo puedo automatizar las implementaciones de producción sin experimentar ansiedad extrema?

En nuestra tienda utilizamos SVN para el control de fuente y CruiseControl para CI en el manejo de compilaciones e implementaciones automáticas en nuestros entornos de desarrollo, prueba e integración.

Todo esto funciona sin problemas, sin embargo, debido a las limitaciones de hardware y recursos, nuestro entorno de integración no es un entorno de carga equilibrada de 2 servidores como nuestro entorno de producción. Si bien todo lo demás es igual, esa sería la única diferencia entre nuestros entornos de integración y producción (¡aunque grande!)

Teóricamente, la diferencia es una configuración ligeramente diferente de nuestros servidores de aplicaciones y el script de implementación simplemente tendría que colocar los artefactos de compilación en dos servidores en lugar de solo uno, pero ¿por qué estoy tan nervioso por automatizar nuestras implementaciones de producción?

Generalmente no soy un fanático del control, pero siempre siento la necesidad insaciable de implementar la producción en producción manualmente. He escuchado de colegas que esto generalmente es una Cosa Realmente MALA, pero no pudieron presentar un caso en su contra.

Sé que cuando lo hago manualmente puedo VER que estoy copiando físicamente los archivos correctos, estoy cerrando físicamente los servidores de aplicaciones y asegurándome de que se cierren correctamente, estoy iniciando físicamente los servidores nuevamente y luego inspeccionando físicamente los registros para hacer asegúrese de que comenzó bien y que la implementación fue exitosa. Me da tranquilidad.

¿Cuáles son los argumentos en contra de esto O argumentos para la implementación automática de producción con script?

Hay algunos argumentos obvios en contra de esto.

1. ¿Qué pasa si te vas? ¿Está toda esta información documentada cuidadosamente o está principalmente en su cabeza? Las secuencias de comandos automatizadas son un lugar mucho mejor para que otra persona tome el control.

2. Todos cometemos errores. Llegará un momento en que la persona que realice el despliegue esté cansada, sin prestar atención a lo que sea. Sí, lo ideal es que las implementaciones solo se realicen en un lugar tranquilo y feliz con mucho tiempo. En la práctica, pueden ser apresurados y estresados ​​cuando intentan implementar soluciones urgentes. Este es el momento más probable para cometer un error, y también el más costoso. Si la implementación es una secuencia de comandos única, el potencial de errores es limitado.

3. Hora. A medida que las implementaciones se vuelven más complicadas, la cantidad que se necesita hacer aumenta. Las secuencias de comandos solo requieren comenzar, una verificación manual y luego un cambio manual (también podría automatizar esto, pero comparto algo de la paranoia :).

Puede obtener lo mejor de los mejores mundos: tranquilidad con la verificación de procesos y la fiabilidad de la automatización.

Script de la implementación. Luego, revise y verifique manualmente que se inician los procesos, que se eliminan los archivos, etc. En otras palabras, escriba su propio script de control de calidad solo para verificar que los pasos automatizados 1 - X realmente ocurrieron.

Creo que la clave aquí es: ¿por qué crees que no puedes escribir el proceso de verificación?

Mis scripts de implementación no solo empujan archivos y reinician servicios. Imprimen mucha información codificada por colores durante cada paso de la implementación y me proporcionan un resumen de los eventos al final. Me permite saber que los procesos están en funcionamiento, que la página de inicio ofrece un código de estado 200 y que todas las máquinas y servicios pueden verse bien. Luego tengo un servicio separado que no es parte del script que monitorea los archivos de registro, los errores de nivel 4xx y 5xx, y las métricas clave del sitio. Luego procede a gritarme a través de todos los medios posibles (correo electrónico, mensaje de texto y alarmas) si hay picos drásticos de efectos negativos.

Entre eso y los servidores de CI que ejecutan pruebas, literalmente implemento y olvido en este nivel de automatización. Ni siquiera busco una sola página en el sitio después de un empuje debido a lo confiable que es el proceso ahora, lo que no solo me permite implementar tantas veces como lo desee, sino que permite que un nuevo desarrollador del proyecto realice una actualización en vivo sitio a los pocos minutos de llegar a bordo. En el pasado, incluso hice que los servidores CI se implementaran automáticamente en producción después de un compromiso con una rama maestra / troncal que pasa todo. Así de seguro estoy en mis herramientas.

Tú también deberías serlo.

¿También ejecuta sus máquinas de producción con depuración remota y las atraviesa manualmente? Construir un script adecuado es idéntico a escribir un programa. Todos los problemas que tiene indican cosas que deberá observar y comparar.

Si algo sale mal, debe pasar por los procedimientos de reversión adecuados y enviarle un mensaje. Todo lo que sucede puede registrarse para más adelante. Puede controlar la versión de los scripts y configurar casos de prueba.

Pero si está ejecutando comandos manualmente, no tiene ninguna de estas ventajas. En cambio, tienes una lista de desventajas.

• No tienes un buen registro, el historial de shell no cuenta
• Nadie más sabe cómo hacerlo
• Pasos que se pierden
• Los cheques solo a veces se hacen
• Se pueden perder algunos elementos para implementar, ya lo he hecho antes
• Toma mucho más tiempo
• Puedes ser interrumpido durante el proceso

Una secuencia de comandos adecuada debe ser casi idéntica a si escribiste todo en el shell. Esta es una de las razones por las que tenemos scripts bash. Si confías en las cosas que haces, ¿por qué no puedes grabar todo y ajustarlo? Una mejor comprobación, una comprobación más rápida, una mayor comprobación puede ocurrir porque la computadora lo hace.

Puedo entender estar un poco nervioso probando algo nuevo en el entorno de producción. Tener cuidado con los posibles desastres es una buena cosa ^TM .

Las secuencias de comandos automatizadas también son un Good Thing ^TM y, siempre que lo abordes con cuidado, deberías poder minimizar el peligro y reducir el miedo. Entonces mi consejo es este;

• Prepare (y practique en el entorno de integración) una lista de verificación / conjunto de pruebas para que pueda averiguar rápidamente si funcionó y si algo salió mal. El registro detallado puede ayudar con esto.
• Copia de seguridad de todo. Prepare y practique una reversión manual para que pueda recuperarse si sale mal.
• Pruebe todo lo que pueda antes de hacerlo de verdad en prod. Parece que eres una buena manera junto con esto con tu entorno de integración.
• La primera vez que lo intente, hágalo con un cambio de bajo perfil y bajo impacto. Algo así como una actualización o parche menor. La idea es minimizar las consecuencias si sale mal. No elija una actualización importante de alto perfil (donde el CEO y todos sus competidores están mirando) para su primera carrera.

Una vez que tenga algunas carreras exitosas en su haber, su confianza crecerá y pronto se preguntará cómo logró hacer implementaciones manuales.

Este es el argumento más importante contra las implementaciones manuales en producción: eres un ser humano y cometerás errores. Sin duda, habrá momentos en los que te olvides de hacer algo que te causará dolor. Una implementación automatizada bien escrita no tiene esa misma tendencia. Es cierto que aún puede tener implementaciones de producción en mal estado, pero eso se debe a que su implementación automática tiene errores que deben resolverse.

En mi experiencia, los beneficios de las implementaciones automatizadas para la producción son enormes. La más importante es que te diviertes los fines de semana en lugar de tratar de avanzar a través de un proceso de implementación manual que no cooperará.

Dicho esto, aquí hay algunos indicadores clave para automatizar sus implementaciones de producción:

• ¡No lo hagas todo de una vez! Comience a escribir lentamente sus implementaciones automatizadas. Configure primero un entorno de no producción separado e intente automatizar las implementaciones allí. Una vez que haya acumulado confianza en sus implementaciones automatizadas, puede comenzar a pensar en hacer implementaciones de producción
• ¡Comience a lanzar y desplegar con mucha frecuencia! Es mucho más fácil realizar implementaciones automatizadas cuando no tiene 4 meses de código esperando para ser lanzado. Libere pequeñas funciones y correcciones de errores varias veces por semana. ¡Los beneficios de este estilo de lanzamiento no pueden ser subestimados!
• Confíe en las pruebas automatizadas para tener la confianza de que su entorno de producción funcionará. Nuevamente, esto lleva tiempo para acumularse, pero es muy importante. Las pruebas automatizadas siempre son mejores que las pruebas de aceptación manual. Claro, las pruebas de aceptación manual están bien, pero las pruebas automatizadas pueden ayudarlo a saber si debe implementarlo en producción o no. Son la clave que permite todo este proceso de entrega automática y continua. Si sus pruebas no pasan, sabe que no debe desplegarse en producción.

Ejecute los scripts en el servidor en vivo. Funcionará, y después de haberlo visto funcionar bien varias veces, estará perfectamente seguro de ello.

Sin embargo, es más probable que cometas errores que el script de implementación.

Las computadoras no cometen errores, la gente sí.

Escriba su guión una vez y verifíquelo minuciosamente, revíselo línea por línea. A partir de entonces, puede estar seguro de que cada vez que implemente, funcionará.

Hazlo a mano y seguramente cometerás errores. Tal vez escribiste, todo lo que tienes que hacer, abajo, pero es tan fácil cometer un error. ¿Tiene que copiar todos los archivos excepto el archivo web.config? Puede apostar que algún día lo sobrescribirá. Un guión nunca cometerá este error.

¿Cómo puedo automatizar las implementaciones de producción sin experimentar ansiedad extrema?

La ansiedad extrema que experimentaría al automatizar las implementaciones de producción se basa, muy probablemente, en dos creencias:

1. Un día u otro, algún paso de implementación fallará y usted u otro ser humano podrán recuperarse rápidamente de la falla mientras que un script automatizado podría pasarla por alto.

2. Un fracaso pasado por alto en la producción tiene consecuencias dramáticas.

Hay poco que se pueda hacer alrededor de 2., además de evitar fallas, así que concentrémonos en 1.

Una solución económica que mejore ligeramente la existente sería utilizar un procedimiento de implementación semiautomático, esperando la validación al final de cada paso de la instalación. Con una solución semiautomática, disfrutará de los beneficios de una solución totalmente automática, como la consistencia y la reproducibilidad, mientras que todavía tendrá la oportunidad de monitorear los progresos y recuperarse de los errores como está acostumbrado.

La secuencia de comandos semiautomatizada y su biotopo (pruebas de regresión, etc.) también podrían servir como vehículo para el conocimiento que está recopilando sobre las fallas que ocurren en el procedimiento de instalación y las formas de recuperarse de ellas.

Lo que me gusta es que puede probar el despliegue en etapas o QA y saber que cuando lo ejecute en prod, se realizarán exactamente los mismos pasos.

Cuando lo haces manualmente, es más fácil olvidar un paso o hacerlos fuera de servicio.

... debido a limitaciones de hardware y recursos, nuestro entorno de integración no es un entorno de carga equilibrada de 2 servidores como nuestro entorno de producción. Si bien todo lo demás es igual, esa sería la única diferencia entre nuestros entornos de integración y producción (¡aunque grande!)

Dado lo anterior, probablemente estaría tan ansioso como tú.

Una vez revisé y probé el script automatizado que se implementa en SLB y creo que sin la prueba previa en la configuración de carga equilibrada preferiría hacer las cosas manualmente.

Además de la configuración de prueba tipo prod, otra cosa que tuvo un impacto significativo en mi tranquilidad es que la implementación de prod fue realizada por otro equipo que los desarrolladores , por chicos cuyo único trabajo era mantener el entorno de producción.

• En uno de los proyectos, los estaba ayudando en la implementación como representante del equipo de desarrollo. Antes del despliegue, estaban revisando mis instrucciones y durante el despliegue estaba sentado en línea listo para consultar si las cosas salían mal. En aquel entonces, aprendí a apreciar esa separación .
   
  No es que fueran más rápidos (¿por qué lo harían? Probé implementaciones 5x-10x con más frecuencia que ellos). La gran diferencia estaba en foco. Quiero decir, mi cabeza siempre está cargada de cosas "principales" (codificación, depuración, nuevas características), hay demasiadas distracciones para concentrarse adecuadamente en la implementación. A diferencia de esto, su material principal era simplemente el mantenimiento y la producción que se han centrado en eso.
   
  Es sorprendente cuánto funciona mejor el cerebro cuando está enfocado. Estos muchachos, fueron mucho más atentos, cometieron muchos menos errores que yo. Simplemente sabían esas cosas mejor que yo. Incluso me enseñaron una o dos cosas que facilitaron mis propios despliegues de prueba.

Cree un script de implementación que use para mover su código a cualquier entorno. Usamos exactamente el mismo proceso de implementación para mover el código a dev, qa, puesta en escena y finalmente producción. Dado que estamos implementando varias veces al día para el desarrollo y diariamente para el control de calidad, hemos ganado la confianza de que los scripts de implementación son correctos. Básicamente, prueba el infierno al usarlo con frecuencia.

1. Simplificar. Su proceso de cambio debe ser archivos rsync, ejecutar script SQL, nada más.
2. Automatizar.
3. Prueba.

La razón para automatizar es obtener algo que sea comprobable, repetible y en el que pueda confiar para que funcione correctamente en cada situación esperada.

Todavía necesita tener un plan de retroceso, como para cualquier cambio en cualquier contexto, y también debe ser automatizado.

Todavía querrá observar el proceso tal como sucede si el entorno es realmente sensible, pero nunca lo haga manualmente, ya que simplemente no puede reproducirse.

Es completamente posible utilizar scripts de automatización para implementar en entornos de producción. Sin embargo, para hacerlo de manera confiable, debe ser capaz de hacer varias cosas.

1. Vuelva a la versión anterior de manera confiable.
2. Obtenga confirmación positiva de que la implementación se ha aplicado con éxito y está respondiendo al tráfico válido.
3. Tenga entornos comparables para el desarrollo y el control de calidad que también utilizan los mismos scripts.

Los scripts tienen algunas ventajas, ya que nunca perderán un comando porque son las 2 a.m. y están cansados.

Sin embargo, los scripts pueden fallar y seguirán fallando. A veces, la falla está en el diseño de la secuencia de comandos, pero también puede ser causada por una falla de red o de energía, un sistema de archivos corrupto, la falta de memoria .....

Es por eso que es importante que después de que se haya ejecutado el script, también se siga una fase de prueba definida que verifique que la nueva implementación esté activa, ejecutando y manejando las solicitudes, antes de habilitar el tráfico en vivo.

1. tomar una ventana más grande para la implementación la primera vez si las cosas salen mal

2. Divida el proceso de implementación en dos partes. a. Copia de seguridad (manual): esto debería darle confianza si algo sale mal durante la implementación

   si. Despliegue (automatizado)

una vez que pueda implementar con confianza por primera vez. También puede automatizar el proceso de copia de seguridad.