Integracje / GitHub / GitLab
Integracja AI z GitHub / GitLab
Podłączamy repozytoria przez token API read-only i czytamy issues, merge requesty, pipeline CI/CD oraz logi deploymentów. Asystent przekłada wiadomości commitów na język polski i wysyła cotygodniowy raport do właściciela bez otwierania repozytorium.
Rozmowa trwa 15 minut. Dzwonimy my, nic nie trzeba instalować.
Po rozmowie dwa tygodnie za darmo. Jeśli uznamy, że u Was to ma sens, uruchamiamy Wam własną platformę podłączoną pod GitHub / GitLab. Bez umowy i bez karty.
Czym jest GitHub / GitLab
GitHub i GitLab to platformy, na których zespoły programistyczne trzymają kod źródłowy, zgłaszają błędy, planują zmiany i wdrażają oprogramowanie na serwery. Korzystają z nich firmy rozwijające własne produkty cyfrowe, software house'y i działy IT prowadzące wewnętrzne systemy. Codzienna praca odbywa się przez zgłoszenia (issues), przeglądy kodu (code review) i automatyczne pipeline'y uruchamiane przy każdej zmianie.
Oba systemy udostępniają REST API i GraphQL API. Dane leżą na serwerach GitHub lub GitLab, ale GitLab można też zainstalować na własnym serwerze firmy, co oznacza, że kod i historia nigdy nie opuszczają wewnętrznej infrastruktury. W repozytorium gromadzą się miesiące albo lata danych o zgłoszeniach, commitach i wdrożeniach. Większość firm nigdy nie zebrała ich w całość dla zarządu.
Co podłączamy w GitHub / GitLab
- Issues: tytuły, etykiety bug/feature/critical, assignee i status open/closed
- Merge requesty: autor, status recenzji, lista zmienionych plików
- Pipelines CI/CD: etapy build/test/deploy, wyniki testów, status passed/failed
- Deployments: środowisko docelowe, kto uruchomił, kiedy i do której wersji kodu
- Releases i tagi wersji: numer wersji, data publikacji, opis do notatki wydania
Zakres ustalamy pod Was. Zaczynamy od odczytu danych, a zapis i akcje włączamy dopiero wtedy, gdy sami tego chcecie.
O co pytają w praktyce
Pytania zadaje się po polsku, jak koledze z pracy.
„Co nowego weszło do produktu w ostatnich 7 dniach?"
„Które zgłoszenia od klientów czekają bez przypisanej osoby ponad 5 dni?"
„Czy ostatnie wdrożenie na produkcję przeszło wszystkie etapy testów?"
„Jakie błędy naprawiono od czasu poprzedniego wydania?"
Co dokładnie podłączamy w GitHub / GitLab
Obszar po obszarze: jakie dane czytamy i co asystent z nich robi. To lista z realnego wdrożenia, nie katalog możliwości.
Czytamytytuł, opis, etykiety, przypisana osoba, data otwarcia, status open/closed i komentarze do zgłoszenia
Asystentwykrywa zgłoszenia krytyczne bez reakcji ponad 24 godziny i zaległe bez assignee, wysyła alert do managera zanim zadzwoni klient
Czytamyautor, lista recenzentów, status recenzji (approved, changes requested, pending) i lista zmienionych plików
Asystentflaguje przeglądy kodu czekające na zatwierdzenie ponad 3 dni, które blokują wejście zmiany na serwer produkcyjny
Czytamywiadomość commita, autor, data i lista zmienionych ścieżek plików w danej zmianie kodu
Asystentprzekształca techniczne opisy commitów na zrozumiały dla właściciela opis zmian w produkcie, pisany po polsku bez żargonu
Czytamyetapy build/test/deploy, wyniki testów z podziałem na przejścia i niepowodzenia, status i czas trwania pipeline'u
Asystentwykrywa wdrożenia na produkcję bez powiązanego pipeline'u lub z wynikiem failed i generuje natychmiastowy alert do managera
Czytamyśrodowisko docelowe (staging, production), kto uruchomił, kiedy, do której wersji kodu i czy poprzedzał go pipeline
Asystentporównuje każde wdrożenie z wynikiem pipeline'u i alarmuje, gdy deploy ominął testy lub poszedł z gałęzi bez code review
Czytamynumer wersji, data publikacji, opis wydania, commity od poprzedniego tagu i powiązane issues z milestone'u
Asystentgeneruje gotową notatkę wydania po polsku z opisem zmian widocznych dla użytkownika, z pominięciem refaktoryzacji i zmian wewnętrznych
Co się zmienia
Właściciel dostaje w piątek czytelny raport o stanie projektu bez jednego pytania do programistów, a zaległe zgłoszenia przestają się gubić.
Asystent stoi na Waszym serwerze i łączy się z GitHub / GitLab na Waszych uprawnieniach. Dane nie wychodzą do zewnętrznych usług, a każdy odczyt i każda akcja zostawiają ślad w logu. Zakres uprawnień ustalacie Wy, więc asystent widzi dokładnie tyle, ile ma widzieć.
Nie wymieniamy Wam programu i nie zmuszamy nikogo do zmiany nawyków. GitHub / GitLab zostaje tam, gdzie jest, razem z historią danych i przyzwyczajeniami zespołu.
Jak łączymy się z GitHub / GitLab
Łączymy się przez REST API i GraphQL API obu platform. W GitHubie generujemy Personal Access Token lub Fine-grained Token z zakresami repo i read:org. W GitLabie używamy Project Access Token albo Group Access Token z zakresem read_api. Token ma wyłącznie uprawnienia do odczytu, więc asystent pobiera dane i nie wprowadza żadnych zmian w repozytorium.
Przy GitLabie zainstalowanym na własnym serwerze firmy token wskazuje na wewnętrzny adres i dane nie opuszczają infrastruktury klienta. Oprócz cyklicznego odpytywania API obsługujemy webhooki: GitHub i GitLab mogą wysłać powiadomienie natychmiast po każdym zdarzeniu, co przyspiesza alerty o wdrożeniach na produkcję czy krytycznych zgłoszeniach bez czekania na zaplanowany cykl.
Czego potrzebujemy od Was
- Token API read-only: GitHub (zakresy repo, read:org) lub GitLab (zakres read_api)
- Lista repozytoriów lub grup projektów do monitorowania wraz z wybranym harmonogramem sprawdzania
- Wybór kanału powiadomień: e-mail, Slack, Microsoft Teams lub wewnętrzny panel redAi
- Osoba po stronie firmy, która potwierdzi zakres monitorowania i odbierze pierwsze raporty
- Przy GitLabie self-hosted: adres wewnętrznego serwera dostępny z naszej infrastruktury
Gdzie to działa najlepiej
Właściciel firmy
Co piątek właściciel firmy rozwijającej własną platformę chce wiedzieć, co zmieniło się w produkcie. Dotychczas dowiadywał się o tym z rozmów przy kawie albo ze sprint review, na których nie rozumiał połowy slajdów.
Z asystentem: Dostaje na e-mail jedno zwięzłe podsumowanie po polsku: co naprawiono, co weszło jako nowa funkcja, które wdrożenie trafiło na produkcję. Nie musi nic pytać ani otwierać repozytorium.
Manager lub team lead
Krytyczne zgłoszenie od klienta leży w issue trackerze od ponad doby bez komentarza i bez przypisanego programisty. Manager nie wie, bo nikt mu nie powiedział, a programiści skupiają się na nowych zadaniach.
Z asystentem: Asystent wysyła alert z listą zaległych zgłoszeń krytycznych. Manager widzi problem i może reagować, zanim klient zadzwoni z pretensjami o brak odpowiedzi.
Dyrektor techniczny lub właściciel
Programista ręcznie uruchamia deployment na środowisko produkcyjne w piątek po 16:00, pomijając standardowy pipeline CI/CD z testami. Nikt nie zauważa, że etap testów nie przeszedł i że kod wchodzi na produkcję bez weryfikacji.
Z asystentem: Asystent wykrywa brak powiązanego pipeline'u z wynikiem passed i wysyła alert do managera. Firma ma szansę zareagować przed zgłoszeniem awarii przez użytkowników w poniedziałek.
Jak to uruchamiamy
- Rozmowa 15 minut. Mówicie, na czym pracujecie i co Was korkuje. Mówimy, czy da się to spiąć.
- Podłączenie i pierwsze pytania. Zaczynamy od odczytu, na Waszym serwerze, w zakresie który zatwierdzacie.
- Rozszerzanie. Dokładamy kolejne moduły i akcje, gdy zespół już ufa temu, co dostaje.
Koszt: od 3 000 zł miesięcznie. W tym wdrożenie, integracja, szkolenie zespołu i opieka. Widełki na Wasz przypadek podajemy na tej pierwszej rozmowie, bez ofert na dwadzieścia stron.
Chcecie najpierw poczytać konkrety: jakie moduły ruszamy, jakie dane bierzemy i czego potrzebujemy po Waszej stronie?
Cały opis integracji z GitHub / GitLab →Czego asystent nie robi
Żebyście wiedzieli, gdzie kończy się jego rola, zanim zaczniecie.
- Asystent nie tworzy, nie zamyka ani nie edytuje issues i merge requestów w repozytorium.
- Asystent nie blokuje deploymentów ani nie naprawia kodu: widzi wzorzec i zgłasza go człowiekowi do decyzji.
- Asystent nie przypisuje zadań programistom ani nie wysyła do nich wiadomości bezpośrednio.
- Asystent nie zastępuje code review: nie ocenia jakości kodu ani nie zatwierdza zmian w repozytorium.
Pytania o integrację z GitHub / GitLab
Jak szybko po podłączeniu pojawią się pierwsze użyteczne raporty?
Pierwsze sensowne wyniki pojawiają się po kilku dniach, gdy asystent zebrał historię z kilku cykli i może porównywać tygodnie. Na starcie warto zadać jednorazowe pytanie: podsumuj ostatnie 30 dni w repozytorium X. To od razu pokazuje, czy dane nadają się do automatycznych podsumowań.
Czy monitorowanie działa, gdy mamy kilkanaście repozytoriów w różnych projektach?
Tak. Określasz, które repozytoria lub grupy projektów mają być monitorowane. Można wybrać wszystkie naraz albo ograniczyć się do konkretnych. Przy GitLabie możesz wskazać całą grupę projektów jednym tokenem na poziomie grupy, bez konfigurowania każdego repozytorium osobno.
Czy mogę dostać alert od razu, gdy coś pójdzie nie tak, a nie czekać do piątkowego raportu?
Tak. Oprócz cyklicznych raportów obsługujemy webhooki: GitHub i GitLab wysyłają powiadomienie natychmiast po zdarzeniu, takim jak nowe wdrożenie na produkcję czy otwarcie zgłoszenia z etykietą critical. Alert trafia do managera w minutach, bez czekania na koniec tygodnia.
Czy raport można dostosować do tego, co mnie interesuje jako właściciela?
Tak. Możesz określić, które obszary chcesz widzieć w raporcie i z jaką częstotliwością. Na przykład właściciel może dostawać piątkowe podsumowanie z naciskiem na wdrożenia i nowe funkcje, a team lead codzienne alerty o zaległych zgłoszeniach i blokadach code review.
Piętnaście minut o GitHub / GitLab
Wybierzcie termin z kalendarza. Na rozmowie powiemy wprost, co da się u Was podłączyć, ile to trwa i ile kosztuje. Jeśli nie ma czego automatyzować, też to powiemy. A jeśli ma, dostajecie 14 dni działającej platformy podłączonej pod GitHub / GitLab, żeby sprawdzić to na własnych danych zamiast wierzyć nam na słowo.
Komunikacja, projekty i biuro
GitHub / GitLab jest znakiem towarowym swojego właściciela. Nie jesteśmy z nim powiązani ani przez niego autoryzowani. Nazwy używamy wyłącznie po to, żeby wskazać, z jakim programem integrujemy asystenta.