Wdrożenia CI/CD
Q247 zbiera historię wdrożeń z potoków CI/CD. Pobierają ją te same konektory repozytoriów, które dostarczają commity. Korzystają przy tym z tokenu zapisanego w konektorze, więc zbieranie nie wymaga osobnego formularza. Po stronie Klienta trzeba sprawdzić uprawnienia tokenu, a przy Private Plugin także wersję i plik konfiguracyjny wtyczki.
Na podstawie tych danych w kolejnym wydaniu zostaną udostępnione metryki DORA: Częstotliwość wdrożeń, Czas wdrożenia zmian, Odsetek wdrożeń powodujących awarie i Czas przywrócenia działania.
Obsługiwane platformy
| Platforma | Źródło wdrożeń | Obsługiwane instalacje |
|---|---|---|
| GitLab | GitLab CI/CD | gitlab.com i instancje własne |
| GitHub | GitHub Actions i pozostałe wdrożenia rejestrowane w API GitHuba | github.com i GitHub Enterprise Server |
| Azure DevOps | YAML Pipelines i Environments | Azure DevOps Services oraz Azure DevOps Server 2020 i nowszy |
| Bitbucket | Bitbucket Pipelines | wyłącznie Bitbucket Cloud |
W Azure DevOps wdrożeniem jest uruchomienie zadania, które deklaruje środowisko (Environment, w YAML klucz environment:). Zadania bez zadeklarowanego środowiska nie zostawiają w Azure DevOps historii wdrożeń, więc wtyczka ich nie zbiera.
Klasyczne potoki Release Management w Azure DevOps nie są obsługiwane, podobnie jak Bitbucket Data Center i Server. Konektory Gitea, Gerrit i Generic GIT nie dostarczają danych o wdrożeniach.
Zakres danych o wdrożeniu
Dla każdego wdrożenia wtyczka pobiera:
- nazwę środowiska i status wdrożenia,
- wdrożony commit, gałąź albo tag, z którego pochodzi, oraz wersję, jeśli jest dostępna,
- czas rozpoczęcia i zakończenia oraz link do wdrożenia w systemie źródłowym,
- nazwę potoku,
- e-mail albo login konta, które uruchomiło wdrożenie (często jest to konto CI),
- przy wdrożeniu zakończonym powodzeniem listę identyfikatorów commitów objętych wdrożeniem.
Zdarzenie wdrożenia nie zawiera kodu źródłowego, diffów, wiadomości commitów, logów potoków, zmiennych ani sekretów. Wiadomości commitów Q247 dostaje osobno, w zdarzeniach commitów. Pełną listę pól obu rodzajów zdarzeń zawiera Bezpieczeństwo Enterprise Plugin.
Wdrożenia są zbierane tylko z repozytoriów przypisanych do projektu w Źródłach, a repozytoria bez projektu wtyczka pomija. Historię z ostatnich 365 dni wtyczka pobiera dla każdego repozytorium osobno, przy jego pierwszym przetworzeniu, a potem dociąga już tylko nowe wdrożenia. Repozytorium przypisane do projektu później również dostaje 365 dni wstecz, liczone od pierwszego przebiegu po przypisaniu.
Wdrożenia nie zmieniają Kalorii, a konto CI, które uruchomiło wdrożenie, nie staje się przez to użytkownikiem organizacji ani uczestnikiem projektu.
Uprawnienia tokenów
Zbieranie wdrożeń korzysta z tokenu zapisanego w konektorze. W części systemów token potrzebuje do tego zakresów, których sam konektor nie wymaga.
| Platforma | Wymagane uprawnienia | Zmiana względem konektora |
|---|---|---|
| GitLab | read_user, read_api i read_repository | bez zmian |
| GitHub, token klasyczny | repo | bez zmian |
| GitHub, token fine-grained | Contents, Deployments, Actions i Metadata, każde na poziomie Read-only | dochodzą Deployments, Actions i Metadata |
| Azure DevOps | Code (Read), Project and Team (Read), Build (Read) i Environment (Read & manage) | dochodzą Build (Read) i Environment (Read & manage) |
| Bitbucket Cloud | token API Bitbucket z uprawnieniami opisanymi na stronie BitBucket, w tym z odczytem Pipelines (zakres read:pipeline:bitbucket) | dochodzi odczyt Pipelines |
Bez uprawnienia Deployments wtyczka nie pobierze wdrożeń z GitHuba, a bez uprawnienia Actions pobierze je bez nazwy potoku.
Microsoft nie udostępnia dla środowisk zakresu tylko do odczytu, dlatego token musi mieć zakres Environment (Read & manage). Wtyczka korzysta z niego wyłącznie do odczytu środowisk i historii wdrożeń.
Wersja i konfiguracja wtyczki
Cloud Plugin utrzymuje Q247, więc po stronie Klienta wystarczą kroki 1 i 2 poniżej. Private Plugin wymaga wszystkich sześciu:
- Token w istniejącym konektorze. Jeśli tabela w Uprawnieniach tokenów podaje dla danej platformy nowe zakresy, wygeneruj token z tymi zakresami, otwórz konektor w Konfiguracji, w sekcji Wtyczki, przyciskiem „Edytuj”, wpisz nowy token i zapisz przyciskiem „Zapisz zmiany”.
- Repozytoria przypisane do projektu w Źródłach. Z repozytoriów bez projektu wdrożenia nie są zbierane.
- Wtyczka w wersji
q247-enterprise-plugin-linux-v2.7.9lub nowszej, pobrana przyciskiem „Plik wtyczki” w nagłówku sekcji Wtyczki (→ Pobranie plików). - Wpis
{ "code": "CICD" }w tablicyplugins.itemsplikuconfig.cfg. Sama aktualizacja pliku wtyczki nie włącza zbierania. Miejsce wpisu i przykład pokazuje Instalacja. - Ponowne uruchomienie wtyczki, bo
config.cfgjest wczytywany tylko przy starcie. Polecenie uruchomienia podaje Instalacja. - Sprawdzenie logu
q247-plugin.log: po starcie powinna się w nim pojawić liniaStarted addon CI/CD Deployments(→ Diagnostyka zbierania).
Moduł CICD łączy się z tymi samymi hostami systemów kontroli wersji co konektor repozytoriów, tylko z innymi ścieżkami ich API, więc istniejące reguły firewalla dla tych systemów wystarczają.
Plik konfiguracyjny pobierany z panelu zawiera już wpis CICD. Ma jednak ustawienia domyślne, więc zastąpienie nim dotychczasowego pliku usuwa wprowadzone w nim zmiany, w tym własne porty i sekcję ssl. Z tej drogi warto korzystać tylko wtedy, gdy plik nie był zmieniany po pobraniu.
Diagnostyka zbierania
Brak uprawnień do wdrożeń nie daje komunikatu w aplikacji ani nie zmienia statusu konektora. Konfigurację sprawdza się po stronie tokenu i wtyczki:
- Zakresy tokenu zgodne z tabelą w Uprawnieniach tokenów.
- Wersja wtyczki i wpis CICD (Private Plugin): wersja
q247-enterprise-plugin-linux-v2.7.9lub nowsza, wpis wplugins.itemsi ponowne uruchomienie po jego dopisaniu. - Log wtyczki
q247-plugin.log(Private Plugin), w którym moduł zostawia linie opisane w tabeli poniżej.
| Linia w logu | Znaczenie |
|---|---|
Started addon CI/CD Deployments | moduł CICD wystartował razem z wtyczką; brak tej linii po starcie oznacza brak wpisu CICD w plugins.items albo wtyczkę starszą niż q247-enterprise-plugin-linux-v2.7.9 |
CICD ingest for <konto>: ... | podsumowanie przebiegu: liczba nowych wdrożeń, przetworzonych repozytoriów, błędów i repozytoriów bez projektu |
CICD <konto>: error processing repo <adres> (poziom ERROR) | błąd pobierania wdrożeń z repozytorium, w tym odmowa dostępu przy brakującym zakresie tokenu |
CICD <konto>: skipping N repo(s) without a project assignment. | wtyczka pominęła repozytoria bez przypisanego projektu |
W miejscu <konto> log podaje identyfikator konta Q247, czyli organizacji w Q247. Nazwy konektora w tych liniach nie ma, a repozytorium wskazuje jego adres.
Zobacz też
- Konektory: wspólny formularz, uprawnienia tokenu, statusy
- GitLab, GitHub, Azure DevOps i BitBucket: generowanie tokenu w każdym z tych systemów
- Instalacja: pliki Private Plugin i wpis CICD w
config.cfg - Bezpieczeństwo Enterprise Plugin: pola wysyłane do Q247 i reguły firewalla