Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este tutorial, aprenderá a integrar entornos Azure Deployment Environments en la canalización de CI/CD. Puede usar cualquier proveedor de GitOps que admita CI/CD, como Acciones de GitHub, Azure Arc, GitLab o Jenkins.
La integración y entrega continuas (CI/CD) es un enfoque de desarrollo de software que ayuda a los equipos a automatizar el proceso de creación, prueba e implementación de cambios de software. CI/CD le permite liberar cambios de software con más frecuencia y con más confianza.
Se usa un flujo de trabajo que incluye tres ramas: main, dev y test.
- La rama principal siempre se considera producción.
- Las ramas de características se crean a partir de la rama principal .
- Puede crear solicitudes de incorporación de cambios para combinar ramas de características en main.
El flujo de trabajo de este tutorial es un ejemplo simplificado. Los flujos de trabajo reales pueden ser más complejos.
Antes de comenzar este tutorial, puede familiarizarse con los componentes y conceptos de entornos de implementación revisando conceptos clave para entornos de implementación de Azure.
En este tutorial, aprenderá a:
- Creación y configuración de un centro de desarrollo
- Crear una bóveda de claves
- Creación y configuración de un repositorio de GitHub
- Conexión del catálogo al centro de desarrollo
- Configurar identidades de implementación
- Configuración de entornos de GitHub
- Prueba de la canalización de CI/CD
Prerrequisitos
| Producto | Requisitos |
|---|---|
| Azur | - Una suscripción de Azure. - Permisos de propietario en la suscripción de Azure. - CLI de Azure instalada. |
| Git | - Una cuenta de GitHub. - Git instalado. |
1. Creación y configuración de un centro de desarrollo
En esta sección, creará un centro de desarrollo y un proyecto de entornos de implementación de Azure con tres tipos de entorno: Desarrollo, Pruebas y Prod.
- El tipo de entorno Prod contiene un único entorno de producción.
- Se crea un nuevo entorno en Desarrollo para cada rama de características.
- Se crea un nuevo entorno en Prueba para cada pull request.
1.1 Configuración de la CLI de Azure
Para empezar, inicie sesión en Azure. Ejecute el siguiente comando y siga las indicaciones para completar el proceso de autenticación:
az login
A continuación, instale la extensión del centro de desarrollo de Azure para la CLI de Azure:
az extension add --name devcenter --upgrade
Ahora que la extensión actual está instalada, registre el espacio de nombres Microsoft.DevCenter.
az provider register --namespace Microsoft.DevCenter
Sugerencia
En este tutorial, guardará varios valores como variables de entorno para usarlas más adelante. También puede que quiera registrar estos valores en otro lugar para asegurarse de que están disponibles cuando los necesite.
Obtenga el identificador de usuario y establézcalo en una variable de entorno para más adelante:
MY_AZURE_ID=$(az ad signed-in-user show --query id -o tsv)
Recupere el identificador de suscripción de la suscripción actual:
AZURE_SUBSCRIPTION_ID=$(az account show --query id --output tsv)
Recupere el identificador de inquilino del inquilino actual:
AZURE_TENANT_ID=$(az account show --query tenantId --output tsv)
Establezca estas variables de entorno:
LOCATION="eastus"
AZURE_RESOURCE_GROUP=<resourceGroupName>
AZURE_DEVCENTER=<devcenterName>
AZURE_PROJECT=<projectName>
AZURE_KEYVAULT=<keyVaultName>
Nota:
Debe usar un nombre único a nivel global para el almacén de claves. De lo contrario, es posible que reciba el siguiente error:
Code: VaultAlreadyExists Message: The vault name 'mykeyvaultname' is already in use. Vault names are globally unique so it is possible that the name is already taken.
1.2 Creación de un centro de desarrollo
Un centro de desarrollo es una colección de proyectos y entornos que tienen una configuración similar. Los centros de desarrollo proporcionan acceso a un catálogo de plantillas y artefactos que se pueden usar para crear entornos. Los centros de desarrollo también proporcionan una manera de administrar el acceso a entornos y proyectos.
Cree un grupo de recursos:
az group create \
--name $AZURE_RESOURCE_GROUP \
--location $LOCATION
Cree un centro de desarrollo:
az devcenter admin devcenter create \
--name $AZURE_DEVCENTER \
--identity-type SystemAssigned \
--resource-group $AZURE_RESOURCE_GROUP \
--location $LOCATION
El comando anterior genera JSON. Guarde los valores de id y identity.principalId como variables de entorno para usarlos más adelante:
AZURE_DEVCENTER_ID=<id>
AZURE_DEVCENTER_PRINCIPAL_ID=<identity.principalId>
1.3 Asignar el rol de propietario de identidad del Centro de desarrollo en la suscripción
Un centro de desarrollo necesita permisos para asignar roles en suscripciones asociadas a los tipos de entorno.
Para reducir la complejidad innecesaria, en este tutorial usará una única suscripción tanto para el centro de desarrollo como para todos los tipos de entornos. En la práctica, las suscripciones del centro de desarrollo y de implementación de destino probablemente sean suscripciones independientes con diferentes políticas aplicadas.
az role assignment create \
--scope /subscriptions/$AZURE_SUBSCRIPTION_ID \
--role Owner \
--assignee-object-id $AZURE_DEVCENTER_PRINCIPAL_ID \
--assignee-principal-type ServicePrincipal
1.4 Crear los tipos de entorno
En el nivel central de desarrollo, los tipos de entorno definen los entornos que los equipos de desarrollo pueden crear, como desarrollo, pruebas, espacio aislado, preproducción y producción.
Cree tres tipos de entorno nuevos: Desarrollo, Prueba y Prod:
az devcenter admin environment-type create \
--name Dev \
--resource-group $AZURE_RESOURCE_GROUP \
--dev-center $AZURE_DEVCENTER
az devcenter admin environment-type create \
--name Test \
--resource-group $AZURE_RESOURCE_GROUP \
--dev-center $AZURE_DEVCENTER
az devcenter admin environment-type create \
--name Prod \
--resource-group $AZURE_RESOURCE_GROUP \
--dev-center $AZURE_DEVCENTER
1.5 Creación de un proyecto
Un proyecto es el punto de acceso para el equipo de desarrollo. Cada proyecto está asociado a un centro de desarrollo.
Cree un proyecto:
az devcenter admin project create \
--name $AZURE_PROJECT \
--resource-group $AZURE_RESOURCE_GROUP \
--location $LOCATION \
--dev-center-id $AZURE_DEVCENTER_ID
El comando anterior genera JSON. Guarde el id valor como una variable de entorno para usarla más adelante:
AZURE_PROJECT_ID=<id>
Asígnese el rol DevCenter Project Admin en el proyecto:
az role assignment create \
--scope "$AZURE_PROJECT_ID" \
--role "DevCenter Project Admin" \
--assignee-object-id $MY_AZURE_ID \
--assignee-principal-type User
1.6 Crear tipos de entorno de proyecto
En el nivel de proyecto, los ingenieros de plataforma especifican qué tipos de entorno son adecuados para el equipo de desarrollo.
Cree un nuevo tipo de entorno de proyecto para cada uno de los tipos de entorno que creó en el centro de desarrollo:
az devcenter admin project-environment-type create \
--name Dev \
--roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
--deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
--resource-group $AZURE_RESOURCE_GROUP \
--location $LOCATION \
--project $AZURE_PROJECT \
--identity-type SystemAssigned \
--status Enabled
az devcenter admin project-environment-type create \
--name Test \
--roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
--deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
--resource-group $AZURE_RESOURCE_GROUP \
--location $LOCATION \
--project $AZURE_PROJECT \
--identity-type SystemAssigned \
--status Enabled
az devcenter admin project-environment-type create \
--name Prod \
--roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
--deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
--resource-group $AZURE_RESOURCE_GROUP \
--location $LOCATION \
--project $AZURE_PROJECT \
--identity-type SystemAssigned \
--status Enabled
2. Crear un almacén de claves
En esta sección, creará un nuevo almacén de claves. Use este almacén de claves más adelante en el tutorial para guardar un token de acceso personal desde GitHub.
az keyvault create \
--name $AZURE_KEYVAULT \
--resource-group $AZURE_RESOURCE_GROUP \
--location $LOCATION \
--enable-rbac-authorization true
De nuevo, guarde la id salida JSON del comando anterior como una variable de entorno.
AZURE_KEYVAULT_ID=<id>
Asígnese el rol de administrador de Key Vault en el nuevo almacén de claves.
az role assignment create \
--scope $AZURE_KEYVAULT_ID \
--role "Key Vault Administrator" \
--assignee-object-id $MY_AZURE_ID \
--assignee-principal-type User
Asigne el rol de usuario de secretos de Key Vault a la identidad del centro de desarrollo:
az role assignment create \
--scope $AZURE_KEYVAULT_ID \
--role "Key Vault Secrets User" \
--assignee-object-id $AZURE_DEVCENTER_PRINCIPAL_ID \
--assignee-principal-type ServicePrincipal
3. Creación y configuración de un repositorio de GitHub
En esta sección, creará un nuevo repositorio de GitHub para almacenar un catálogo. Los entornos de implementación de Azure admiten repositorios de GitHub y Azure DevOps. En este tutorial, usará GitHub.
3.1 Creación de un repositorio de GitHub
En este paso, creará un nuevo repositorio en la cuenta de GitHub que tiene una estructura de directorios predefinida, ramas y archivos. Estos elementos se generan a partir de un repositorio de plantillas de ejemplo.
Genere un nuevo repositorio de GitHub a partir de la plantilla de ejemplo:
Si no tiene una cuenta de GitHub de pago, establezca el repositorio en Público.
Seleccione Create repository (Crear repositorio).
3.2 Proteger la rama principal del repositorio
Puede proteger las ramas importantes estableciendo reglas de protección de ramas. Las reglas de protección definen si los colaboradores pueden eliminar una rama o forzar la inserción en la rama. También establecen requisitos para las inserciones en la rama, como tener que pasar comprobaciones de estado o aplicar un historial de confirmaciones lineales.
Nota:
Las ramas protegidas están disponibles en repositorios públicos con GitHub Free y GitHub Free para organizaciones, y en repositorios públicos y privados con GitHub Pro, GitHub Team, GitHub Enterprise Cloud y GitHub Enterprise Server. Para más información, consulte Planes de GitHub.
Si aún no está abierto, vaya a la página principal del repositorio.
Seleccione Configuración en el menú de la parte superior de la ventana:
En la sección Código y automatización de la barra lateral izquierda, seleccione Ramas:
En Reglas de protección de rama, seleccione Agregar conjunto de reglas de rama:
En la página Nuevo conjunto de reglas de rama , en Nombre del conjunto de reglas, escriba CI-CD-tutorial-ruleset:
En Ramas de destino, seleccione Agregar destino y, a continuación, seleccione Incluir rama predeterminada o Incluir todas las ramas:
En Reglas de rama, seleccione Requerir una solicitud de extracción antes de fusionar:
Opcionalmente, puede habilitar más reglas de protección.
Selecciona Crear.
3.3 Configuración de variables de repositorio
En la sección Seguridad de la barra lateral, seleccione Secretos y variables y, a continuación, seleccione Acciones:
Seleccione la pestaña Variables.
Para cada elemento de la tabla siguiente:
- Seleccione Nueva variable de repositorio.
- En el campo Nombre , escriba el nombre de la variable.
- En el campo Valor , escriba el valor descrito en la tabla.
- Seleccione Agregar variable.
Nombre de la variable Valor de la variable AZURE_DEVCENTER Nombre del centro de desarrollo AZURE_PROJECT Nombre del proyecto AZURE_CATALOG Configurar en Entornos AZURE_CATALOG_ITEM Establecer en FunctionApp AZURE_SUBSCRIPTION_ID Identificador de suscripción de Azure AZURE_TENANT_ID Identificador de inquilino de Azure
3.4 Creación de un token de acceso personal de GitHub
A continuación, cree un token de acceso personal granular para permitir que el centro de desarrollo de Azure Deployment Environments se conecte al repositorio y consuma el catálogo de entornos.
Nota:
Puede dejar comentarios sobre los tokens de acceso personal específicos en la discusión de comentarios.
En la esquina superior derecha de cualquier página de GitHub.com, seleccione la foto del perfil y, a continuación, seleccione Configuración.
En la barra lateral izquierda, seleccione Configuración del desarrollador.
En la barra lateral izquierda, en Tokens de acceso personal, seleccione Tokens específicos y, a continuación, seleccione Generar nuevo token:
En la página Nuevo token de acceso personal específico, bajo Nombre del token, escriba un nombre para el token.
En Expiración, selecciona cuándo expirará el token.
En Propietario del recurso, seleccione el nombre de usuario de GitHub.
En Acceso al repositorio, seleccione Solo repositorios. En Repositorios seleccionados, busque y seleccione el repositorio que creó:
En Permisos, seleccione Permisos del repositorio y, a continuación, cambie Contenido a Solo lectura:
Seleccione Generar token.
Copie y guarde el token de acceso personal. No podrá volver a verlo.
3.5 Guarde el token de acceso personal en el almacén de claves
A continuación, guarde el token de acceso personal como un secreto en el almacén de claves denominado pat:
az keyvault secret set \
--name pat \
--vault-name $AZURE_KEYVAULT \
--value <personalAccessToken>
4. Conectar el catálogo al centro de desarrollo
En entornos de implementación de Azure, un catálogo es un repositorio que contiene un conjunto de definiciones de entorno. Los elementos de catálogo constan de una plantilla de infraestructura como código (IaC) y un archivo de entorno que actúa como manifiesto. La plantilla define el entorno, y el archivo de entorno proporciona metadatos sobre la plantilla. Los equipos de desarrollo usan definiciones de entorno del catálogo para crear entornos.
La plantilla que usó para crear el repositorio de GitHub contiene un catálogo en la carpeta Entornos .
Adición del catálogo al centro de desarrollo
En el comando siguiente, reemplace por < Organization/Repository > el nombre del repositorio y la organización de GitHub:
az devcenter admin catalog create \
--name Environments \
--resource-group $AZURE_RESOURCE_GROUP \
--dev-center $AZURE_DEVCENTER \
--git-hub path="/Environments" branch="main" secret-identifier="https://$AZURE_KEYVAULT.vault.azure.net/secrets/pat" uri="https://github.com/< Organization/Repository >.git"
5. Configuración de identidades de implementación
OpenID Connect con Acciones de GitHub es un método de autenticación que usa tokens de corta duración para proporcionar seguridad protegida. Es la manera recomendada de autenticar Acciones de GitHub en Azure.
También puede autenticar una entidad de servicio directamente mediante un secreto, pero esto no se aborda en este tutorial.
5.1 Generación de identidades de implementación
Registre aplicaciones y entidades de servicio de Microsoft Entra para cada uno de los tres tipos de entorno.
Cree la aplicación Microsoft Entra para Dev:
az ad app create --display-name "$AZURE_PROJECT-Dev"Este comando genera JSON con un
idque se utiliza al crear credenciales federadas con Graph API y unappId(también denominado identificador de cliente).Establezca estas variables de entorno:
DEV_AZURE_CLIENT_ID=<appId> DEV_APPLICATION_ID=<id>Repita estos pasos para Probar:
az ad app create --display-name "$AZURE_PROJECT-Test"TEST_AZURE_CLIENT_ID=<appId> TEST_APPLICATION_ID=<id>Repita los pasos de nuevo para Prod:
az ad app create --display-name "$AZURE_PROJECT-Prod"PROD_AZURE_CLIENT_ID=<appId> PROD_APPLICATION_ID=<id>Configure una entidad principal de servicio para cada aplicación.
Ejecute el comando siguiente para crear una nueva entidad de servicio para Dev:
az ad sp create --id $DEV_AZURE_CLIENT_IDEste comando genera una salida JSON con un valor diferente
idque se usará en el paso siguiente.Establezca la siguiente variable de entorno:
DEV_SERVICE_PRINCIPAL_ID=<id>Repita estos pasos para Probar:
az ad sp create --id $TEST_AZURE_CLIENT_IDTEST_SERVICE_PRINCIPAL_ID=<id>Repita los pasos de nuevo para Prod:
az ad sp create --id $PROD_AZURE_CLIENT_IDPROD_SERVICE_PRINCIPAL_ID=<id>Ejecute los siguientes comandos para crear una nueva credencial de identidad federada para cada aplicación de Microsoft Entra.
En cada uno de los tres comandos siguientes, reemplace por
< Organization/Repository >el nombre del repositorio y la organización de GitHub.Cree la credencial de identidad federada para Dev:
az rest --method POST \ --uri "https://graph.microsoft.com/beta/applications/$DEV_APPLICATION_ID/federatedIdentityCredentials" \ --body '{"name":"ADEDev","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Dev","description":"Dev","audiences":["api://AzureADTokenExchange"]}'Cree la credencial para Prueba:
az rest --method POST \ --uri "https://graph.microsoft.com/beta/applications/$TEST_APPLICATION_ID/federatedIdentityCredentials" \ --body '{"name":"ADETest","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Test","description":"Test","audiences":["api://AzureADTokenExchange"]}'Cree la credencial para Prod:
az rest --method POST \ --uri "https://graph.microsoft.com/beta/applications/$PROD_APPLICATION_ID/federatedIdentityCredentials" \ --body '{"name":"ADEProd","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Prod","description":"Prod","audiences":["api://AzureADTokenExchange"]}'
5.2 Asignar roles a las identidades de implementación
Asigne el rol de Lector a cada identidad de implementación en el proyecto:
az role assignment create \ --scope "$AZURE_PROJECT_ID" \ --role Reader \ --assignee-object-id $DEV_SERVICE_PRINCIPAL_ID \ --assignee-principal-type ServicePrincipalaz role assignment create \ --scope "$AZURE_PROJECT_ID" \ --role Reader \ --assignee-object-id $TEST_SERVICE_PRINCIPAL_ID \ --assignee-principal-type ServicePrincipalaz role assignment create \ --scope "$AZURE_PROJECT_ID" \ --role Reader \ --assignee-object-id $PROD_SERVICE_PRINCIPAL_ID \ --assignee-principal-type ServicePrincipalAsigne el rol de Usuario de Entornos de Implementación al tipo de entorno correspondiente de cada identidad de implementación.
az role assignment create \ --scope "$AZURE_PROJECT_ID/environmentTypes/Dev" \ --role "Deployment Environments User" \ --assignee-object-id $DEV_SERVICE_PRINCIPAL_ID \ --assignee-principal-type ServicePrincipalaz role assignment create \ --scope "$AZURE_PROJECT_ID/environmentTypes/Test" \ --role "Deployment Environments User" \ --assignee-object-id $TEST_SERVICE_PRINCIPAL_ID \ --assignee-principal-type ServicePrincipalaz role assignment create \ --scope "$AZURE_PROJECT_ID/environmentTypes/Prod" \ --role "Deployment Environments User" \ --assignee-object-id $PROD_SERVICE_PRINCIPAL_ID \ --assignee-principal-type ServicePrincipal
6. Configuración de entornos de GitHub
Con los entornos de GitHub, puede configurar entornos con reglas de protección y secretos. Un trabajo de flujo de trabajo que haga referencia a un entorno debe seguir las reglas de protección del entorno antes de ejecutar o acceder a los secretos del entorno.
Cree entornos de desarrollo, pruebas y prod que se asignen a los tipos de entorno en el proyecto Entornos de implementación de Azure.
Nota:
Los entornos, los secretos de entorno y las reglas de protección del entorno están disponibles en repositorios públicos para todos los productos. Para acceder a entornos, secretos de entorno e ramas de implementación en repositorios privados o internos, debe usar GitHub Pro, GitHub Team o GitHub Enterprise. Para acceder a otras reglas de protección del entorno en repositorios privados o internos, debe usar GitHub Enterprise. Para más información, consulte Planes de GitHub.
6.1 Creación del entorno de desarrollo
En GitHub, vaya a la página principal del repositorio.
En el nombre del repositorio, seleccione Configuración. Si no puede ver la pestaña Configuración , seleccione el menú desplegable ... y, a continuación, seleccione Configuración.
En la barra lateral izquierda, seleccione Entornos.
Seleccione Nuevo entorno y escriba Desarrollo para el nombre del entorno y, a continuación, seleccione Configurar entorno:
En Secretos de entorno, seleccione Agregar secreto de entorno y, a continuación, escriba AZURE_CLIENT_ID en el cuadro Nombre .
En el cuadro Valor , escriba el identificador de cliente (
appId) de la aplicación Dev Microsoft Entra que creó anteriormente (guardada como la variable de$DEV_AZURE_CLIENT_IDentorno):Seleccione Add secret (Agregar secreto).
6.2 Creación del entorno de prueba
Vuelva a la página de entornos principales seleccionando Entornos en la barra lateral izquierda.
Seleccione Nuevo entorno, escriba Probar para el nombre del entorno y, a continuación, seleccione Configurar entorno.
En Secretos de entorno, seleccione Agregar secreto de entorno y, a continuación, escriba AZURE_CLIENT_ID en el cuadro Nombre .
En el cuadro Valor, escriba el identificador de cliente (
appId) de la aplicación Test de Microsoft Entra que creó anteriormente (guardado como la variable de entorno$TEST_AZURE_CLIENT_ID).Seleccione Add secret (Agregar secreto).
6.3 Creación del entorno de Prod
Una vez más, vuelva a la página principal de Entornos seleccionando Entornos en la barra lateral izquierda.
Seleccione Nuevo entorno, escriba Prod como nombre del entorno y, a continuación, seleccione Configurar entorno.
En Secretos de entorno, seleccione Agregar secreto de entorno y, a continuación, escriba AZURE_CLIENT_ID en el cuadro Nombre .
En el cuadro Valor , escriba el identificador de cliente (
appId) de la aplicación Prod Microsoft Entra que creó anteriormente (guardada como variable de$PROD_AZURE_CLIENT_IDentorno).Seleccione Add secret (Agregar secreto).
A continuación, debes establecerte como revisor necesario para este entorno. Cuando se intenta implementar en Prod, GitHub Actions espera una aprobación antes de comenzar. Mientras un trabajo está esperando la aprobación, tiene el estado Esperando. Si un trabajo no se aprueba en un plazo de 30 días, falla automáticamente.
Para obtener más información sobre entornos y aprobaciones necesarias, consulte Uso de entornos para la implementación.
Seleccione Revisores obligatorios.
Busque y seleccione el nombre de usuario de GitHub. Puede entrar hasta seis personas o equipos. Solo uno de los revisores requeridos necesita aprobar el job para que éste pueda proceder.
Seleccione Guardar reglas de protección.
Por último, configure main como rama de implementación:
En la lista Ramas y etiquetas de implementación , seleccione Ramas y etiquetas seleccionadas.
Seleccione Agregar rama de implementación o regla de etiqueta, asegúrese de que Tipo ref: Rama está seleccionada y, a continuación, escriba main en el cuadro Patrón de nombre .
Seleccione Agregar regla.
7. Probar la tubería de CI/CD
En esta sección, realizas algunos cambios en el repositorio y pruebas la canalización de CI/CD.
7.1 Clonar el repositorio
En Git Bash, use
cdpara cambiar a una carpeta donde quiera clonar el repositorio localmente.Clone el repositorio. Asegúrese de reemplazar
< Organization/Repository >en el siguiente comando por el nombre del repositorio y la organización de GitHub.git clone https://github.com/< Organization/Repository >.gitVaya al directorio clonado:
cd <repository>Cree una rama y publíquela de forma remota:
git checkout -b feature1git push -u origin feature1Se crea un nuevo entorno específico de esta rama en Azure.
En GitHub, vaya a la página principal del repositorio recién creado.
En el nombre del repositorio, seleccione Acciones:
Debería ver un nuevo flujo de trabajo de Crear Entorno en ejecución.
7.2 Realizar un cambio en el código
Abra el repositorio clonado localmente en Visual Studio Code.
En la carpeta ADE.Tutorial, realice un cambio en un archivo.
Guarde el cambio.
7.3 Insertar los cambios para actualizar el entorno
Almacene provisionalmente los cambios e insértelos en la rama
feature1:git add . git commit -m '<commit message>' git pushEn la página Acciones del repositorio, verá que se ejecuta un nuevo flujo de trabajo de Update Environment.
7.4 Crear una solicitud de incorporación de cambios (pull request)
Cree una solicitud de incorporación de cambios en GitHub
main <- feature1.En la página Acciones del repositorio, verá que se ha iniciado un nuevo flujo de trabajo para crear un entorno específico de la solicitud de incorporación de cambios. Se usa el tipo de entorno de prueba.
7.5 Combinar la solicitud de incorporación de cambios
En GitHub, vaya al pull request que creó.
Combine la solicitud de incorporación de cambios.
Los cambios se publican en el entorno de producción y se eliminan los entornos de branch y pull request.
Limpieza de recursos
Si no planea usar ninguno de los recursos que ha creado, elimínelos para no incurrir en cargos. Si ha implementado la aplicación de ejemplo en otro grupo de recursos, puede repetir los siguientes pasos.
Para eliminar recursos desde Azure Portal:
Seleccione el botón del menú de la esquina superior izquierda y, después, seleccione Grupos de recursos.
En la lista, seleccione el grupo de recursos que creó.
Seleccione Eliminar grupo de recursos.
Escriba el nombre del grupo de recursos. A continuación, seleccione Eliminar.
Para eliminar recursos mediante la CLI de Azure, escriba el siguiente comando:
az group delete --name <my-dev-center-rg>
Recuerde que al eliminar el grupo de recursos se eliminan todos los recursos que contiene.
Contenido relacionado
- Creación y acceso a un entorno mediante la CLI de Azure
- Para obtener una lista completa de comandos, consulte la documentación de la CLI de Azure sobre Microsoft Dev Box y los Entornos de Implementación de Azure.