GitHub Copilot Enterprise: Ghid pentru Spaces și API-ul Usage Metrics

Ce este GitHub Copilot Enterprise?

GitHub Copilot Enterprise se află în vârful ierarhiei de planuri Copilot de la GitHub.

Comparativ cu GitHub Copilot Business sau Pro+, Enterprise pune accent puternic pe guvernanță, context organizațional și capabilități de măsurare. Este conceput pentru companii care operează medii de inginerie mari, nu pentru dezvoltatori individuali sau echipe mici.

Două capabilități contează cel mai mult în practică:

1. Context organizațional personalizat prin Spaces
2. Telemetrie la nivel de organizație prin API-ul Usage Metrics

Aceste două funcționalități transformă Copilotul din „autocomplete inteligent” într-o platformă internă de inginerie cu AI.

Companiile care obțin cea mai mare valoare din GitHub Copilot Enterprise îl tratează ca pe o componentă-cheie a infrastructurii interne. Configurează cu grijă contextul organizațional, măsoară constant adoptarea și ajustează politicile pe baza datelor de utilizare, nu a presupunerilor.

Pentru o privire mai amplă asupra ecosistemului GitHub, îți recomand să citești ghidul nostru Introduction to GitHub Products.

Cum diferă Enterprise de Business și Pro+

GitHub Copilot Enterprise extinde abonamentul Business cu funcții suplimentare precum:

• Metrici de utilizare la nivel de organizație
• Controale de guvernanță extinse
• Moștenirea politicilor la nivel de enterprise
• Alocări mai mari pentru cereri premium (1.000 vs 300 în nivelul Business)
• Acces și management suplimentar al modelelor

Enterprise necesită GitHub Enterprise Cloud pe lângă abonamentul Copilot Enterprise în sine. Acest lucru adaugă un cost suplimentar per utilizator, așa că asigură-te că organizația ta chiar are nevoie de guvernanță, telemetrie și administrare la nivel enterprise.

Notă: Abonații Business accesează API-ul Usage Metrics la nivel de organizație (/orgs/{org}/…). Abonații Enterprise accesează suplimentar rapoarte agregate la nivel enterprise (/enterprises/{enterprise}/…) care acoperă toate organizațiile într-o singură vizualizare.

Pentru cine este GitHub Copilot Enterprise

GitHub Copilot Enterprise vizează organizațiile care operează deja medii GitHub mature.

Clienții tipici Enterprise includ:

• Organizații mari de inginerie
• Industrii reglementate
• Grupuri de platform engineering multi-echipă
• Companii cu standarde interne de dezvoltare
• Organizații care necesită guvernanță centralizată

Reține că acest lucru nu îmbunătățește inerent performanța Copilot. Cred că această distincție contează deoarece multe echipe cumpără inițial prea mult. Presupun că Enterprise înseamnă „Copilot mai bun”, când, în realitate, Enterprise adaugă în principal instrumente de guvernanță și măsurare.

Copilot Spaces: context personalizat pentru organizația ta

Copilot Spaces rezolvă una dintre cele mai mari slăbiciuni ale asistenților de codare AI generalizați.

Din cutie, Copilot înțelege destul de bine cunoștințele publice de programare. Nu înțelege automat API-urile tale interne, deciziile de arhitectură, convențiile de cod, fluxurile de deployment sau documentația de onboarding.

Spaces oferă un context organizațional selectat, pe care Copilot îl poate referi în timpul conversațiilor și asistenței la codare.

În practică, Spaces ajută Copilot să răspundă la întrebări precum:

• „Cum structurăm intern handler-ele de API?”
• „Ce bibliotecă de autentificare recomandă echipa noastră de platformă?”
• „Ce flux de deployment ar trebui să folosească acest microserviciu?”
• „Ce convenții de denumire urmează echipa noastră de backend?”

Ce acceptă Spaces

Spaces acceptă o gamă mai largă de conținut organizațional decât vechiul sistem Knowledge Bases.

Tipurile de conținut acceptate includ:

• Fișiere de cod
• Documentație Markdown
• Fișiere JSON
• Fișiere încărcate
• Imagini
• GitHub Issues
• Pull requests

Fiecare tip de conținut contribuie diferit.

