Entorno de despliegue

El entorno de desarrollo (dev) es el entorno en el que se desarrollan los cambios en el software, generalmente la estación de trabajo de un desarrollador individual. Este difiere del entorno de destino final en varios aspectos: el destino puede no ser una computadora de escritorio (puede ser un teléfono inteligente, un sistema embebido , una máquina sin interfaz gráfica en un centro de datos, etc.), e incluso si son similares en otros aspectos, el entorno del desarrollador incluirá herramientas de desarrollo como un compilador , un entorno de desarrollo integrado, versiones diferentes o adicionales de bibliotecas y software de soporte, etc., que no están presentes en el entorno del usuario.

En el contexto del control de versiones , especialmente con varios desarrolladores, se establecen distinciones más sutiles: un desarrollador tiene una copia de trabajo del código fuente en su máquina, y los cambios se envían al repositorio, confirmándose en la rama principal o en una rama secundaria, según la metodología de desarrollo. El entorno en una estación de trabajo individual, en el que se trabajan y prueban los cambios, puede denominarse entorno local o entorno de pruebas . La creación de la copia del código fuente del repositorio en un entorno limpio es un paso independiente, parte de la integración (integración de cambios dispares), y este entorno puede denominarse entorno de integración o entorno de desarrollo ; en la integración continua , esto se realiza con frecuencia, incluso para cada revisión. El concepto a nivel de código fuente de "confirmar un cambio en el repositorio", seguido de la creación de la rama principal o secundaria, corresponde a enviar la versión desde el entorno local (entorno del desarrollador individual) a la integración (compilación limpia); una versión defectuosa en este paso significa que un cambio rompió la compilación, y revertir la versión corresponde a revertir todos los cambios a partir de ese punto, o deshacer solo el cambio que rompió la compilación, si es posible.

El propósito del entorno de pruebas es permitir que los evaluadores humanos prueben el código nuevo y modificado mediante comprobaciones automatizadas o técnicas no automatizadas. Una vez que el desarrollador aprueba el código y las configuraciones nuevas mediante pruebas unitarias en el entorno de desarrollo, los elementos se trasladan a uno o más entornos de pruebas. ^{[ 3 ]} En caso de que una prueba falle, el entorno de pruebas puede eliminar el código defectuoso de las plataformas de prueba, contactar al desarrollador responsable y proporcionar registros detallados de las pruebas y los resultados. Si todas las pruebas se superan, el entorno de pruebas o un marco de integración continua que controle las pruebas puede promover automáticamente el código al siguiente entorno de despliegue.

Los distintos tipos de pruebas sugieren diferentes entornos de prueba, algunos o todos los cuales pueden virtualizarse ^{[ 4 ]} para permitir pruebas rápidas y paralelas. Por ejemplo, las pruebas automatizadas de interfaz de usuario ^{[ 5 ]} pueden realizarse en varios sistemas operativos y pantallas virtuales (reales o virtuales). Las pruebas de rendimiento pueden requerir una configuración de hardware física de referencia normalizada, de modo que los resultados de las pruebas de rendimiento puedan compararse a lo largo del tiempo. Las pruebas de disponibilidad o durabilidad pueden depender de simuladores de fallos en hardware y redes virtuales.

Las pruebas pueden ser secuenciales (una tras otra) o paralelas (algunas o todas a la vez), dependiendo de la complejidad del entorno de prueba. Un objetivo importante para las prácticas de desarrollo de software ágiles y de alta productividad es reducir el tiempo desde el diseño o la especificación del software hasta su entrega en producción. ^{[ 6 ]} Los entornos de prueba altamente automatizados y paralelizados contribuyen significativamente al desarrollo rápido de software.

Un entorno de preproducción o de pruebas es un entorno que reproduce fielmente un entorno de producción. ^{[ 7 ]} Su objetivo es replicar un entorno de producción real con la mayor precisión posible y puede conectarse a otros servicios y datos de producción, como bases de datos. Por ejemplo, los servidores se ejecutan en máquinas remotas, en lugar de localmente (como en la estación de trabajo de un desarrollador durante el desarrollo o en una única máquina de prueba durante las pruebas), lo que permite evaluar los efectos de la red en el sistema.

El uso principal de un entorno de pruebas es testear todos los scripts y procedimientos de instalación, configuración y migración antes de aplicarlos a un entorno de producción. Esto garantiza que todas las actualizaciones, tanto mayores como menores, del entorno de producción se completen de forma fiable, sin errores y en el menor tiempo posible.

Otro uso importante de la puesta en escena es la prueba de rendimiento , en particular la prueba de carga , ya que esta suele ser sensible al entorno.

Algunas organizaciones también utilizan entornos de prueba para mostrar nuevas funciones a clientes seleccionados o para validar integraciones con versiones en producción de dependencias externas.

El entorno de producción también se conoce como entorno en vivo , especialmente en el caso de los servidores, ya que es el entorno con el que los usuarios interactúan directamente.

El despliegue en producción es el paso más delicado; puede realizarse desplegando directamente el código nuevo (sobrescribiendo el código antiguo, de modo que solo exista una copia a la vez) o desplegando un cambio de configuración. Esto puede adoptar diversas formas: desplegar una instalación paralela de una nueva versión del código y alternar entre ellas mediante un cambio de configuración; desplegar una nueva versión del código con el comportamiento anterior y una bandera de características , y cambiar al nuevo comportamiento mediante un cambio de configuración que invierta dicha bandera; o desplegar servidores separados (uno ejecutando el código antiguo y otro el nuevo) y redirigiendo el tráfico del antiguo al nuevo mediante un cambio de configuración a nivel de enrutamiento de tráfico. Estos procesos, a su vez, pueden realizarse simultáneamente o gradualmente, por fases.

Por lo general, el despliegue de una nueva versión requiere un reinicio, a menos que sea posible el intercambio en caliente , lo que implica una interrupción del servicio (algo habitual en el software de usuario, donde las aplicaciones se reinician) o redundancia: ya sea reiniciando las instancias lentamente detrás de un equilibrador de carga o iniciando nuevos servidores con antelación y luego simplemente redirigiendo el tráfico a los nuevos servidores.

Al implementar una nueva versión en producción, en lugar de implementarla inmediatamente en todas las instancias o usuarios, puede implementarse primero en una sola instancia o en un grupo reducido de usuarios, y luego implementarse en todos o gradualmente por fases, para detectar cualquier problema de última hora. Esto es similar a la fase de pruebas, pero se realiza en producción y se conoce como lanzamiento canario , por analogía con la minería del carbón. Esto añade complejidad debido a que se ejecutan varias versiones simultáneamente, por lo que suele ser rápido para evitar problemas de compatibilidad.