En l'ecosistema del desenvolupament de programari modern, la gestió de repositoris pot convertir-se en un repte monumental quan es manca d'un sistema clar de propietat. GitHub, una de les plataformes més utilitzades del món, es va enfrontar a una situació crítica: més de 14.000 repositoris a la seva organització interna, dels quals 11.000 estaven actius i una gran part no tenia un propietari definit. Aquest problema, lluny de ser un simple detall administratiu, es va convertir en un obstacle recurrent per a tasques com la rotació de secrets, la resposta a incidents i la gestió de vulnerabilitats. La història de com van resoldre aquest problema ofereix lliçons valuoses per a qualsevol empresa que manegi un volum significatiu de codi.
El problema de fons era estructural. Tot i que existia un registre de serveis (Service Catalog) que associava repositoris a equips responsables, aquesta relació era unidireccional: un servei podia tenir diversos repositoris, però no era fàcil descobrir qui era el propietari d'un repositori que no estigués vinculat a un servei productiu. Això deixava fora repositoris de documentació, eines internes, experiments personals i projectes de hackathons. Cada vegada que es necessitava contactar amb el responsable, calia recórrer a mètodes manuals: revisar l'historial de commits, llegir el README, preguntar a Slack o simplement endevinar. Per a tasques puntuals era molest, però per a processos de seguretat que s'expandien per tota l'organització suposava un risc real. A Q2BSTUDIO, com a empresa especialitzada en desenvolupament d'aplicacions a mida, sabem que la traçabilitat de la propietat és un pilar fonamental per garantir la qualitat i la seguretat del programari.
La solució va passar per convertir la propietat del repositori en una propietat de primer nivell, utilitzant les 'custom properties' de GitHub. Es van definir dues propietats: ownership-type (tipus de propietari) i ownership-name (nom del propietari). Els tipus acceptats van ser 'Service Catalog', 'Hubber Handle' (empleat individual) i 'Team' (equip). Cada valor era validat automàticament per una aplicació GitHub App: els handles havien de pertànyer a membres actius de l'organització, els equips havien de tenir almenys dos integrants i les entrades del catàleg havien de correspondre a serveis actius. Es va optar per ser permissius en el format per reduir la fricció; per exemple, s'acceptava '@meu-equip' com a entrada vàlida, però després la validació rebutjava equips inexistents o empleats que ja no estaven a l'empresa. Aquesta flexibilitat inicial va accelerar l'adopció mentre es mantenia la integritat de les dades.
El desplegament va començar amb una sincronització automàtica des del Service Catalog, que va cobrir uns 1.500 repositoris recolzats per serveis. Els repositoris restants —equips, documentació, projectes personals— havien de completar la informació manualment. Per a això, es va construir una aplicació amb un CronJob a Kubernetes que obria issues recordatoris a cada repositori sense propietari, donant un termini de 30 dies. El primer dia d'execució va ser un dissabte al matí, pensant que ningú ho notaria. Error: en una empresa global sempre hi ha algú treballant, i els issues van començar a aparèixer amb preguntes a Slack. Després del període de gràcia, els repositoris sense propietari van ser arxivats. L'arxiu és reversible i no destructiu: el repositori passa a ser només lectura i s'aturen les Actions, però res s'elimina. Això va permetre aplicar l'arxivament de forma massiva sense debats per casos particulars. Al final, es van arxivar uns 8.000 repositoris, reduint la superfície activa a uns 3.000, tots amb un propietari validat.
No obstant això, no tot va ser perfecte. Es van produir dos incidents menors que van obligar a ajustar el sistema. El primer va ocórrer quan un repositori arxivat impedia que Datadog creés issues automàtics, cosa que va generar una alerta inesperada. La lliçó va ser que els issues de propietat no estaven notificant directament als administradors del repositori. La solució va ser esmentar (@) als administradors i assignar automàticament a tots els usuaris amb permisos d'escriptura, assegurant que les notificacions no passessin desapercebudes. El segon incident va tenir a veure amb la fiabilitat de les dades: si el Service Catalog retornava dades corruptes o desactualitzades, l'aplicació podia arxivar repositoris legítims. Per evitar-ho, es va implementar un 'low water mark': abans d'arxivar, el sistema comptava quants repositoris anava a tocar; si superava un llindar conservador, avortava l'execució i disparava una alerta a Datadog. Aquest enfocament de guardarraïls és quelcom que a Q2BSTUDIO apliquem constantment en els nostres projectes de cloud AWS i Azure, on l'automatització ha de ser robusta davant fonts de dades imperfectes.
Els resultats numèrics parlen per si sols: en 45 dies es va passar de tenir uns 3.000 repositoris arxivats a més d'11.000, mentre que els actius es van reduir a 3.000, tots amb propietari conegut. Molts d'aquests repositoris arxivats portaven anys sense commits: projectes de hackathons abandonats, experiments personals i fins i tot prototips de 2008. Arxivar no només va reduir la superfície d'atac, sinó que també va fer que l'inventari reflectís la realitat operativa. Per mantenir el 100% de cobertura, es va integrar la propietat com a requisit obligatori en tots els fluxos de creació de repositoris, i es va reduir el termini de gràcia a només una hora per a repositoris nous que perdessin la propietat.
La durabilitat de la propietat depèn del tipus. Els serveis segueixen el seu cicle de vida: en descomissionar un servei, els seus repositoris solen arxivar-se. Els equips són estables mentre tinguin almenys un membre. I els empleats individuals només deixen de ser vàlids quan algú se'n va de l'empresa, moment en què els seus repositoris personals també haurien d'arxivar-se. Per a repositoris crítics que han de sobreviure a una persona, la propietat ha de ser un equip o un servei, mai un individu. Aquesta filosofia és aplicable a qualsevol organització que desitgi enfortir la seva postura de seguretat. En un context on la ciberseguretat i la intel·ligència artificial estan transformant el desenvolupament, comptar amb un control de propietat sòlid és indispensable. Per exemple, la implementació d'agents d'IA per automatitzar la detecció de vulnerabilitats en repositoris requereix saber a qui notificar. De la mateixa manera, un panell de BI/Power BI que monitoritzi la salut dels repositoris només és útil si les dades de propietat són fiables.
Per a les empreses que vulguin replicar aquest model, GitHub ofereix les custom properties com a eina nativa. El procés recomanat inclou definir una taxonomia de propietaris (servei, equip, individu), crear les propietats a nivell d'organització, sincronitzar des d'un catàleg de serveis si existeix, fer obligatòria la propietat en la creació, i establir un flux de gràcia amb arxivament com a acció final. Les lliçons apreses són clares: no executar el primer escombratge un dissabte, dissenyar guardarraïls per a l'automatització i notificar directament als responsables. El resultat final és un ecosistema de repositoris ordenat, segur i amb propietaris clars, cosa que permet als equips centrar-se en el que realment importa: desenvolupar programari de qualitat. A Q2BSTUDIO, ajudem les empreses a implementar aquestes pràctiques combinant desenvolupament d'aplicacions a mida, cloud, IA, ciberseguretat i BI, assegurant que la propietat del codi no sigui un mal de cap més.
