Información sobre los entornos
Los flujos de trabajo de implementación le 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, obtendrá información sobre cómo los entornos de Acciones de GitHub le ayudan a admitir su propio proceso.
¿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. Para minimizar el riesgo, implemente los cambios en un entorno que no sea de producción.
Muchas organizaciones establecen varios entornos que no son de producción, donde implementan progresivamente sus cambios antes de publicarlos 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 pasa por la solución y comprueba que se comporta según lo previsto y que cumple 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, podría tener un flujo de trabajo complejo que se implementa 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 organización que elija como su lista de entornos, el objetivo es mejorar la confianza en un cambio a medida que avanza a través del flujo de trabajo 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:
Actualizará el flujo de trabajo para implementar el código de Bicep en el entorno de prueba y ejecutar algunas pruebas básicas en él. Si ese esfuerzo se realiza correctamente, puede implementarlo en el entorno de producción.
Entornos de flujo de trabajo
Acciones de GitHub también incluye el concepto de entorno. Cree un entorno de Acciones de GitHub para representar el entorno que tiene en Azure. Al definir el flujo de trabajo en un archivo YAML, puede vincular trabajos a un entorno específico. Mediante el uso de entornos, se obtienen algunas características adicionales del flujo de trabajo.
Reglas de protección
Un entorno de Acciones de GitHub puede tener reglas de protección configuradas. Cada vez que el entorno se usa en un trabajo del flujo de trabajo, GitHub Actions se asegurará de que estas reglas se cumplen antes de que el trabajo empiece a ejecutarse.
Por ejemplo, puede configurar revisiones manuales en el entorno de producción. Antes de que se inicie una implementación de producción, el revisor designado recibe una notificación. 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, podría ejecutar una comprobación automatizada para confirmar de qué rama procede el cambio. Si el cambio no está en la rama principal, puede configurar GitHub para impedir que se implemente en el entorno de producción.
Secretos
Acciones de GitHub permite almacenar secretos que solo se pueden usar con un entorno específico. Nos adentraremos en la administración de secretos más adelante en este módulo.
Historial de implementación
Acciones de GitHub 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 llevar un seguimiento de una implementación hasta 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.
Creación de entornos
Puede crear un entorno mediante la interfaz web de GitHub.
Cuando el flujo de trabajo hace referencia a un entorno que no existe, Acciones de GitHub lo crea automáticamente. Esta característica puede afectar a la seguridad del repositorio de GitHub, ya que el nuevo entorno no tendrá ninguna regla de protección configurada. Es mejor que cree un entorno usted mismo a través de la interfaz web GitHub para tener control total sobre su seguridad.
Vinculación de un trabajo de implementación a un entorno
En la definición del flujo de trabajo de implementación, puede hacer referencia a un entorno mediante la propiedad environment:
jobs:
deploy:
environment: Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
En este ejemplo, el trabajo denominado deploy está vinculado al entorno Test.
Entornos y conexiones a Azure
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 al flujo de trabajo de implementación. Debe crear identidades de carga de trabajo independientes para cada entorno. Siguiendo esta práctica, se agrega otra capa de protección para asegurarse de que las implementaciones que no son de producción no afectan al entorno de producción.
Es necesario asignar a las identidades de carga de trabajo permisos específicos para realizar la implementación solo en la suscripción y el grupo de recursos usados por ese entorno:
Importante
Use una identidad de carga de trabajo independiente para cada entorno en el que planee realizar la implementación. Conceda a la identidad de carga de trabajo los permisos mínimos que necesita para implementar en su entorno y 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 identidades de carga de trabajo solo puedan acceder a los entornos a los que necesitan acceder. Además, tenga cuidado de limitar el acceso a su entorno de producción a un pequeño conjunto de personas y a la identidad de carga de trabajo de implementación para ese entorno.
Credenciales federadas para entornos
Cuando la identidad de carga de trabajo se conecta a Azure desde el flujo de trabajo de implementación, usa una credencial federada para autenticarse de forma segura sin secretos ni claves. En los módulos anteriores de esta ruta de aprendizaje, las credenciales federadas concedieron acceso a los flujos de trabajo de implementación cuando se implementaron desde la rama main del repositorio de Git.
Al implementar en un entorno dentro del flujo de trabajo, debe usar una credencial federada con ámbito en ese entorno.
En este módulo, el flujo de trabajo incluye varios trabajos, muchos de los cuales se conectan e implementan en Azure. Algunos de los trabajos usan entornos y algunos no. Por lo tanto, cree dos credenciales federadas para cada una de las identidades de carga de trabajo: una con ámbito en el entorno y otra con ámbito en la rama main.