Fișierele de cod ajută Copilot să înțeleagă tiparele de implementare. Fișierele Markdown oferă explicații de arhitectură și ghidaj pentru onboarding. Pull request-urile expun discuții de review și decizii istorice de inginerie. Această combinație îi oferă lui Copilot o mai bună conștientizare a practicilor de dezvoltare ale organizației tale.

Un punct subtil, dar important, este că Spaces nu sunt pur și simplu baze de date vectoriale atașate la GitHub. Ele includ controale de partajare și fluxuri de lucru de guvernanță organizațională concepute pentru medii enterprise.

Retragerea Knowledge Bases

GitHub a retras vechea funcție Copilot Knowledge Bases pe 1 noiembrie 2025.

Spaces a înlocuit Knowledge Bases cu:

• Suport mai larg pentru conținut
• Controale de partajare mai bune
• Administrare îmbunătățită
• Management mai flexibil la nivel de organizație

Încă vei găsi documentație și articole de blog învechite care fac referire la Knowledge Bases. Ai grijă când urmezi tutoriale mai vechi, deoarece multe endpoint-uri și fluxuri de lucru s-au schimbat în perioada de tranziție 2025–2026.

Crearea și configurarea Copilot Spaces

Din perspectiva administrării, Copilot Spaces sunt destul de ușor de creat. Provocarea apare la gestionarea a zeci sau sute dintre ele în echipe.

Structura pe care o alegi devreme tinde să rămână. Am văzut organizații care au creat din greșeală „împrăștiere de documentație” în Spaces pentru că nimeni nu a stabilit din start reguli de responsabilitate.

Oricine poate crea un Copilot Space, așa că hai să testăm crearea unuia într-un repo personal. Acești pași sunt similari la nivel Enterprise, cu câteva pagini diferite.

Configurarea unui Space

Crearea unui Space urmează, în general, acest flux:

1. Accesează pagina Copilot Spaces în zona ta de administrare Enterprise
2. Creează un Space nou

3. Selectează repository-urile și sursele de conținut, inclusiv MCP-uri și alte instrumente utile

4. Adăugarea surselor se poate face făcând clic pe butonul „+ Add sources” din partea dreaptă

5. Poți alege să partajezi spațiul sau să configurezi setările de partajare în acest pas

6. Verifică dacă Copilot poate face referire la conținut în timpul conversațiilor

O notă pentru utilizatorii enterprise: administratorul tău poate dezactiva partajarea Spaces personale. Așadar, dacă folosești propriul cont, acest lucru îți poate afecta abilitatea de a partaja un Copilot Space care nu folosește repository-urile enterprise-ului.

După configurare, administratorii ar trebui să testeze Space-ul cu prompturi practice.

De exemplu:

How does our authentication middleware handle token refresh logic?

Sau:

Show me an example of how our backend services structure database migrations.

Dacă Copilot nu poate răspunde corect, de obicei problema este una dintre următoarele:

• Repository-uri lipsă
• Calitate slabă a documentației
• Permisiuni incorecte
• Timp insuficient pentru indexare

Partajare și controale de acces

Spaces acceptă două modele principale de vizibilitate:

• Spaces individuale
• Spaces la nivel de organizație

Membrii unui enterprise pot avea spațiile individuale gestionate de setările enterprise-ului. Administratorii enterprise pot, de asemenea, gestiona centralizat politicile de previzualizare și disponibilitatea funcțiilor. 

Spaces private sunt potrivite pentru echipe experimentale sau inițiative interne sensibile. Spaces la nivel de organizație au sens pentru standarde de inginerie, documentație de onboarding sau framework-uri la nivel de companie.

O greșeală frecventă este supra-centralizarea. Un singur Space uriaș la nivel de companie poate deveni zgomotos și dificil de folosit eficient de către Copilot.

Organizarea Spaces pe echipă sau domeniu

Nu există o structură organizațională universal corectă.

Modelele comune includ un space per echipă, un space per zonă de produs sau spaces partajate pentru standarde. Fiecare are un alt scop și folosește practic aceleași setări în mod diferit.

Un Space per echipă

Util când grupurile de inginerie operează relativ independent.

Exemple:

• Platform engineering
• Data engineering
• Dezvoltare mobilă

Un Space per zonă de produs

