Información sobre los entornos
Las canalizaciones de implementación permiten automatizar los pasos del proceso de implementación. A menudo es necesario ejecutar los pasos en varios entornos independientes. En la empresa de juguetes, quiere revisar los cambios realizados en el código antes de implementarlos en el entorno de producción.
En esta unidad va a ver cómo ayudan los entornos de Azure Pipelines a admitir un flujo de trabajo propio.
¿Por qué hay varios entornos?
Los procesos de implementación hacen cambios en los recursos de Azure, incluidos los recursos en uso. El cambio en los recursos conlleva cierto riesgo, ya que es posible que los cambios que se implementan no se comporten según lo esperado. Incluso es posible que se descubra que los cambios interrumpen la configuración actual.
Para minimizar el riesgo de problemas, un procedimiento recomendado es probar los cambios de forma segura antes de implementarlos en el entorno de producción. Por ejemplo, puede implementar los cambios en un entorno que no sea de producción.
Muchas organizaciones configuran varios entornos que no son de producción, donde implementan progresivamente los cambios antes de implementarlos en producción. Cada entorno que no es de producción tiene un fin concreto y, a menudo, hasta requisitos de calidad específicos que deben cumplirse para pasar al siguiente entorno. Si algo va mal, como un error en una prueba, la implementación se detiene. A medida que la implementación va pasando por cada entorno, aumenta la confianza en los cambios.
Los entornos comunes incluyen:
Desarrollo: los desarrolladores suelen usar un entorno de desarrollo para probar sus cambios e iterar rápidamente en su trabajo.
Los entornos de desarrollo suelen tener controles mínimos para que los miembros del equipo puedan probar fácilmente las ideas. Puede usar un entorno de desarrollo para probar una determinada configuración en un recurso o para ver cómo puede configurar un nuevo sitio web con una base de datos back-end de forma segura. Es posible que muchos de estos cambios y pruebas no avancen en el proceso de implementación, ya que se eliminan las ideas que no prosperan.
En algunos equipos, es posible que incluso se configure un entorno de desarrollo independiente para cada miembro del equipo, de modo que no se produzcan interferencias mientras se trabaja en nuevas características.
Los entornos de desarrollo a veces también se denominan entornos de espacio aislado.
Prueba: un entorno de prueba está diseñado para ejecutar pruebas manuales o automatizadas en los cambios.
Los entornos de prueba se pueden usar en un proceso de integración continua. Después de implementar un cambio en un entorno de prueba, se pueden ejecutar pruebas automatizadas en él. Si todas las pruebas automatizadas son correctas, resulta seguro combinar el cambio en la rama principal del proyecto. Las pruebas automatizadas suelen comprobar la funcionalidad básica del sistema, junto con aspectos como infracciones de directivas en los recursos recién implementados.
También se pueden crear entornos de prueba dedicados para tipos específicos de pruebas, como pruebas de rendimiento y seguridad.
Integración: un entorno de integración puede ayudar a probar cualquier punto de integración con otros sistemas.
En un entorno de integración se pueden simular transacciones de un extremo a otro. Estas pruebas suelen ejecutarse automáticamente, aunque muchas organizaciones también realizan pruebas manuales en este entorno.
Los entornos de integración a veces también se denominan entornos de prueba de integración del sistema (SIT).
Pruebas de aceptación de usuario: un entorno de pruebas de aceptación de usuario (UAT) se usa para la validación manual, normalmente realizada por partes interesadas empresariales en lugar de desarrolladores. En la validación manual, alguien revisa la solución y comprueba que se comporta según lo previsto y que logra los requisitos empresariales necesarios. Posteriormente, esa persona aprueba los cambios para que la implementación pueda continuar.
Preproducción: un entorno de preproducción suele ser un reflejo del entorno de producción, con SKU de recursos y configuración equivalentes. Se usa como comprobación final para verificar cómo se va a comportar la implementación de producción durante y después de aplicar el cambio. También se puede usar para comprobar si se espera algún tiempo de inactividad durante la implementación de producción.
Los entornos de preproducción a veces también se denominan entornos de ensayo.
Producción: el entorno de producción es el que usan los usuarios finales de la aplicación. Es el entorno en directo que se quiere proteger para que siga funcionando tanto como sea posible.
En algunas organizaciones puede haber varios entornos de producción. Por ejemplo, puede haber entornos de producción en regiones geográficas diferentes o para atender a diferentes grupos de clientes.
Demostración: el equipo también puede crear entornos de demostración para mostrar la aplicación a los usuarios finales, para su uso en actividades de formación o para que los equipos de ventas muestren ciertas capacidades a los clientes potenciales. Es posible que incluso haya varios entornos de demostración que sirvan para distintos fines. Un entorno de demostración suele ser una réplica reducida del entorno de producción, con datos de clientes falsos.
Entornos de la organización
Es posible que vea variaciones de estos entornos. Algunas organizaciones usan solo unos cuantos entornos, mientras que otras emplean muchos más. El número y el tipo de entornos que se usan depende de la solución que se va a implementar, del tamaño del equipo que la está compilando y de la importancia de la carga de trabajo.
A veces, un único entorno asume el rol de varios de los entornos indicados anteriormente. En otras ocasiones, puede haber una canalización compleja que implemente los cambios en varios entornos, algunos en paralelo y otros en secuencia. Algunas organizaciones incluso eliminan o desaprovisionan automáticamente entornos cuando ya no se usan y, posteriormente, los vuelven a implementar si se necesitan.
Sea cual sea la lista de entornos que elija la organización, el objetivo es mejorar la confianza en un cambio a medida que avanza a lo largo de la canalización de implementación. Si un cambio no cumple los requisitos de calidad, se recomienda detener la implementación de ese cambio en cualquier entorno posterior de la cadena.
En la empresa de juguetes se decide empezar con un conjunto básico de entornos para el sitio web. Además del entorno de producción, va a crear un entorno que no sea de producción de nombre Prueba:
Va a actualizar la canalización para implementar el código de Bicep en el entorno de prueba y ejecutar algunas pruebas básicas en él. Si la operación se realiza correctamente, el código se implementa en el entorno de producción.
Entornos de canalización
Azure Pipelines también tiene el concepto de entorno. Cree un entorno de Azure Pipelines para representar el que tiene en Azure. Al definir la canalización en un archivo YAML, se vinculan los trabajos de implementación a un entorno específico. Con los entornos se obtienen otras características en la canalización.
Comprobaciones y aprobaciones
Un entorno de Azure DevOps puede tener configuradas comprobaciones y aprobaciones. Cada vez que se usa el entorno en un trabajo en la canalización, Azure DevOps se asegura de que estas comprobaciones y aprobaciones tengan un resultado satisfactorio antes de que el trabajo empiece a ejecutarse.
Por ejemplo, puede configurar aprobaciones manuales en el entorno de producción. Antes de que se inicie una implementación en el entorno de producción, el aprobador designado recibe una notificación por correo electrónico. Esa persona puede comprobar manualmente que se cumplen las directivas y los procedimientos antes de que comience la implementación. Por ejemplo, el aprobador puede comprobar que todo funciona según lo previsto en el entorno de preproducción antes de aprobar la implementación.
Además, puede ejecutar una comprobación automatizada para revisar los registros y las tasas de error del entorno de preproducción después de la última implementación. Si la comprobación confirma que el número de errores no ha aumentado considerablemente, permite que la implementación continúe.
Historial de implementación
Azure Pipelines realiza un seguimiento del historial de las implementaciones en un entorno. Este historial constituye una manera sencilla de realizar un seguimiento de lo que sucede en el entorno a lo largo del tiempo. Incluso permite seguir paso a paso una implementación en una solicitud de característica específica en los elementos de trabajo de Azure Boards, o en una confirmación en el repositorio. Esta característica puede ser útil si tiene un problema con una implementación y necesita identificar el cambio que lo ha provocado.
Seguridad
Puede aplicar otros controles de seguridad en entornos. Puede restringir las canalizaciones a las que se les permite usar un entorno específico. O impedir que alguien cree sin querer una canalización secundaria que interactúe con el entorno de producción.
También puede aplicar permisos de usuario para controlar qué usuarios pueden administrar entornos. Hay permisos específicos que pueden permitir a los usuarios crear nuevos entornos, modificar entornos y ver entornos y su historial de implementaciones.
Nota:
Cuando la canalización hace referencia a un entorno que aún no existe, Azure Pipelines lo crea automáticamente. Esta característica puede afectar a la seguridad del proyecto de Azure DevOps, ya que se obtienen automáticamente permisos administrativos en el entorno. Es mejor crear un entorno personalmente mediante la interfaz web de Azure DevOps para tener control total sobre la seguridad y no obtener accidentalmente permisos que no se necesitan.
Vinculación de un trabajo de implementación a un entorno
En la definición de la canalización de implementación, se crea una propiedad deployment para especificar un trabajo de implementación y se especifica el nombre del entorno en el que se implementa el trabajo:
- stage: DeployTest
displayName: Deploy (Test Environment)
jobs:
- deployment: DeployWebsite
environment: Test
strategy:
runOnce:
deploy:
steps:
- checkout: self
En el ejemplo, el trabajo denominado DeployWebsite está vinculado al entorno Test.
Sugerencia
Los trabajos también tienen otras propiedades, incluida la estrategia de implementación, que están fuera del ámbito de este módulo. En la unidad de resumen se incluyen vínculos a más información.
Entornos y conexiones de servicio
Cuando se usan varios entornos, es necesario que cada entorno sea independiente de los demás. Por ejemplo, el sitio web del entorno de desarrollo no debe poder acceder a una base de datos del entorno de producción.
El mismo principio también se aplica a la canalización de implementación. La conexión de servicio que se usa para implementar en el entorno de desarrollo no debe poder acceder al entorno de producción. Con este principio se agrega otra capa de protección para garantizar que las implementaciones que no son de producción no afecten al entorno de producción.
Debe crear conexiones de servicio independientes para cada entorno. Cada conexión de servicio debe usar su propia entidad de servicio dedicada, con permisos específicos para implementar solo en la suscripción y el grupo de recursos usados por ese entorno:
Importante
Use una entidad de servicio y una conexión de servicio independientes para cada entorno en el que planee realizar la implementación. Conceda a la entidad de servicio los permisos mínimos necesarios para implementar en su entorno y en ningún otro.
También es buena idea separar los entornos en Azure. Como mínimo, debe crear un grupo de recursos independiente para cada entorno. En muchas situaciones, es mejor crear suscripciones de Azure independientes para cada entorno. Luego puede crear varios grupos de recursos dentro de la suscripción de cada entorno.
Aplique asignaciones de roles de Azure para que los usuarios y las entidades de servicio solo puedan acceder a los entornos a los que necesitan hacerlo. Además, ocúpese de limitar el acceso al entorno de producción a un pequeño conjunto de personas y a la entidad de servicio de implementación de ese entorno.