Hmm, no usamos estos términos precisos, pero creo que tenemos un flujo de trabajo que implica la puesta en escena y la implementación real en varios de nuestros flujos de trabajo.
Por ejemplo, implementamos una serie de aplicaciones a través de paquetes RPM en servidores centos, porque esto nos permite implementar fácilmente algunos servicios simples en muchos servidores.
Cuando construimos un nuevo paquete, o actualizamos un paquete, usamos un servidor de prueba para verificar, si todo funciona correctamente, si el paquete extrae las dependencias correctas y si el paquete hace algo tonto. En el pasado han ocurrido paquetes que hacen cosas tontas, es por eso que la VM tiene un litte 2 en lugar de un 1 al final de su nombre ahora, y esa es la razón por la que existe este servidor provisional. 🙂
- ¿Cuáles son algunos scripts de bash personalizados que utiliza para acelerar el desarrollo web?
- Cómo implementar una aplicación web en una VPC de AWS
- Como desarrollador web, ¿debería crear primero una estructura alámbrica o simplemente construir? ¿Cuáles son tus pensamientos?
- ¿Cómo se implementa el cliente web de Quip?
- ¿Cuál es el mejor editor de texto HTML 2016?
Una vez que todo el paquete funciona correctamente, podemos marcar el paquete como estable e implementarlo en servidores completos.
Nuestras aplicaciones en vivo funcionan de manera similar. Primero los colocamos en servidores de prueba para ver si sucede algo horrible, luego los implementamos en algunos servidores de bajo valor para ver si ocurren cosas malas y finalmente lo implementamos en todas partes.
El objetivo de todos estos procesos de preparación es reducir el riesgo. La actualización podría destruir su base de datos de producción de alguna manera, su implementación podría arruinarse y extender el tiempo de inactividad de su aplicación, podría haberse perdido errores funcionales críticos. Organizar la aplicación en un entorno de bajo valor primero aísla el impacto de un error y, por lo tanto, reduce el riesgo de toda la implementación.
