Jak AI pilnuje kodu, zadań i wdrożeń w Azure DevOps i Bitbucket?

Tak, AI można podłączyć do Azure DevOps i do Bitbucket. Oba systemy mają otwarte REST API, które pozwala wyciągać Work Items z tablic zadań, stan Pull Requestów, wyniki uruchomień potoku i historię wdrożeń. Z tych danych AI robi coś, czego brakuje w każdym zespole IT: tłumaczy techniczny stan projektu na język zrozumiały dla właściciela, przypomina o Pull Requestach czekających na przegląd i składa notatki wydania, zanim ktokolwiek zdąży zapytać.

Czym są Azure DevOps i Bitbucket z perspektywy właściciela firmy?

Programiści używają tych systemów do trzech podstawowych rzeczy. Pierwsza to śledzenie pracy. Każde zadanie, poprawka albo nowa funkcja to osobny rekord z przypisaną osobą, priorytetem i terminem. W Azure DevOps ta lista nazywa się Boards, a poszczególne wpisy to Work Items z polami: State (New, Active, Resolved, Closed), Assigned To, Sprint i Area Path. W Bitbucket zadania żyją najczęściej po stronie Jiry, która jest z nim wpięta przez natywną integrację.

Druga rzecz to przechowywanie i przeglądanie kodu. W Azure DevOps to moduł Repos, w Bitbucket cała platforma jest zbudowana wokół repozytoriów Git. Każda zmiana w kodzie przechodzi przez Pull Request: programista zgłasza zmiany, inni przeglądają je i zatwierdzają albo odsyłają do poprawy. Bez zatwierdzenia zmiana nie trafia do głównej gałęzi. Prosta zasada, ale jej pilnowanie bywa ciężkie przy kilkunastoosobowym zespole.

Trzecia rzecz to automatyczne wdrażanie. W Azure DevOps to moduł Pipelines: po każdej zatwierdzonej zmianie automat buduje aplikację, uruchamia testy i wgrywa ją na odpowiedni serwer. W Bitbucket analogiczna usługa to Bitbucket Pipelines. Każde uruchomienie ma status: succeeded, failed lub running. Gdy potok się wysypie, w logach zostaje szczegółowy ślad tego, co poszło nie tak. I tu zaczyna się problem: logi mają kilkaset linii, a przyczyna chowa się gdzieś na końcu.

Dla właściciela firmy ważne jest jedno. Te systemy produkują bardzo dużo danych. Status każdego zadania, kto co robi, co czeka na przegląd, co zostało wdrożone ostatniej nocy. Dane leżą w interfejsach zaprojektowanych dla programistów, nie dla menedżerów, i bez AI praktycznie nikt spoza IT ich nie czyta.

Jak wygląda podłączenie: API, tokeny i co producent udostępnia

Oba systemy mają dobrze udokumentowane REST API. Azure DevOps udostępnia je pod adresem dev.azure.com/{organizacja}/{projekt}/_apis/ w kilkunastu wersjach (aktualnie 7.x). Bitbucket Cloud działa pod api.bitbucket.org/2.0/, a Bitbucket Data Center (instalacja on-premise na własnym serwerze firmy) pod adresem {adres-serwera}/rest/api/1.0/. Odpowiedzi przychodzą w JSON.

Do uwierzytelnienia w Azure DevOps używamy Personal Access Token (PAT): generuje się go w ustawieniach swojego konta, z uprawnieniami ograniczonymi tylko do odczytu. Konkretnie: Work Items Read, Code Read i Build Read. Token działa jak klucz do konkretnej organizacji w Azure. W Bitbucket Cloud odpowiednikiem jest App Password albo token OAuth. Bitbucket Data Center ma własny mechanizm tokenów, analogiczny do Azure.

Co producent udostępnia, a czego nie? Azure DevOps REST API jest wyjątkowo kompletne. Przez API można odczytać Work Items z całą historią zmian stanu, Pull Requesty z listą zmienionych plików i wszystkimi komentarzami, logi z każdego kroku Pipeline run, konfigurację środowisk wdrożeń (Environments) i artefakty. Bitbucket Cloud ma nieco węższe API: Pull Requesty, statusy buildów, zawartość repozytoriów. Pełne logi z Pipelines w wersji Cloud są dostępne, ale z ograniczeniami stronicowania. Bitbucket Data Center ma pełniejsze API od wersji chmurowej.