Util pentru organizațiile structurate în jurul produselor, nu al departamentelor.

Exemple:

• Plăți
• Analitice
• Infrastructură
• Platformă pentru clienți

Space pentru standarde partajate

Multe organizații mențin un Space partajat separat pentru:

• Linii directoare de securitate
• Convenții de codare
• Fluxuri de lucru pentru deployment
• Standardele de arhitectură

În practică, abordările hibride funcționează de obicei cel mai bine. Fiecare echipă poate avea propriul space, iar spaces mai mari cu standarde sunt partajate între echipe.

API-ul Copilot Usage Metrics

Spaces rezolvă problema contextului. API-ul Usage Metrics rezolvă problema măsurării. A înlocuit mai multe sisteme vechi de telemetrie pe care GitHub le-a retras în timpul consolidării API din 2026. 

Fără măsurători clare, organizațiile își pierd rapid vizibilitatea asupra succesului adoptării Copilot. Conducerea vrea dovezi că investiția îmbunătățește fluxurile de lucru ale dezvoltatorilor, nu doar adaugă un nou abonament.

Dashboard-ul a ajuns în disponibilitate generală în februarie 2026 și este accesibil prin contul tău enterprise → AI Controls → Copilot → Metrics → Copilot usage metrics, în fila Insights.

Exemplu de Copilot Usage Metrics Dashboard de pe github.blog

Ce măsoară API-ul

API-ul Usage Metrics expune mai multe categorii de telemetrie operațională.

Metricile comune includ:

• Utilizatori activi
• Linii de cod sugerate vs linii de cod acceptate
• Tipare de utilizare a IDE-urilor
• Utilizarea modelelor
• Interacțiuni cu agenții
• Defalcări pe limbaje

Acest lucru oferă organizațiilor o imagine mult mai nuanțată decât simplele numărători de locuri.

O echipă cu 100 de locuri alocate, dar doar 15 utilizatori activi are un profil de adoptare foarte diferit față de una cu utilizare zilnică constantă și rate mari de acceptare.

Tranziția API din 2026

GitHub a retras mai multe API-uri de telemetrie anterioare (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) în perioada de tranziție 2025–2026, acestea fiind complet retrase până în aprilie 2026.

Acestea au inclus:

• API-ul Metrics vechi
• API-urile Feature Engagement
• API-urile Direct Data Access

Noile endpoint-uri Usage Metrics, disponibile din februarie 2026, au consolidat aceste sisteme de raportare într-un model mai unificat, care include și versionarea acestor API-uri în caz de schimbări majore.

Acest lucru contează deoarece multe articole de blog și exemple GitHub mai vechi încă fac referire la endpoint-uri depreciate. Ori de câte ori lucrezi cu API-ul Usage Metrics, verifică întotdeauna documentația în raport cu cele mai recente referințe API GitHub înainte de a construi automatizări în jurul lui.

Interogarea API-ului Usage Metrics

Acum că înțelegem scopul API-ului usage metrics, hai să vorbim despre cum îl folosim efectiv în practică.

Autentificare și permisiuni

Endpoint-urile GitHub Copilot Usage Metrics îți cer, de obicei, să configurezi câteva permisiuni pentru Personal Access Token (PAT). Acest lucru se poate face fie prin PAT clasic, fie prin PAT cu granularitate fină.

• Pentru PAT-urile clasice, vei avea nevoie ca administratorul enterprise să îți ofere următoarele permisiuni: manage_billing:copilot și read:org. 

• Pentru token-urile cu acces granular, trebuie să te asiguri că folosești tokenul de acces al utilizatorului aplicației GitHub sau tokenul de acces al instalării cu setul de permisiuni Enterprise Copilot metrics enterprise permissions (read).

De obicei, folosirea token-urilor cu granularitate fină este preferată pentru că reduc expunerea inutilă a permisiunilor.

Endpoint-uri la nivel de organizație

Cele mai comune rapoarte la nivel de organizație sunt:

• organization-1-day

• organization-28-day

Raport de o zi la nivel de organizație

Raportul de o zi este util pentru monitorizare operațională și analiză a tendințelor pe termen scurt. Datele istorice sunt disponibile începând cu 10 octombrie 2025 și pot fi accesate timp de până la un an de la data curentă.

