Integración con GitLab y Azure DevOps

Conexión

En Administración › Integraciones cada proveedor tiene su propia pestaña. El espacio de trabajo se conecta una vez con un token de acceso personal, que se verifica con el proveedor antes de guardarse.

• GitLab: gitlab.com o tu propio GitLab autogestionado por https, con un token que tenga el alcance api.
• Azure DevOps: el nombre de tu organización y un token con Code (Read & write), Build (Read), Project and Team (Read) y Service Hooks (Read, write & manage).
• El token se guarda cifrado, nunca se vuelve a mostrar y puede probarse o reemplazarse en cualquier momento.
• GitHub, GitLab y Azure DevOps pueden estar conectados a la vez; cada proyecto vincula los repositorios con los que trabaja.

Vincular repositorios y trabajo

• En Configuración › Repositorios del proyecto, elige el proveedor y busca sus repositorios.
• Al vincular se crea el webhook del repositorio, con su propia dirección y secreto, para que los cambios lleguen en cuanto ocurren.
• Escribe el código del elemento, como PBI-364, en una rama, un merge o pull request, un mensaje de commit o las notas de una versión y se vincula solo.
• Desde el elemento se puede crear en el repositorio una rama ya nombrada con su código, o agregar un merge request, pull request, rama o commit buscándolo o pegando su URL.

git switch -c feature/PBI-364-conciliacion
git commit -m "PBI-364 conciliación automática de pagos"
git push -u origin feature/PBI-364-conciliacion

Revisiones, pipelines y versiones

• Las aprobaciones de GitLab y los votos de los revisores de Azure DevOps se muestran como resultado de revisión de cada merge o pull request.
• Los pipelines de GitLab CI y las ejecuciones de Azure Pipelines aparecen en los elementos de la rama o el commit en que se ejecutaron, y en Informes › Código y CI.
• Las versiones de GitLab marcan como entregados los elementos que mencionan sus notas.
• Un Deployment con un merge o pull request vinculado cumple el requisito de Pull Request para salir de Desarrollo, y su paquete de evidencias los incluye.

Seguridad

• Cada entrega debe llevar el secreto propio del repositorio —la cabecera de token de GitLab o la autenticación básica de Azure DevOps—, comparado en tiempo constante.
• Las entregas tienen límite de frecuencia y de tamaño, se reducen a los campos usados y se procesan en segundo plano.
• La dirección del servidor debe usar https y nunca puede apuntar a direcciones internas; una instalación on-premise puede llegar a una red privada.
• Cada proyecto accede solo a sus propios repositorios, y cada usuario solo a los ítems que puede ver.