GitHub Apps para empresas: migra tareas concretas, no todos los permisos de un token

GitHub anunció el 23/10 la disponibilidad general de instalaciones enterprise de GitHub Apps y más cobertura administrativa. Las novedades para GHES se prevén en 3.24; no deben darse por disponibles allí por ese anuncio. (GitHub)

Haz una ficha por acción

Una automatización puede leer inventario, cambiar una política y crear un repositorio, aunque hoy utilice una sola credencial. Si migras el token como un bloque, puedes trasladar todos sus privilegios sin preguntarte cuáles necesita cada paso.

La documentación de GitHub separa permisos de repositorio, organización, enterprise y cuenta. Recomienda seleccionar el mínimo requerido por las APIs y los webhooks utilizados. (GitHub)

Compara por tarea, no por etiqueta

PAT y App no son dos casillas que describan toda la seguridad del proceso. Revisa quién mantiene la integración, de qué identidad depende, dónde están las credenciales y qué recursos alcanza. Comprueba también que el método concreto admite el mecanismo de autenticación que has elegido.

Un piloto de lectura antes de escribir

Escoge una operación acotada, como producir un inventario para el responsable técnico. Compara su resultado con una referencia autorizada y comprueba qué ocurre cuando no hay permiso sobre un recurso. El resultado correcto puede ser «sin acceso», acompañado de una explicación utilizable; no una petición automática de privilegios más amplios.

1. Confirmar entorno, cuenta y método exactos en la documentación vigente.
2. Asignar el permiso mínimo y el recurso permitido para el piloto.
3. Ejecutar una lectura limitada y revisar datos, errores y trazabilidad.
4. Comprobar que detener el acceso produce el comportamiento previsto.
5. Solo después, evaluar una escritura concreta con aceptación y reversión.

Los plazos de los tokens y sus mecanismos dependen de cómo se autentique la App y de la operación. Compruébalos en la documentación del caso antes de fijar la rotación. No trasladamos una duración genérica como si sirviera para todas las credenciales de GitHub.

Migrar también significa retirar lo antiguo

Durante una transición pueden convivir dos caminos. Deja claro cuál está autorizado para ejecutar cada tarea, para no provocar cambios duplicados. Cuando aceptes el nuevo recorrido, registra consumidores migrados y revisa la retirada de la credencial anterior; no la conserves indefinidamente como solución informal para errores.

Si falla una escritura, comprueba el estado antes de repetirla por la otra vía. Un timeout no demuestra que la operación no haya ocurrido. El plan de migración debe incluir quién reconcilia esos resultados ambiguos.

Una entrega que otro equipo pueda mantener

Conserva el inventario de acciones, el permiso justificado por cada una, las comprobaciones y la forma de retirar acceso. Para proyectos compartidos con agencias, esa documentación permite acordar interlocución y continuidad sin depender de una credencial personal olvidada.

La colaboración técnica puede incluir esa entrega cuando forme parte del alcance. No afirmamos haber migrado una instalación concreta ni que toda automatización con PAT deba sustituirse sin evaluar antes su compatibilidad.