Comanda curl de mai jos va apela API-ul pentru raportul de o zi și va returna un răspuns JSON cu linkuri de descărcare pentru rapoartele de utilizare. Va trebui să incluzi YOUR_TOKEN pentru autentificarea bearer și să alegi o DAY pentru ziua specifică a raportului, în format YYYY-MM-DD.

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY"

URL-urile din download_links sunt semnate și limitate în timp, ceea ce înseamnă că expiră la scurt timp după obținere. Fluxul tău trebuie să preia URL-ul de descărcare și să tragă imediat fișierul în aceeași rulare; nu poți stoca aceste URL-uri pentru utilizare ulterioară.

Răspunsul pe care îl primești poate conține doar download_links și report_day, dar acesta este schema completă potențială:

{
  "type": "object",
  "title": "Copilot Metrics 1 Day Report",
  "description": "Links to download the Copilot usage metrics report for an enterprise/organization for a specific day.",
  "properties": {
    "download_links": {
      "type": "array",
      "items": {
        "type": "string",
        "format": "uri"
      },
      "description": "The URLs to download the Copilot usage metrics report for the enterprise/organization for the specified day."
    },
    "report_day": {
      "type": "string",
      "format": "date",
      "description": "The day of the report in YYYY-MM-DD format."
    }
  },
  "required": [
    "download_links",
    "report_day"
  ]
}

Raport de 28 de zile la nivel de organizație

Raportul pe 28 de zile ajută la identificarea tiparelor de adoptare mai ample și a schimbărilor de utilizare pe termen mai lung. Comenzile sunt foarte similare, cu o mică modificare pentru a folosi API-ul de 28 de zile.

Exemplu de cerere:

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

Vei primi un răspuns similar, cu excepția faptului că vor exista response_start_day și response_end_day.

Structura raportului la nivel de organizație

Rapoartele JSON atât pentru cel de o zi, cât și pentru cel de 28 de zile la nivel organizațional pot arăta astfel:

[
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  },
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 43,
    "slug": "backend"
  },
  {
    "user_id": 1002,
    "user_login": "hubot",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  }
]

După cum poți vedea, acest lucru îți oferă o privire de ansamblu asupra utilizatorilor dintr-o anumită organizație, a echipei lor și a etichetelor de echipă. 

Endpoint-uri la nivel de utilizator

Rapoartele la nivel de utilizator oferă o vizibilitate mai granulară a adoptării. Asta înseamnă că poți înțelege cum folosesc indivizii Copilot la un nivel foarte înalt.

Endpoint-urile comune includ:

• users-1-day

• users-28-day

• user-teams-1-day

Aceste rapoarte îi ajută pe administratori să identifice:

• Utilizatori foarte activi
• Echipe cu adoptare scăzută
• Oportunități de training
• Tendințe de utilizare la nivel de departament

Aceste cereri sunt foarte similare cu rapoartele de o zi și de 28 de zile la nivel de organizație; ele indică doar către un alt API.

Raport de o zi la nivel de utilizator

Exemplu de apel API users-1-day:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=DAY"

Raport de 28 de zile la nivel de utilizator

Exemplu de apel API users-28-day:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
   https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest

Raport de o zi la nivel user-teams

Există și un endpoint user-teams-1-day, care mapează fiecare utilizator la apartenențele sale de echipă. Nu conține metrici de utilizare în sine; scopul lui este să servească drept cheie de îmbinare atunci când vrei să agregi datele per utilizator pe echipă.

Structura raportului la nivel de utilizator

Nivelul de detaliu din aceste rapoarte este mult mai ridicat, dat fiind că indică către datele de utilizare ale unui anumit utilizator:

