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 o componente de software . En casos simples, como el desarrollo y la ejecución inmediata de un programa en la misma máquina, puede haber un solo entorno, pero en el uso industrial, el entorno de desarrollo (donde se realizaron 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 estructurado de administración de versiones permite la implementación por fases (implementación), las pruebas y la reversión 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 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.
Arquitecturas
Las arquitecturas de implementación varían significativamente, pero, en general, los niveles se reservan comenzando en el desarrollo (DEV) y terminando en la producción (PROD). Una arquitectura común de 4 niveles es desarrollo, prueba, modelo, producción (DEV, TEST, MODL, PROD), y el software se implementa en cada uno de ellos 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 continuar con la producción; y Disaster Recovery, para proporcionar un respaldo inmediato en caso de problemas con la producción. Otra arquitectura común es el desarrollo, las pruebas, la aceptación y la 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 (aplicaciones) o clientes, se puede hacer referencia al entorno del usuario (USUARIO) o al entorno local (LOCAL).
Definiciones y límites entre ambientes exactas varían - prueba puede ser considerada parte de dev, aceptación puede ser considerado parte de la prueba, que forma parte de la etapa, o estar separados, etc. Los principales niveles se progresaron a través de en orden, con las nuevas versiones siendo desplegados ( laminado hacia fuera o empujado ) a cada uno a su vez. [1] [2] Los niveles experimentales 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, más simplemente presionando la versión anterior como si fuera una nueva versión. El último paso, la implementación en producción ("empujar para producir") es el más sensible, ya que cualquier problema tiene como resultado un impacto inmediato en el usuario. Por esta razón, esto a menudo se maneja de manera diferente, al menos se monitorea con más cuidado y, en algunos casos, se implementa en fases o solo se requiere accionar un interruptor, lo que permite un retroceso rápido. Es mejor evitar un nombre como Garantía de calidad (QA); Control de calidad no significa pruebas de software. La prueba es importante, pero es diferente 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 versión completa. Puede consistir en un único parche , un paquete de servicio grande o una pequeña revisión .
Los entornos pueden ser de muy diferentes tamaños: 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; La prueba y el control de calidad pueden ser pequeños o grandes, dependiendo de los recursos dedicados a estos, y la puesta en escena puede variar desde una sola máquina (similar a canary) hasta un duplicado exacto de la producción.
Ambientes
La siguiente tabla describe una lista finamente dividida de niveles [ cita requerida ] .
Entorno / Nombre de nivel | Descripción |
---|---|
Local | Escritorio / estación de trabajo del desarrollador |
Desarrollo / Tronco | Servidor de desarrollo que actúa como una caja de arena donde el desarrollador puede realizar las pruebas unitarias |
Integración | Objetivo de compilación de CI , o para que el desarrollador pruebe los efectos secundarios |
Prueba / Prueba / Control de calidad / Aceptación interna | El entorno donde se realizan las pruebas de interfaz. Un equipo de control de calidad garantiza que el nuevo código no tendrá ningún impacto en la funcionalidad existente y prueba las principales funcionalidades del sistema después de implementar el nuevo código en el entorno de prueba. |
Escenario / Escenario / Modelo / Preproducción / Aceptación de clientes externos / Demostración | Espejo del entorno de producción |
Producción / Live | Sirve a los usuarios finales / clientes |
Desarrollo
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 de varias maneras: el destino 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, el entorno del desarrollador lo hará. 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 , en particular con varios desarrolladores, se establecen distinciones más precisas: un desarrollador tiene una copia de trabajo del código fuente en su máquina y los cambios se envían al repositorio y se envían al tronco o a una rama, según 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 . La creación de la copia del repositorio del código fuente en un entorno limpio es un paso separado, 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 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 rama, corresponde a presionar para liberar de local (entorno de desarrollador individual) a integración (construcción limpia); un lanzamiento incorrecto en este paso significa que un cambio rompió la compilación, y revertir el lanzamiento corresponde a revertir todos los cambios desde ese punto en adelante, o deshacer solo el cambio de ruptura, si es posible.
Pruebas
El propósito del entorno de prueba es permitir que los probadores humanos ejerciten código nuevo y modificado mediante comprobaciones automatizadas o técnicas no automatizadas. Una vez que el desarrollador acepta el nuevo código y las configuraciones mediante pruebas unitarias en el entorno de desarrollo, los elementos se mueven 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, contactar al 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 pueden virtualizarse [4] para permitir que se realicen pruebas rápidas y paralelas. Por ejemplo, las pruebas de interfaz de usuario automatizadas [5] pueden ocurrir en varios sistemas operativos virtuales y pantallas (reales o virtuales). Las pruebas de rendimiento pueden requerir una configuración de hardware básica 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 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 contribuyen de manera importante al desarrollo rápido de software.
Puesta en escena
Un entorno de etapa, preparación o preproducción es un entorno de prueba 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 ensayo es probar todos los scripts y procedimientos de instalación / configuración / migración antes de aplicarlos 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 a menudo son sensibles al entorno.
Algunas organizaciones también utilizan la puesta en escena para obtener una vista previa de nuevas funciones para seleccionar clientes o para validar integraciones con versiones en vivo de dependencias externas.
Producción
El entorno de producción también se conoce como en vivo , en particular para los 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 tomar varias formas: implementar una instalación paralela de una nueva versión de código y alternar entre ellas con un cambio de configuración; implementar una nueva versión de código con el comportamiento anterior y una bandera de función , y cambiar al nuevo comportamiento con un cambio de configuración que realiza un cambio de bandera; o mediante la implementación de servidores separados (uno que ejecuta el código antiguo, el otro el nuevo) y redirigir 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, se pueden hacer 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 equilibrador de carga o iniciando nuevos servidores antes de tiempo 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, con el fin de capturar la última -Problemas de minutos. Esto es similar a la puesta en escena, excepto que se realiza realmente en la producción, y se conoce como un lanzamiento canario , por analogía con la minería del carbón. Esto agrega complejidad debido a que se ejecutan múltiples versiones simultáneamente y, por lo tanto, generalmente se termina rápidamente para evitar problemas de compatibilidad.
Integración de marcos
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 definida, se ejecuta un código diferente y se procesa el contenido, y se aplican diferentes configuraciones de seguridad y depuración. [8]
Ver también
Referencias
- ^ "Práctica tradicional de desarrollo / integración / puesta en escena / producción para el desarrollo de software" . El bufón de la tecnología disruptiva de la biblioteca . 4 de diciembre de 2006.
- ^ "Sandboxes de desarrollo: una 'mejor práctica ' ágil " . www.agiledata.org .
- ^ Ellison, Richard (20 de junio de 2016). "Mejores prácticas de entornos de prueba de software" . Revista de pruebas de software . Martinig y asociados . Consultado el 2 de diciembre de 2016 .
Una vez que el desarrollador realiza los casos de prueba unitaria, el código se moverá a QA para comenzar a probar. A menudo, tendrá algunos entornos para realizar pruebas. Por ejemplo, tendrá uno configurado para las pruebas del sistema y otro que se utilizará para las pruebas de rendimiento y otro que se utilizará para las pruebas de aceptación del usuario (UAT). Esto se debe a las necesidades únicas de cada tipo de prueba.
- ^ Dubie, Denise (17 de enero de 2008). "Cómo mantener bajo control los entornos de prueba virtuales" . Red Mundial, Inc . IDG . Consultado el 2 de diciembre de 2016 .
La tecnología de servidor virtual facilita a las empresas la instalación y eliminación de entornos de prueba en los que pueden garantizar que las aplicaciones se ejecuten a la par en los servidores de producción y las máquinas cliente.
- ^ "Utilice la automatización de la interfaz de usuario para probar su código" . Microsoft.com . Microsoft . Consultado el 2 de diciembre de 2016 .
Las pruebas automatizadas que impulsan 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.
- ^ Heusser, Matthew (7 de julio de 2015). "¿Está probando demasiado su software?" . CIO.com . IDG . Consultado el 3 de diciembre de 2016 .
La prueba del candidato de lanzamiento lleva 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.
- ^ Sharma, Anurag (2018). Gestión del entorno de prueba . Prensa ITSM. pag. 11. ISBN 9781912651269.
- ^ "Utilice múltiples entornos en ASP.NET Core" . docs.microsoft.com . Consultado el 5 de abril de 2019 .