En implementación de software , un entorno o nivel es un sistema informático o conjunto de sistemas en los que se implementa y ejecuta un programa informático o componente de software . En casos simples, como desarrollar y ejecutar inmediatamente un programa en la misma máquina, puede haber un solo entorno, pero en el uso industrial, el entorno de desarrollo (donde se realizan originalmente los cambios) y el entorno de producción (lo que usan los usuarios finales) están separados. , a menudo con varias etapas intermedias. Este proceso estructurado de gestión de lanzamientos permite la implementación (implementación), pruebas y reversión por fases en caso de problemas.
Los entornos pueden variar significativamente en tamaño: el entorno de desarrollo suele ser 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 la computación en la nube . El código, los datos y la configuración se pueden implementar en paralelo y no es necesario conectarse al nivel correspondiente; por ejemplo, el código de preproducción puede conectarse a una base de datos de producción.
Las arquitecturas de implementación varían significativamente, pero, en términos generales, los niveles se delimitan comenzando en el desarrollo (DEV) y terminando en la producción (PROD). Una arquitectura común de 4 niveles es desarrollo, prueba, modelo y producción (DEV, TEST, MODL, PROD), y el software se implementa en cada uno en orden. Otros entornos comunes incluyen Control de Calidad (QC), para pruebas de aceptación ; sandbox o experimental (EXP), para experimentos que no están destinados a pasar a producción; y Recuperación ante Desastres, para proporcionar un respaldo inmediato 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, se puede hacer referencia al entorno de usuario (USER) o al 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 de la etapa o estar separada, etc. Los niveles principales avanzan en orden, y se implementan nuevas versiones ( hacia afuera o empujado ) a cada uno 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 la producción, implementada después de la producción. En caso de problemas, se puede volver a la versión anterior, simplemente presionando la versión anterior como si fuera una nueva. El último paso, implementar en producción ("empujar a producción") es el más delicado, ya que cualquier problema genera un impacto inmediato en el usuario. Por esta razón, esto a menudo se maneja de manera diferente, al menos se monitorea más cuidadosamente y, en algunos casos, se implementa por fases o solo se requiere presionar un interruptor, lo que permite una rápida reversión. Es mejor evitar un nombre como Garantía de Calidad (QA); Control de calidad no significa pruebas de software. Las pruebas son importantes, pero son diferentes del control de calidad.
A veces, la implementación se realiza fuera de este proceso regular, principalmente para proporcionar cambios urgentes o relativamente menores, sin requerir una publicación completa. Esto puede consistir en un único parche , un paquete de servicio grande o una pequeña revisión .
Los entornos pueden ser de tamaños muy diferentes: el desarrollo suele ser la estación de trabajo de un desarrollador individual (aunque puede haber miles de desarrolladores), mientras que la producción puede consistir en 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 ellos, y la puesta en escena 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 necesaria ] .
El entorno de desarrollo (dev) es el entorno en el que se desarrollan los cambios en el software, más simplemente la estación de trabajo de un desarrollador individual. Esto difiere del entorno de destino final en varios aspectos: el objetivo puede no ser una computadora de escritorio (puede ser un teléfono inteligente, un sistema integrado, una máquina sin cabeza en un centro de datos, etc.) e incluso si es similar en otros aspectos, el entorno del desarrollador será diferente. incluyen 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 revisiones , particularmente con múltiples desarrolladores, se hacen 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, siendo confirmados en el tronco o en una rama, dependiendo de Metodología de desarrollo. El entorno de una estación de trabajo individual, en el que se trabajan y 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 (integrar cambios dispares), y este entorno puede denominarse 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 a nivel de código fuente de "realizar un cambio en el repositorio", seguido de la construcción del tronco o rama, corresponde a impulsar la liberación desde el entorno local (entorno de desarrollador individual) a la integración (compilación limpia); una mala versión en este paso significa que un cambio rompió la compilación, y revertir la versión corresponde a revertir todos los cambios desde ese punto en adelante o deshacer solo el cambio importante, si es posible.
El propósito del entorno de prueba es permitir a los evaluadores humanos ejercitar código nuevo y modificado mediante comprobaciones automatizadas o técnicas no automatizadas. Después de que el desarrollador acepta el nuevo código y las configuraciones mediante pruebas unitarias en el entorno de desarrollo, los elementos se trasladan a uno o más entornos de prueba. [3] Si la prueba falla, 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 pruebas y 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 diferentes tipos de pruebas sugieren diferentes tipos de entornos de prueba, algunos o todos de los cuales pueden virtualizarse [4] para permitir que se realicen 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 de referencia física 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 fallas en hardware virtual y redes virtuales.
Las pruebas pueden ser en serie (una tras otra) o en paralelo (algunas o todas a la vez) dependiendo de la sofisticación 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 la entrega en producción. [6] Los entornos de prueba altamente automatizados y paralelizados son contribuyentes importantes al rápido desarrollo de software.
Un entorno de escenario, ensayo o preproducción es un entorno para pruebas que se parece 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 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/migración antes de que se apliquen a un entorno de producción. Esto garantiza que todas las actualizaciones mayores 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 son las pruebas de rendimiento , en particular las pruebas de carga , ya que suelen ser sensibles al entorno.
Algunas organizaciones también utilizan la preparación para obtener una vista previa de nuevas funciones para seleccionar clientes o para validar integraciones con versiones en vivo de dependencias externas.
El entorno de producción también se conoce como 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 hacer implementando código nuevo directamente (sobrescribiendo el código antiguo, de modo que solo haya una copia a la vez) o implementando un cambio de configuración. Esto puede adoptar 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 característica , y cambiar al nuevo comportamiento con un cambio de configuración que realiza un cambio de indicador; o implementando servidores separados (uno que ejecuta el código antiguo, otro el nuevo) y redirigiendo el tráfico del antiguo al nuevo con un cambio de configuración en el nivel de enrutamiento del tráfico. Estos, a su vez, pueden realizarse 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 reiniciando las instancias lentamente detrás de un balanceador de carga o iniciando. 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 única instancia o fracción de usuarios y luego implementarla en todos o implementarla gradualmente en fases para detectar cualquier última versión. -Problemas minuciosos. Esto es similar a la puesta en escena, excepto que en realidad se realiza en producción, y se conoce como liberación canaria , por analogía con la minería del carbón. Esto añade complejidad debido a que se ejecutan varias versiones simultáneamente y, por lo tanto, suele finalizar rápidamente para evitar problemas de compatibilidad.
Desarrollo, puesta en escena y producción son variables de entorno conocidas y documentadas en ASP.NET Core . Dependiendo de la variable definida, se ejecuta código diferente y se representa contenido, 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á al control de calidad para comenzar las pruebas.
A menudo tendrá algunos entornos para realizar pruebas.
Por ejemplo, tendrá uno configurado para pruebas del sistema, otro para pruebas de rendimiento y otro más para pruebas de aceptación del usuario (UAT).
Esto se debe a las necesidades únicas de cada tipo de prueba.
La tecnología de servidor virtual facilita a las empresas la configuración y desmantelamiento de entornos de prueba en los que pueden garantizar que las aplicaciones se ejecutarán a la par 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 (UI) se conocen como pruebas de UI codificadas (CUIT).
Estas pruebas incluyen pruebas funcionales de los controles de la interfaz de usuario.
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 lanzamiento de candidatos llevan 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.