[{
  "code_acceptance_activity_count": 1,
  "code_generation_activity_count": 1,
  "day": "2025-10-01",
  "enterprise_id": "1",
  "loc_added_sum": 8,
  "loc_deleted_sum": 0,
  "loc_suggested_to_add_sum": 10,
  "loc_suggested_to_delete_sum": 0,
  "totals_by_cli": {
    "last_known_cli_version": {
      "cli_version": "1.0.8",
      "sampled_at": "2025-10-01T00:01:43.000Z"
    },
    "prompt_count": 2,
    "request_count": 2,
    "session_count": 2,
    "token_usage": {
      "avg_tokens_per_request": 4400.0,
      "output_tokens_sum": 5000,
      "prompt_tokens_sum": 3800
    }
  },
  "totals_by_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_ide": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "ide": "vscode",
    "last_known_ide_version": {
      "ide_version": "1.85.0",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "last_known_plugin_version": {
      "plugin": "",
      "plugin_version": "",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_language_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "language": "unknown",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0
  }],
  "totals_by_language_model": [],
  "totals_by_model_feature": [],
  "used_agent": false,
  "used_chat": false,
  "used_cli": true,
  "user_id": 1,
  "user_login": "login1",
  "user_initiated_interaction_count": 0,
  "etl_id": "green",
  "day_partition": "2025-10-01",
  "entity_id_partition": 1
}]

Aceste metrici sunt cele mai valoroase ca semnale de adoptare la nivel de echipă. Ratele de acceptare și numărătorile de utilizare sunt semnale operaționale, nu măsurători ale calității dezvoltatorilor.

Pentru setul complet de metrici pe care le-ai putea vedea, vizitează documentația despre datele de usage metrics de la GitHub pentru cele mai recente metrici măsurate.

Rapoartele la nivel de utilizator includ date despre interacțiunile CLI. Dacă echipele tale folosesc Copilot din linia de comandă, GitHub Copilot CLI Tutorial acoperă setarea și fluxurile de lucru comune.

Construirea unui flux de raportare pentru Copilot

Apelarea manuală a API-ului este utilă pentru experimentare și înțelegerea schemei. Ca să fie acționabil, e mai bine să creezi un flux automatizat.

Echipele care obțin cea mai mare valoare din Copilot Enterprise construiesc de obicei pipeline-uri de raportare ușoare, care combină telemetria de utilizare cu metrici interne de inginerie.

Metrici-cheie pentru a demonstra ROI

Nu toate metricile Copilot contează la fel de mult. Cele mai utile tind să includă:

• Creșterea utilizatorilor activi
• Tendințe ale ratelor de acceptare
• Cod sugerat versus cod păstrat
• Îmbunătățiri ale timpului de ciclu PR
• Frecvența de utilizare a IDE-ului

GitHub a publicat repere precum:

• Finalizarea sarcinilor cu 55% mai rapid
• Rate de păstrare a codului de 88%

Aceste cifre arată îmbunătățiri semnificative ale productivității. Rezultatele tale vor varia în funcție de echipă și fluxul de lucru, motiv pentru care există API-ul Usage Metrics. O echipă de infrastructură backend poate interacționa cu Copilot diferit față de o echipă de prototipare frontend.

De la date brute la un dashboard de echipă

Un flux de raportare ușor arată adesea așa:

1. Apel API programat
2. Stocarea răspunsurilor într-o bază de date sau într-un spreadsheet
3. Transformarea datelor în tabele de raportare
4. Vizualizarea metricilor într-o platformă BI existentă

Stack-ul în sine contează mai puțin decât consistența.

Chiar și un flux simplu cu scripturi Python programate și exporturi CSV poate oferi vizibilitate operațională utilă.

Arhitectură exemplu:

GitHub API

  ↓

Script Python programat

  ↓

PostgreSQL / CSV / Spreadsheet

  ↓

Power BI / Tableau / Looker

Concluzii finale

GitHub Copilot Enterprise înseamnă, în esență, să îți construiești infrastructura pentru cod pregătit pentru AI. Spaces oferă contextul organizațional care face Copilot mai util în medii reale de inginerie. API-ul Usage Metrics oferă telemetria necesară pentru a înțelege dacă adoptarea are succes.

Organizațiile care obțin cele mai bune rezultate din Copilot Enterprise tind să urmeze un tipar comun:

• Îngrijesc cu atenție contextul intern
• Monitorizează adoptarea în mod continuu
• Tratează cu seriozitate guvernanța Copilot
• Măsoară rezultatele în loc să presupună câștiguri de productivitate

Această mentalitate contează mult mai mult decât simpla alocare a locurilor.

Dacă vrei să îți aprofundezi abilitățile în Copilot și AI, îți recomand cursul nostru Software Development with GitHub Copilot sau întregul traseu de abilități AI for Software Engineering.