Revisión y combinación de cambios de Bicep
Ha aprendido a usar ramas de características y a aplicar la protección de ramas para asegurarse de que los cambios se revisen antes de que se combinen. Ahora, debe seguir un proceso coherente para proponer y revisar los cambios antes de que se combinen.
En esta unidad, aprenderá más sobre las solicitudes de extracción, incluido cómo crearlas y usarlas. También aprenderá a usar solicitud de incorporación de cambios para revisar el código Bicep.
Solicitudes de incorporación de cambios
Una solicitud de extracción es una solicitud que usted, el desarrollador de una característica, hace a la persona encargada del mantenimiento de la rama principal. Pida a la persona encargada del mantenimiento que extraiga los cambios en la rama principal del repositorio.
Solicitud de incorporación de cambios y protecciones de ramas
Al configurar las protecciones de rama, puede requerir que los propietarios del código revisen la solicitud de incorporación de cambios. Por ejemplo, puede incluir a los gestores del proyecto como revisores para todas las solicitudes de incorporación de cambios, o puede especificar que un determinado número de personas deba revisar cada solicitud de incorporación de cambios.
Solicitudes de incorporación de cambios y directivas de rama
Al configurar directivas de rama, puede requerir que personas específicas o un grupo de personas revisen la solicitud de incorporación de cambios. Por ejemplo, puede incluir a los gestores del proyecto como revisores para todas las solicitudes de incorporación de cambios, o puede especificar que un determinado número de personas deba revisar cada solicitud de incorporación de cambios.
También puede requerir que cada solicitud de incorporación de cambios esté vinculada a un elemento de trabajo. Con esta configuración, puede realizar un seguimiento desde un elemento de trabajo que contiene una solicitud de característica al código que implementa el cambio, hasta la implementación en el entorno de producción.
Crear una solicitud de incorporación de cambios
Puede crear una solicitud de incorporación de cambios mediante la interfaz web de GitHub. Seleccione la rama de origen, donde ha realizado los cambios, y la rama de destino, que suele ser la rama principal del repositorio.
Puede crear una solicitud de incorporación de cambios mediante la interfaz web de Azure DevOps. Seleccione la rama de origen, donde ha realizado los cambios, y la rama de destino, que suele ser la rama principal del repositorio.
Al crear una solicitud de incorporación de cambios, debe darle un nombre. Es una buena práctica poner nombres a las solicitudes de incorporación de cambios que sean claros y comprensibles. Esta práctica ayuda a los miembros del equipo a comprender el contexto de lo que se les pide que revisen. Si tienen diferentes áreas de experiencia, un buen nombre puede ayudarles a encontrar solicitudes de incorporación de cambios en las que puedan aportar comentarios significativos y omitir las solicitudes de extracción que no son pertinentes.
Además, los nombres de las solicitudes de cambios suelen formar parte del historial del repositorio de Git, por lo que es recomendable hacer que sean comprensibles para quien mire el historial.
También puede proporcionar una descripción a las solicitudes de incorporación de cambios. Puede mencionar a personas específicas o hacer referencia a problemas en sus descripciones. Muchos equipos crean plantillas estandarizadas para las descripciones de las solicitudes de incorporación de cambios para que esté claro cuál es cada cambio.
También puede proporcionar una descripción a las solicitudes de incorporación de cambios. Puede mencionar a personas específicas o hacer referencia a elementos de trabajo en las descripciones. Muchos equipos crean plantillas estandarizadas para las descripciones de las solicitudes de incorporación de cambios para que esté claro cuál es cada cambio.
Al crear una solicitud de incorporación de cambios, puede invitar a personas a revisar los cambios.
A veces, se crea una solicitud de incorporación de cambios solo para obtener comentarios de los compañeros. En estas situaciones, puede especificar que la solicitud de incorporación de cambios es un borrador. Los revisores sabrán que sigue trabajando en los cambios. Los revisores todavía pueden proporcionar comentarios, pero está claro que los cambios aún no están listos para combinarse. Cuando esté satisfecho con los cambios, puede quitar el estado de borrador.
Incluso después de crear una solicitud de incorporación de cambios, puede seguir realizando cambios en el código en la rama de características. Estos cambios se convierten en parte de la solicitud de incorporación de cambios.
Revisión de una solicitud de incorporación de cambios
Al revisar una solicitud de incorporación de cambios, puede ver todos los cambios. Puede hacer comentarios en toda la solicitud de cambios o simplemente en partes específicas de los archivos que se han cambiado. El autor de la solicitud de incorporación de cambios puede responder a los comentarios y otros revisores pueden participar en los debates. Estas características de comentarios hacen que la colaboración en las solicitudes de incorporación de cambios sea una experiencia interactiva.
Al revisar el código Bicep, busque estos elementos clave:
- ¿Se puede implementar el archivo? Implemente y pruebe el código Bicep antes de combinarlo. Asegúrese de que no hay advertencias de linter y de que la implementación de Azure se realiza correctamente. En un próximo módulo de Microsoft Learn, aprenderá sobre los enfoques para implementar y comprobar automáticamente los cambios.
- ¿Es claro y comprensible el código Bicep? Es importante que todos los miembros del equipo comprendan el código Bicep. Al revisar un archivo de Bicep en una solicitud de incorporación de cambios, asegúrese de comprender exactamente para qué sirve cada cambio. ¿Tienen las variables y los parámetros nombres adecuados? ¿Se han usado comentarios para explicar las secciones complejas de código?
- ¿Se ha completado el cambio? Si esta solicitud de incorporación de cambios representa parte de un trabajo más amplio, asegúrese de que el entorno funcionará cuando este cambio se combine e implemente. Por ejemplo, si la solicitud de incorporación de cambios vuelve a configurar un recurso de Azure como preparación para un cambio posterior, compruebe que el recurso sigue funcionando correctamente a lo largo de todo el proceso. Si la solicitud de incorporación de cambios agrega un nuevo recurso de Azure que aún no es necesario, considere si se debe agregar temporalmente una condición para que el recurso no se implemente hasta que sea necesario.
- ¿Sigue el cambio las prácticas de Bicep adecuadas? En otros módulos de Microsoft Learn, ha aprendido sobre los elementos del código Bicep correcto. Asegúrese de que el código que revise siga esos mismos procedimientos recomendados.
- ¿Coincide el cambio con la descripción? Es una buena práctica que las solicitudes de incorporación de cambios incluyan un título descriptivo. Muchos equipos también requieren que las solicitudes de incorporación de cambios incluyan una descripción del cambio y su finalidad. Compruebe que los cambios en el código Bicep coinciden con los detalles de las solicitudes de incorporación de cambios. Si el autor de la solicitud de incorporación de cambios se ha vinculado a elementos de trabajo o incidencias, compruebe que los cambios de la solicitud de incorporación de cambios cumplen los criterios de éxito definidos por el elemento de trabajo.
Completar una solicitud de incorporación de cambios
Una vez aprobada la solicitud de incorporación de cambios, dicha solicitud se puede completar. Esto significa que el contenido de la solicitud de incorporación de cambios se combina en la rama principal.
En algunos equipos, el autor de la solicitud de cambios también debe completarla. Este proceso ayuda a garantizar que el autor controla cuándo se produce la combinación y puede estar disponible para supervisar cualquier implementación automatizada. En otros equipos, los aprobadores completan la solicitud de extracción. El equipo debe decidir quién combina las solicitudes de incorporación de cambios y cuándo.
En algunos equipos, el autor de la solicitud de cambios también debe completarla. Este proceso ayuda a garantizar que el autor controla cuándo se produce la combinación y puede estar disponible para supervisar cualquier implementación automatizada. En otros equipos, los aprobadores completan la solicitud de extracción. Incluso puede usar Azure DevOps para completar automáticamente una solicitud de incorporación de cambios cuando cumpla los criterios de aprobación. El equipo debe decidir quién combina las solicitudes de incorporación de cambios y cuándo.
Proceso del equipo
Después de empezar a usar ramas de características y solicitudes de incorporación de cambios, el proceso del equipo puede cambiar a algo parecido a lo siguiente:
Un miembro del equipo clona el repositorio compartido.
Realiza cambios locales en una rama de su propia copia local del repositorio.
Cuando terminen con sus cambios, insertan su rama local en el repositorio compartido.
Dentro del repositorio compartido, crean una solicitud de incorporación de cambios para combinar la rama en main.
Otros miembros del equipo revisan los cambios. Cuando se satisfacen, aprueban la solicitud de incorporación de cambios y se combina en la rama principal del repositorio compartido.
Eliminan las ramas del repositorio compartido y en su copia local del repositorio.
En algunos escenarios, la inserción del repositorio remoto desencadena una canalización automatizada para comprobar, probar e implementar el código. Obtendrá más información sobre las canalizaciones en otros módulos de Microsoft Learn.
En el diagrama siguiente se muestra este proceso.
