Entorno de implementación: Deployment environment

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 único 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).

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 estar separada, etc. Los niveles principales avanzan en orden, con nuevas versiones que se implementan ( enrolladas hacia fuera o empujado ) a cada uno de ellos. 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); QA 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 de niveles finamente dividida.

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); una versión incorrecta 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 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 a través de 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. Si la prueba falla, el entorno de prueba puede eliminar el código defectuoso de las plataformas de prueba, ponerse en contacto 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 controla 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 para permitir que se realicen pruebas rápidas y paralelas. Por ejemplo, las pruebas de interfaz de usuario automatizadas 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. 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. 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 que se apliquen a un entorno de producción. Esto asegura 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 cambiar 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 y 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, pueden hacerse 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.

Ver también

• Gestión del ciclo de vida de las aplicaciones
• Desarrollo, prueba, aceptación y producción
• Entorno de desarrollo integrado
• Desarrollo de software

Referencias