Jedne dane w żadnym systemie nie są dostępne przez API: secrets i zmienne środowiskowe używane przez potoki wdrożeń. I dobrze, bo AI nie ma żadnego powodu, żeby je odczytywać.

Jakie konkretne dane wyciągamy i jak je przygotowujemy dla AI?

Zanim wejdziemy w zastosowania, warto być konkretnym co do danych. Oto co AI realnie dostaje:

• Z Azure Boards: ID Work Itemu, tytuł, opis, State, Assigned To, Sprint, Area Path, tagi, historia zmian stanu z datami i osobami, pola Created Date i Changed Date.
• Z Pull Requestów: tytuł, opis, lista zmienionych plików z liczbą dodanych i usuniętych linii, przypisani recenzenci i ich statusy (Approved, Waiting for Author, Rejected), wszystkie komentarze z datami i autorami, data otwarcia i data ostatniej aktywności, gałąź źródłowa i docelowa.
• Z Pipeline runs: nazwa potoku, trigger (kto albo co go uruchomiło), status (succeeded, failed, partially succeeded, canceled), czas startu, czas trwania, logi z poszczególnych kroków i etapów, komunikaty błędów z exit codeami.
• Z wydań i tagów: lista commitów między poprzednim a bieżącym tagiem, tytuły i opisy scalonych Pull Requestów, powiązane Work Items przez wzmianki w opisach PR i commitach.

Typowo wygląda to tak, że skrypt co godzinę odpytuje API o stan aktywnych sprintów i otwartych Pull Requestów, zapisuje wynik do bazy, a AI dostaje zestawienie tylko zmienionych pozycji. Nie ma sensu analizować sto razy czegoś, co się nie ruszyło od poprzedniego odpytania.

Co konkretnie robi AI z tymi danymi: cztery zastosowania, które wracają

Streszczenie wydania dla biznesu. Przed każdym wdrożeniem programiści scalają kilkanaście Pull Requestów. Ich tytuły wyglądają zwykle tak: "fix: null pointer exception in invoice service" albo "feat: add retry logic for payment gateway timeout". Dla programisty jasne. Dla właściciela firmy albo menedżera produktu: szum. AI dostaje listę scalonych PR-ów, powiązanych Work Items i ostatnich commitów, a zwraca trzy zdania zrozumiałe dla kogoś spoza IT: co nowego dostaje użytkownik, co zostało naprawione i czy jest coś, na co warto zwrócić uwagę po wdrożeniu. Taki raport trafia mailem do menedżera produktu minutę po deploymencie, bez czekania na briefing zespołu.

Pilnowanie Pull Requestów bez przeglądu. U jednego klienta mieliśmy sytuację, w której programista otwierał PR w piątek po południu. Recenzenci nie patrzyli w weekend, PR leżał bez zmian i blokował kolejne zadania. AI sprawdza codziennie rano: który PR jest otwarty dłużej niż 24 godziny, kto jest przypisany jako recenzent i kiedy ostatnio był aktywny w systemie. Wynik idzie do konkretnej osoby na Teams. Nie "mamy zaległości w przeglądach". Tylko: "Piotr, czeka na Ciebie PR #247 od wczoraj 14:30, powiązany z zadaniem PROJ-891".

Tłumaczenie błędów z potoku. Log z nieudanego pipeline potrafi mieć kilkaset linijek. Gdzie szukać przyczyny? AI dostaje pełny log, wyodrębnia fragment z pierwszym błędem: exit code, wyjątek, krok, w którym potok się zatrzymał, pomija szum i zwraca opis po polsku. Programista dostaje diagnozę: co dokładnie się wysypało, w którym kroku, co to prawdopodobnie oznacza i jakie są pierwsze rzeczy do sprawdzenia. Zanim zdąży otworzyć interfejs Azure.

Notatki wydania. Każde większe wdrożenie wymaga dokumentacji: co weszło, co naprawiono, kto zatwierdzał. AI składa to z danych API: commitów między tagami, scalonych PR-ów, zamkniętych Work Items z odpowiednim Area Path i informacji o środowisku docelowym (staging, production). Gotowy dokument w formacie Markdown albo HTML idzie do wiki projektu albo do systemu zgłoszeń, zanim ktokolwiek o to poprosi.

Jak to wygląda u firmy rozwijającej własny produkt SaaS?

