En la implementación de software , un entorno o nivel es un sistema informático en el que se implementa y ejecuta un programa informático o componente de software . En un caso simple, tal despliegue y ejecución inmediata del programa en la misma máquina se puede realizar en un solo entorno , sin embargo, en el desarrollo industrial, se utiliza una separación entre el entorno de desarrollo (entorno del desarrollador), donde se realizan los cambios iniciales y el entorno de producción (que utilizan los usuarios finales); a menudo con etapas intermedias (etapas) en el medio. Este proceso estructurado de administración de versiones puede tener fases de implementación (lanzamiento, 'implementación', 'lanzamiento'), prueba (prueba) y reversión (retroceso) en caso de problemas.
Los entornos pueden variar mucho en tamaño: un entorno de desarrollo suele ser la estación de trabajo de un desarrollador individual , mientras que un entorno de producción puede ser una red de muchas máquinas dispersas geográficamente en el caso de los centros de datos o máquinas virtuales en el caso de las soluciones en la nube . El código, los datos y la configuración se pueden implementar en paralelo y no es necesario vincularlos al nivel adecuado; por ejemplo, el código de preproducción se puede conectar a la base de datos de producción .
Las arquitecturas de implementación varían mucho, pero en general, los niveles comienzan con el desarrollo (DEV) y terminan con la producción (PROD). Una arquitectura común de 4 niveles es una cascada de niveles de desarrollo, prueba, modelo y producción (DEV, TEST, MODL, PROD) con implementación de software en cada nivel por turno. Otro entorno común es el control de calidad (QC), para pruebas de aceptación ; sandbox o ambiente experimental (EXP), para experimentos que no están destinados a ser transferidos a producción; y Disaster Recovery ("recuperación de desastres"), para permitir la reversión inmediata en caso de un problema de producción. Otra arquitectura común es el desarrollo, prueba, aceptación y producción (DTAP).
Tal desglose es particularmente adecuado para programas de servidor cuando los servidores operan en centros de datos remotos; para el código que se ejecuta en los dispositivos finales del usuario, como aplicaciones (apps) o clientes, el último nivel se denomina entorno de usuario (USUARIO) o entorno local (LOCAL).
Las definiciones exactas y los límites entre entornos varían: la prueba puede considerarse parte del desarrollo, la aceptación puede considerarse parte de la prueba, parte del escenario o independiente, etc. Los niveles principales se procesan en un orden específico, con nuevas versiones que se implementan ( implementan o impulsan ) en cada uno. Los niveles experimental y de recuperación, si están presentes, son externos a este proceso: las versiones experimentales son puntos finales, mientras que la recuperación suele ser versiones antiguas o duplicadas de producción implementadas después de la producción. En caso de problemas, en el último caso, puede volver a la versión anterior y, en la mayoría de los casos, implementar la versión anterior de la misma manera que la nueva. El último paso, la implementación en producción ("empujar para producir") es el más sensible, ya que cualquier problema aquí afecta directamente al usuario. Por esta razón, a menudo se gestiona de manera diferente, pero al menos se supervisa con más cuidado, y en algunos casos hay una fase de reversión o cambio simple. Es mejor evitar un nombre como Quality Assurance (QA); QA no significa prueba de software. La prueba es importante, pero es diferente del control de calidad.
A veces, se realiza una implementación fuera del proceso normal, principalmente para proporcionar cambios pequeños o urgentes sin necesidad de una versión completa. Puede ser un solo parche , un paquete de servicio grande o una revisión pequeña .
Los entornos pueden ser de tamaños muy diferentes: el desarrollo generalmente se lleva a cabo en máquinas de desarrolladores individuales (aunque pueden ser miles de desarrolladores), mientras que la producción puede ser de miles de máquinas dispersas geográficamente; las pruebas y el control de calidad pueden ser pequeños o grandes según los recursos proporcionados, y la puesta en escena puede variar desde una sola máquina (como un canario) hasta duplicados exactos de producción.
Local
Computadora de desarrollo
Desarrollo/Troncal
Servidor de desarrollo que actúa como una caja de arena donde el desarrollador puede realizar pruebas unitarias
integración
Marco para construir CI o para probar efectos secundarios por parte de un desarrollador
Prueba/Prueba/Control de calidad/Aceptación interna
El entorno en el que se prueba la interfaz. El equipo de control de calidad verifica que el nuevo código no tenga un impacto en la funcionalidad existente del sistema después de implementar el nuevo código en el entorno de prueba.
Puesta en escena/Escenario/Modelo/Preproducción/Aceptación de cliente externo/Demostración
Espejo del entorno de producción.
Producción/En Vivo
Usuario final/servidores de clientes
El entorno del desarrollador (dev) es el entorno en el que se desarrolla el software, a menudo solo la computadora del desarrollador. Esto difiere del entorno objetivo final en algunos aspectos: es posible que el objetivo no sea una computadora de escritorio (podría ser un teléfono inteligente, un sistema integrado, un vehículo de centro de datos autónomo, etc.), e incluso si es una computadora de escritorio , el entorno de desarrollo incluirá herramientas de desarrollo, por ejemplo, compilador, IDE, versiones diferentes o adicionales de bibliotecas y software de soporte, etc. que no están presentes en el entorno de usuario.
En el contexto de la gestión de revisiones, especialmente cuando hay varios desarrolladores involucrados, existen distinciones más sutiles: el desarrollador tiene una copia de trabajo del código fuente en su máquina y los cambios se realizan en el repositorio al confirmarse en el "tronco" o en sucursal, dependiendo de la metodología de desarrollo. Un entorno en una estación de trabajo independiente en la que se resuelven y prueban los cambios puede denominarse entorno local o sandbox . Construir una copia del código fuente del repositorio en un entorno limpio es un paso de integración separado (integrar cambios dispares), y este entorno puede denominarse entorno de integración o entorno de desarrollador ; en integración continua , esto se hace con frecuencia, con la misma frecuencia que para cada revisión. El concepto de nivel de código fuente, que suena como “commiting (commiting) cambios en el repositorio” con el posterior ensamblaje del “tronco” o rama, corresponde a la transición de local (entorno de desarrollador individual) a integración (ensamblaje puro) ; una versión incorrecta en este punto significa que el cambio rompió la compilación, y revertir la versión significa revertir todos los cambios realizados o revertir solo el cambio de última hora, si es posible.
El propósito de un entorno de prueba es permitir que los probadores ejecuten código nuevo y modificado a través de controles automáticos o métodos manuales. Después de que un desarrollador pasa el nuevo código y las configuraciones a través de pruebas unitarias en el entorno de desarrollo, el código se migra a uno o más entornos de prueba. Después de que falla una prueba, el marco de prueba puede eliminar el código erróneo de los marcos de prueba, ponerse en contacto con el desarrollador responsable y proporcionar registros y resultados de prueba detallados. Si todas las pruebas pasan, el entorno de prueba o el marco de integración continua que controla las pruebas puede migrar automáticamente el código al siguiente entorno de implementación.
Los diferentes tipos de pruebas involucran diferentes tipos de entornos de prueba, algunos o todos los cuales pueden virtualizarse para proporcionar pruebas paralelas rápidas. Por ejemplo, las pruebas de interfaz de usuario automatizadas pueden ejecutarse en múltiples sistemas operativos virtuales y pantallas (reales o virtuales). Las pruebas comparativas pueden requerir una configuración de hardware de referencia normalizada para que los resultados de las comparativas se puedan comparar a lo largo del tiempo. Las pruebas de disponibilidad o resiliencia se pueden basar en simuladores de fallas en hardware virtual y redes virtuales.
Las pruebas pueden ser secuenciales (una tras otra) o paralelas (para algunas o todas a la vez), según la complejidad del entorno de prueba. Un objetivo importante de las prácticas ágiles y otras prácticas de desarrollo de software de alto rendimiento es reducir el tiempo desde el desarrollo o la entrega del software hasta su entrega a la producción. Los entornos de prueba altamente automatizados y paralelizados hacen una importante contribución al rápido desarrollo de software.
Stage o entorno de ensayo (staging) es un entorno de prueba que es exactamente como un entorno de producción. Su objetivo es reflejar el entorno de producción real lo más fielmente posible y puede conectarse a otros servicios y datos de producción, como bases de datos. Por ejemplo, los servidores se ejecutarán en máquinas remotas en lugar de localmente (como en la estación de trabajo de un desarrollador durante el desarrollo o en una sola máquina de prueba durante la prueba) para probar el impacto de la red en el sistema.
El objetivo principal de un entorno de prueba es probar todos los procedimientos y secuencias de comandos de instalación/configuración/movimiento antes de que se apliquen al entorno de producción. Esto garantiza que todas las actualizaciones mayores y menores del entorno de producción se completarán con alta calidad, sin errores y en el menor tiempo posible.
Otro uso importante del entorno de prueba es la prueba de rendimiento, en particular, la prueba de carga, ya que a menudo es sensible al entorno.
Algunas organizaciones también utilizan el entorno de prueba para obtener una vista previa de las nuevas funciones para la selección del cliente o para validar integraciones con versiones en ejecución de dependencias externas.
El entorno de producción también se conoce como en vivo (particularmente cuando se aplica a servidores) porque es el entorno con el que los usuarios interactúan directamente.
La implementación en producción es el paso más delicado; esto se puede hacer implementando el código nuevo directamente (sobrescribiendo el código anterior para que solo haya una copia presente a la vez) o implementando un cambio de configuración. Esto puede tomar varias formas: implementación paralela de una nueva versión del código y cambiar a ella con un cambio de configuración; implementar una nueva versión del código junto a la anterior con el correspondiente "indicador de nueva funcionalidad", y luego cambiar a la nueva versión con un cambio de configuración que cambiará este "indicador"; o implementando servidores separados (uno que ejecuta el código antiguo y el otro el nuevo) con el tráfico redirigido del antiguo al nuevo, con un cambio de configuración en el nivel de enrutamiento del tráfico. Todo esto, a su vez, puede aplicarse de manera simultánea o selectiva, y en diferentes etapas.
La implementación de una nueva versión generalmente requiere un reinicio, a menos que sea posible el cambio en caliente y, por lo tanto, requiere la interrupción del servicio (generalmente software personalizado cuando las aplicaciones necesitan recargarse) o la duplicación: reinicio gradual de instancias "detrás" del balanceador de carga, o inicio anticipado nuevos servidores, seguido de una simple redirección del tráfico a nuevos servidores.
Al implementar una nueva versión en producción, en lugar de implementarla inmediatamente en todas las instancias o usuarios, primero puede implementarla en una instancia o en algunos usuarios y luego implementarla en todas las instancias o en fases para detectar rápidamente los problemas que surjan. . Es similar a la puesta en escena, excepto que se realiza durante la producción y se denomina liberación canaria similar a la minería del carbón . Esto agrega complejidad si se lanzan varias versiones al mismo tiempo, por lo que generalmente se realizan rápidamente para evitar problemas de compatibilidad.
El desarrollo, la puesta en escena y la producción son variables de entorno conocidas y documentadas en ASP.NET Core . Dependiendo de la variable especificada, se ejecuta un código diferente y se aplica una representación de contenido diferente, configuraciones de seguridad y depuración diferentes.