En la implementación de software , un entorno o nivel es un sistema informático o un conjunto de sistemas en los que se implementa y ejecuta un programa informático o un componente de software . En casos sencillos, como el desarrollo y la ejecución inmediata de un programa en la misma máquina, puede haber un único entorno, pero en el uso industrial, el entorno de desarrollo (donde se realizan los cambios originalmente) y el entorno de producción (lo que utilizan los usuarios finales) están separados, a menudo con varias etapas intermedias. Este proceso de gestión de versiones estructurado permite la implementación (lanzamiento) en fases, las pruebas y la reversión en caso de problemas.
Los entornos pueden variar significativamente en tamaño: el entorno de desarrollo es, por lo general, la estación de trabajo de un desarrollador individual, mientras que el entorno de producción puede ser una red de muchas máquinas distribuidas geográficamente en centros de datos o máquinas virtuales en computación en la nube . El código, los datos y la configuración se pueden implementar en paralelo y no es necesario que se conecten al nivel correspondiente; por ejemplo, el código de preproducción podría conectarse a una base de datos de producción.
Las arquitecturas de implementación varían significativamente, pero, en líneas generales, los niveles se dividen en dos partes: primero en el desarrollo (DEV) y luego en la producción (PROD). Una arquitectura común de cuatro niveles es la de desarrollo, prueba, modelo y producción (DEV, TEST, MODL, PROD), y el software se implementa en cada una de ellas en orden. Otros entornos comunes incluyen el control de calidad (QC), para pruebas de aceptación ; el entorno de pruebas o experimental (EXP), para experimentos que no están destinados a pasar a producción; y la recuperación ante desastres, para proporcionar una alternativa inmediata en caso de problemas con la producción. Otra arquitectura común es la de desarrollo, prueba, aceptación y producción (DTAP).
Este lenguaje es particularmente adecuado para programas de servidor, donde los servidores se ejecutan en un centro de datos remoto; para el código que se ejecuta en el dispositivo de un usuario final, como aplicaciones (apps) o clientes, uno puede hacer referencia al entorno del usuario (USER) o al entorno local (LOCAL).
Las definiciones exactas y los límites entre los entornos varían: la prueba puede considerarse parte del desarrollo, la aceptación puede considerarse parte de la prueba, parte de la etapa o ser independiente, etc. Los niveles principales avanzan en orden, y las nuevas versiones se implementan ( se implementan o se envían ) en cada uno de ellos por turno. [1] [2] Los niveles experimental y de recuperación, si están presentes, están fuera de este flujo: las versiones experimentales son terminales, mientras que la recuperación suele ser una versión antigua o duplicada de producción, implementada después de la producción. En caso de problemas, se puede volver a la versión anterior, la mayoría de las veces simplemente enviando la versión anterior como si fuera una nueva versión. El último paso, la implementación en producción ("enviar a producción"), es el más delicado, ya que cualquier problema tiene un impacto inmediato en el usuario. Por este motivo, a menudo se maneja de forma diferente, al menos se controla con más cuidado y, en algunos casos, se implementa en fases o solo se requiere activar un interruptor, lo que permite una reversión rápida. Es mejor evitar un nombre como Garantía de calidad (QA); QA no significa prueba de software. Las pruebas son importantes, pero son diferentes del control de calidad.
A veces, la implementación se realiza fuera de este proceso habitual, principalmente para proporcionar cambios urgentes o relativamente menores, sin necesidad de una versión completa. Esto puede consistir en un solo parche , un gran paquete de servicios o una pequeña revisión .
Los entornos pueden ser de tamaños muy diferentes: el desarrollo es típicamente la estación de trabajo de un desarrollador individual (aunque puede haber miles de desarrolladores), mientras que la producción puede ser muchas máquinas distribuidas geográficamente; las pruebas y el control de calidad pueden ser pequeños o grandes, dependiendo de los recursos dedicados a estos, y la preparación puede variar desde una sola máquina (similar a Canary) hasta un duplicado exacto de la producción.
La siguiente tabla describe una lista finamente dividida de niveles [ cita requerida ] .
El entorno de desarrollo (dev) es el entorno en el que se desarrollan los cambios del software, más sencillamente la estación de trabajo de un desarrollador individual. Se diferencia 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 integrado, 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 de un usuario.
En el contexto del control de revisión , particularmente con múltiples desarrolladores, se hacen distinciones más finas: un desarrollador tiene una copia de trabajo del código fuente en su máquina, y los cambios se envían al repositorio, siendo confirmados ya sea en el tronco o en una rama, dependiendo de la metodología de desarrollo. El entorno en una estación de trabajo individual, en el que se trabaja y se prueban los cambios, puede denominarse entorno local o sandbox . Construir la copia del código fuente del repositorio en un entorno limpio es un paso separado, parte de la integración (integración de cambios dispares), y este entorno puede llamarse entorno de integración o entorno de desarrollo ; en la integración continua esto se hace con frecuencia, tan a menudo como para cada revisión. El concepto de nivel de código fuente de "confirmar un cambio en el repositorio", seguido de la construcción del tronco o la rama, corresponde a empujar a la liberación desde el entorno local (el entorno del desarrollador individual) a la integración (compilación limpia); una mala liberación en este paso significa que un cambio rompió la compilación, y revertir la liberación corresponde a revertir todos los cambios desde ese punto en adelante, o deshacer solo el cambio que rompió, si es posible.
El propósito del entorno de prueba 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 acepta el código nuevo y las configuraciones mediante pruebas unitarias en el entorno de desarrollo, los elementos se trasladan a uno o más entornos de prueba. [3] En caso de que la prueba falle, el entorno de prueba puede eliminar el código defectuoso de las plataformas de prueba, comunicarse con el desarrollador responsable y proporcionar registros detallados de las pruebas y los resultados. Si todas las pruebas pasan, el entorno de prueba o un marco de integración continua que controle las pruebas puede promover automáticamente el código al siguiente entorno de implementación.
Los distintos tipos de pruebas sugieren distintos tipos de entornos de prueba, algunos de los cuales o todos ellos pueden virtualizarse [4] para permitir que se realicen pruebas rápidas y paralelas. Por ejemplo, las pruebas de interfaz de usuario automatizadas [5] pueden realizarse en varios sistemas operativos y pantallas virtuales (reales o virtuales). Las pruebas de rendimiento pueden requerir una configuración de hardware de referencia física normalizada, de modo que los resultados de las pruebas de rendimiento se puedan comparar a lo largo del tiempo. Las pruebas de disponibilidad o durabilidad pueden depender de simuladores de fallas en hardware virtual y redes virtuales.
Las pruebas pueden ser en serie (una tras otra) o paralelas (algunas o todas a la vez) según la sofisticación del entorno de prueba. Un objetivo importante de las prácticas de desarrollo de software ágiles y otras prácticas de alta productividad es reducir el tiempo desde el diseño o la especificación del software hasta la entrega en producción. [6] Los entornos de prueba altamente automatizados y paralelizados son importantes contribuyentes al desarrollo rápido de software.
Un entorno de prueba, de ensayo o de preproducción es un entorno de prueba que se asemeja exactamente a un entorno de producción. [7] Busca reflejar un 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 hacerlo 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), lo que prueba los efectos de la red en el sistema.
El uso principal de un entorno de prueba es probar todos los scripts y procedimientos de instalación, configuración y migración antes de que se apliquen a un entorno de producción. Esto garantiza que todas las actualizaciones importantes y menores de un entorno de producción se completen de manera confiable, sin errores y en un tiempo mínimo.
Otro uso importante de la puesta en escena es la prueba de rendimiento , en particular la prueba de carga , ya que suele ser sensible al entorno.
Algunas organizaciones también utilizan la puesta en escena para obtener una vista previa de nuevas funciones para clientes seleccionados o para validar integraciones con versiones en vivo de dependencias externas.
El entorno de producción también se conoce como entorno en vivo , particularmente para servidores, ya que es el entorno con el que los usuarios interactúan directamente.
La implementación en producción es el paso más delicado; se puede realizar implementando código nuevo directamente (sobrescribiendo el código antiguo, de modo que solo haya una copia presente a la vez) o implementando un cambio de configuración. Esto puede tomar varias formas: implementar una instalación paralela de una nueva versión de código y cambiar entre ellas con un cambio de configuración; implementar una nueva versión de código con el comportamiento anterior y un indicador de función , y cambiar al nuevo comportamiento con un cambio de configuración que realiza un cambio de indicador; o implementar servidores separados (uno que ejecuta el código anterior, otro el nuevo) y redirigir el tráfico del anterior al nuevo con un cambio de configuración en el nivel de enrutamiento del tráfico. Estos, a su vez, se pueden realizar todos a la vez o gradualmente, en fases.
La implementación de una nueva versión generalmente requiere un reinicio, a menos que sea posible el intercambio en caliente , y por lo tanto requiere una interrupción en el servicio (habitual para el software del usuario, donde se reinician las aplicaciones) o redundancia, ya sea reiniciar las instancias lentamente detrás de un equilibrador de carga o iniciar nuevos servidores con anticipación y luego simplemente redirigir 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, se puede implementar primero en una sola instancia o fracción de usuarios y luego implementarla en todos o implementarla gradualmente en fases, para detectar cualquier problema de último momento. Esto es similar a la preparación, excepto que se realiza en producción, y se conoce como versión canary , por analogía con la minería de carbón. Esto agrega complejidad debido a que se ejecutan múltiples versiones simultáneamente y, por lo tanto, generalmente finaliza rápidamente, para evitar problemas de compatibilidad.
Desarrollo, ensayo y producción son variables de entorno conocidas y documentadas en ASP.NET Core . Según la variable definida, se ejecuta código y contenido diferente, y se aplican diferentes configuraciones de seguridad y depuración. [8]
Una vez que el desarrollador realiza los casos de prueba unitaria, el código se trasladará a QA para comenzar a realizar pruebas. A menudo, tendrá algunos entornos para realizar pruebas. Por ejemplo, tendrá uno configurado para pruebas del sistema y otro que se utiliza para pruebas de rendimiento y otro más que se utiliza para pruebas de aceptación del usuario (UAT). Esto se debe a las necesidades únicas de cada tipo de prueba.
tecnología de servidores virtuales facilita a las empresas la creación y el desmantelamiento de entornos de prueba en los que pueden garantizar que las aplicaciones se ejecutarán a la perfección en servidores de producción y máquinas cliente.
Las pruebas automatizadas que controlan su aplicación a través de su interfaz de usuario (IU) se conocen como pruebas de IU codificadas (CUIT). Estas pruebas incluyen pruebas funcionales de los controles de la IU. Le permiten verificar que toda la aplicación, incluida su interfaz de usuario, esté funcionando correctamente. Las pruebas de IU codificadas son particularmente útiles cuando hay validación u otra lógica en la interfaz de usuario, por ejemplo, en una página web.
Las pruebas de candidatos a lanzamiento toman demasiado tiempo. Para muchos equipos ágiles, este es el mayor desafío. Las aplicaciones heredadas comienzan con una ventana de prueba más larga que el sprint.