Firma zajmuje się własnym oprogramowaniem dla branży logistycznej. Kilkanaście osób w IT, Azure DevOps od lat. Problem był konkretny: właściciel co poniedziałek pytał team leadera, co weszło w ostatnim tygodniu i co czeka na wdrożenie. Team leader spędzał na przygotowaniu odpowiedzi pół godziny, bo dane były rozsiane między Boards, Repos i historią pipeline'ów.

Po integracji wygląda to inaczej. W niedzielę o 23:00 automat odpytuje Azure DevOps: Work Items zamknięte w mijającym sprincie, Pull Requesty scalone w ostatnich 7 dniach, ostatnie uruchomienie potoku produkcyjnego ze statusem i logiem. AI dostaje te dane i układa raport: co trafiło na produkcję, co jest w stanie Active na Boards, czy ostatni deploy przebiegł bez błędów, a jeśli nie, to co się wysypało i czy to zostało już naprawione. W poniedziałek o 7:30 właściciel ma mail. Jedno pytanie tygodniowe zniknęło z agendy team leadera.

Przy okazji odkryliśmy, że kilka Pull Requestów miało recenzentów przypisanych błędnie: osoby, które odeszły z firmy albo były na urlopie. AI wyłapała to z danych o aktywności użytkowników i zgłosiła jako część raportu tygodniowego. Nikt nie sprawdzał tego ręcznie przez rok.

Na co uważać przy tej integracji?

Kilka rzeczy, z którymi się spotykamy przy wdrożeniu:

• Wygaśnięcie Personal Access Token. PAT w Azure DevOps ma termin ważności ustawiany przy generowaniu. Gdy wygaśnie, integracja cicho przestaje działać. Warto od razu ustawić monitoring: gdy token wygaśnie albo wywołanie API zwróci status 401, automat wysyła alert zamiast milczeć.
• Szum zamiast sygnału. Jeśli AI raportuje każdą zmianę statusu każdego Work Itemu każdemu z zespołu, ludzie przestają czytać raporty po tygodniu. Lepiej zacząć od jednego konkretnego pytania i jednego odbiorcy, zamiast wysyłać wszystkim wszystko.
• Różnica między Bitbucket Cloud a Data Center. Firmy, które mają Bitbucket Server (starszy) albo Data Center na własnym serwerze, trafiają na inne adresy API i inne ograniczenia niż przy Bitbucket Cloud. Przed budowaniem integracji warto sprawdzić u administratora IT, z której wersji faktycznie korzystacie.
• Logi pipeline'ów mogą zawierać wrażliwe dane. Log z pipeline'u może zawierać fragmenty zmiennych środowiskowych albo nazwy baz danych wypisane przez skrypty budowania. AI dostaje logi w celach diagnostycznych, nie do archiwizacji i nie do przesyłania na zewnątrz.
• Bitbucket Cloud i Jira to dwa osobne API. Jeśli Waszy programiści trzymają zadania w Jirze podpiętej do Bitbucketa, połączenie z samym Bitbucketem nie da dostępu do Work Items. Zadania trzeba wyciągać przez Jira REST API osobno.

Od czego zacząć, jeśli Wasza firma używa Azure DevOps lub Bitbucket?

Pierwsza rzecz: sprawdzić dostęp do API. W Azure DevOps wejdźcie w ustawienia swojego konta, wybierzcie Personal Access Tokens, wygenerujcie nowy z uprawnieniami Read dla Build, Code i Work Items. W Bitbucket Cloud: Personal Settings, App Passwords, Repositories Read i Pull Requests Read. To kilka minut i nie wymaga uprawnień administratora całej organizacji.

Druga rzecz: zdecydować, co monitorować jako pierwsze. Zaległe Pull Requesty to dobry punkt startowy: efekt widać szybko i jest mierzalny. Jedno wywołanie API raz dziennie, jeden raport z listą PR-ów starszych niż 24 godziny i recenzentami przypisanymi do każdego.

Trzecia rzecz: nie próbować podłączyć wszystkiego od razu. Lepiej mieć jeden raport, który ktoś czyta codziennie, niż pięć, które trafiają do folderu ignorowanego. Work Items, Pipelines, Repos, Environments: to dużo danych i łatwo zbudować system, który produkuje szum zamiast sygnałów.

Jeśli chcecie zobaczyć, jak taka integracja może wyglądać dla Waszego projektu, zarezerwujcie 15 minut rozmowy z naszym zespołem. Możemy pokazać realne wdrożenia, w których podobne połączenia już pracują od miesięcy.