Integracje / Azure DevOps
Komunikacja, projekty i biuro
Integracja AI: Azure DevOps
Podłączamy Boards z Work Items, moduł Repos z Pull Requestami i Pipelines z logami uruchomień. Asystent tłumaczy stan sprintu na język biznesowy, pilnuje zaległych przeglądów kodu i składa notatki wydania z każdego wdrożenia.
Po prezentacji do 2 tygodni testów, z dostępem tego samego dnia. Płacicie dopiero po decyzji.
W skrócie
Jak asystent AI łączy się z systemem Azure DevOps?
Łączymy się przez REST API Azure DevOps pod adresem dev.azure.com/{organizacja}/{projekt}/_apis/ w wersji 7.x. Do uwierzytelnienia używamy Personal Access Token generowanego w ustawieniach konta, z uprawnieniami ograniczonymi do odczytu: Work Items Read, Code Read i Build Read.
- Na start potrzebujemy
- Personal Access Token z uprawnieniami Work Items Read, Code Read i Build Read
- Czego asystent nie robi
- Nie zatwierdza Pull Requestów ani nie uruchamia pipeline'ów bez decyzji człowieka z uprawnieniami w projekcie.
- Gdzie są dane
- Na Waszym serwerze. Zaczynamy od odczytu, zapis włączacie sami.
Dane z Azure DevOps w czacie i we własnym module
Pracujecie na dwa sposoby. W czacie pytacie o cokolwiek z programu i dostajecie odpowiedź na Waszych danych. Do rzeczy, które wracają co dzień, budujemy w portalu osobne narzędzie: Sprint i Work Items z Azure DevOps. Moduł zbiera bieżące zadania z Azure Boards i pokazuje stan każdego Work Itema w aktywnym sprincie. Programista, tester i team leader widzą w jednym miejscu, co jest zablokowane, co czeka na przegląd i co można zamknąć, bez logowania do DevOps.
- Wyświetla Work Items z aktywnego sprintu według Area Path i przypisanej roli
- Flaguje zadania bez aktywności dłużej niż ustalony próg z datą ostatniej zmiany
- Łączy Work Item z otwartym Pull Requestem i stanem potoku CI/CD
- Grupuje postęp sprintu według obszaru i pokazuje procent ukończenia
- Generuje raport sprintu dla właściciela produktu po zamknięciu iteracji
Pytanie w czacie
Programista dostaje przyczynę awarii po polsku z numerem kroku, zanim otworzy interfejs Azure DevOps.
Dlaczego ostatni pipeline na branch main się wysypał? Musimy wiedzieć, co naprawić, zanim wejdziemy na produkcję.
Karta w narzędziu
Karta zadania łączy stan z Boards, powiązany PR i historię zmian w jednym widoku dla team leadera.
Aktywny sprint w jednym widoku: team leader widzi co jest zablokowane i co czeka, bez klikania w Azure DevOps.
Ekrany na danych przykładowych. Narzędzie dla Waszej firmy układamy pod Wasz sposób pracy: inne kolumny, inne progi, inne powiadomienia.
Co podłączamy
Zaczynamy od odczytu danych. Zapis i akcje w systemie Azure DevOps włączamy dopiero wtedy, gdy sami tego chcecie.
CzytamyID, State, Assigned To, Area Path, tagi oraz pełna historia zmian stanu z datami i osobami, które je wprowadzały
AsystentWykrywa zadania bez aktywności dłużej niż ustalony próg i informuje przypisaną osobę z dokładną datą ostatniej zmiany
CzytamyStatus każdego recenzenta (Approved, Waiting for Author, Rejected) i data jego ostatniej aktywności w projekcie
AsystentWyłapuje recenzentów nieaktywnych lub usuniętych z projektu i zgłasza ich w raporcie, zamiast pozwolić PR czekać bez końca
CzytamyKto lub co uruchomiło potok, czas startu, czas trwania oraz numer kroku i etapu, w którym potok się zatrzymał
AsystentZ pełnego logu wyodrębnia pierwszy błąd, exit code i krok zatrzymania, zwraca opis po polsku zanim programista otworzy interfejs
CzytamyLista commitów między tagami, tytuły scalonych Pull Requestów i powiązane Work Items przez wzmianki w opisach i commitach
AsystentSkłada notatkę wydania z opisem dla biznesu: co nowego, co naprawiono i środowisko docelowe, gotową minutę po deploymencie
CzytamyAktywne sprinty, przypisanie Work Items do sprintu oraz podział na obszary produktu przez pole Area Path
AsystentGrupuje zadania według obszaru i układa postęp sprintu w raport dla właściciela bez konieczności logowania do Azure
CzytamyGałąź źródłowa i docelowa PR, data otwarcia, data ostatniej aktywności w wątku komentarzy
AsystentIdentyfikuje PR-y otwarte do gałęzi produkcyjnej bez aktywności i wysyła alert do konkretnego recenzenta z godziną otwarcia
O co pytają w praktyce
Po polsku, jak koledze z pracy. Asystent odpowiada na danych z Waszego programu, a nie z ogólnej wiedzy.
- „Co weszło na produkcję w ostatnim tygodniu?”
- „Które Pull Requesty czekają na przegląd dłużej niż dobę?”
- „Dlaczego ostatni pipeline się wysypał i co trzeba sprawdzić?”
- „Co zamknęliśmy w tym sprincie, a co przechodzi na kolejny?”
Co się zmienia
Właściciel i menedżer produktu dostają raport ze stanu projektu zanim zapytają zespół, a team liderzy przestają tracić czas na ręczne zbieranie danych z trzech modułów.
Asystent działa na Waszym serwerze, na Waszych uprawnieniach. Każdy odczyt i każda akcja zostawiają ślad w logu. Program zostaje tam, gdzie jest, razem z historią danych i nawykami zespołu.
O programie
Azure DevOps to platforma Microsoftu do zarządzania pracą zespołów IT. Używają jej firmy, które rozwijają własne oprogramowanie albo zamawiają je na zewnątrz i chcą mieć wgląd w postęp. Dane trzymane są w chmurze Microsoftu (Azure DevOps Services) albo na serwerze firmy (Azure DevOps Server, dawniej Team Foundation Server).
Codzienna praca w Azure DevOps to: tworzenie i aktualizowanie zadań na tablicy Boards, otwieranie Pull Requestów z każdą zmianą w kodzie, przeglądanie wyników automatycznych wdrożeń w Pipelines. System produkuje dużo danych, ale interfejsy są zaprojektowane dla programistów, nie dla menedżerów, więc większość tych informacji zostaje nieodczytana.
Gdzie to działa najlepiej
właściciel firmy
Co poniedziałek właściciel pyta team leadera, co weszło na produkcję w ostatnim tygodniu i czy ostatnie wdrożenie się powiodło. Team leader spędza pół godziny na zbieraniu danych z Boards, Repos i historii pipeline'ów.
Z asystentem: W niedzielę o 23:00 automat odpytuje Azure DevOps i układa raport. W poniedziałek o 7:30 właściciel ma mail: co trafiło na produkcję, co jest w toku i czy deploy przebiegł bez błędów.
team leader IT
Programista otworzył Pull Request w piątek o 14:30. Recenzenci nie zaglądali przez weekend, PR leży zablokowany i wstrzymuje kolejne zadania. Team leader dowiaduje się o tym dopiero na porannym spotkaniu.
Z asystentem: Asystent codziennie rano sprawdza otwarte PR-y. Recenzent dostaje alert z numerem PR, godziną otwarcia i powiązanym zadaniem na Boards, zanim spotkanie się zacznie.
menedżer produktu
Przed wdrożeniem menedżer produktu chce wiedzieć, co dokładnie wchodzi na produkcję, żeby przygotować komunikację do klientów. Tytuły PR-ów takie jak 'fix: null pointer exception in invoice service' nic mu nie mówią.
Z asystentem: Asystent tłumaczy listę scalonych PR-ów i zamkniętych Work Items na język biznesowy i wysyła gotową notatkę wydania minutę po deploymencie, bez czekania na briefing zespołu.
Jak się łączymy
Łączymy się przez REST API Azure DevOps pod adresem dev.azure.com/{organizacja}/{projekt}/_apis/ w wersji 7.x. Do uwierzytelnienia używamy Personal Access Token generowanego w ustawieniach konta, z uprawnieniami ograniczonymi do odczytu: Work Items Read, Code Read i Build Read. Odpowiedzi przychodzą w JSON i trafiają do bazy portalu.
Portal z plikami, bazami i historią rozmów stoi na serwerze klienta. Skrypt odpytuje API w ustalonych odstępach, zapisuje zmiany do bazy i przekazuje do modelu AI polecenie oraz fragmenty danych potrzebne do odpowiedzi. Modele AI nie są trenowane na danych klienta. Tryb pracy to odczyt; dodanie komentarza do Pull Requesta wymaga osobnego potwierdzenia.
Czego potrzebujemy od Was
- Personal Access Token z uprawnieniami Work Items Read, Code Read i Build Read
- Konto w Azure DevOps z dostępem do wskazanego projektu (standardowy plan, bez dodatkowych licencji)
- Osoba po stronie firmy, która wygeneruje token i wskaże projekty oraz Area Path do integracji
- Adres e-mail lub kanał Teams do wysyłki raportów i alertów o zaległych Pull Requestach
- Przy Azure DevOps Server: adres serwera dostępny z sieci klienta i numer wersji API
Czego asystent nie robi
- Nie zatwierdza Pull Requestów ani nie uruchamia pipeline'ów bez decyzji człowieka z uprawnieniami w projekcie.
- Nie zmienia statusów Work Itemów, nie przypisuje zadań ani nie modyfikuje konfiguracji środowisk wdrożeń.
- Nie odczytuje secrets ani zmiennych środowiskowych używanych przez pipeline'y, bo API ich nie udostępnia.
- Nie zastępuje code review: wskazuje zaległe przeglądy i PR-y bez recenzenta, ale ocenę kodu robi programista.
Częste pytania
Czy możemy ograniczyć integrację do wybranych projektów lub sprintów?
Tak. Zakres ustala się przy konfiguracji: podajecie nazwy organizacji, projektów i Area Path, które mają trafiać do raportów. Reszta projektów w waszej organizacji Azure DevOps pozostaje poza zasięgiem asystenta.
Jak często asystent pobiera dane z Azure DevOps?
Domyślnie skrypt odpytuje API co godzinę i zapisuje tylko zmienione pozycje do bazy portalu. Raporty tygodniowe i alerty o zaległych Pull Requestach uruchamiają się o stałych godzinach. Częstotliwość można dostosować do rytmu pracy zespołu.
Czy integracja obejmuje też pracę zewnętrznych wykonawców w naszym projekcie?
Asystent widzi wszystko, do czego ma dostęp wygenerowany token. Jeśli zewnętrzny wykonawca pracuje w tym samym projekcie Azure DevOps, jego Work Items i Pull Requesty będą widoczne. Zakres dostępu ustalacie przy konfiguracji tokenu PAT.
Co jeśli firma prowadzi kilka projektów w Azure DevOps?
Każdy projekt wymaga osobnego tokenu PAT z uprawnieniami do tego projektu. Integracja może działać równolegle na kilku projektach. Raporty można składać osobno dla każdego projektu albo łączyć w jeden widok zbiorczy dla właściciela.
Jak zaczynamy
- Bezpłatna prezentacja. Mówicie, na czym pracujecie i co Was korkuje. Mówimy wprost, czy da się to spiąć, a jeśli nie ma czego automatyzować, też to powiemy.
- Do 2 tygodni testów. Dostęp do portalu tego samego dnia, podłączenie w trybie odczytu, sprawdzacie na własnych danych.
- Rozszerzanie. Kolejne moduły i akcje dokładamy, gdy zespół ufa temu, co dostaje. W abonamencie jest wdrożenie, integracja, szkolenie i opieka.
Inne programy: komunikacja, projekty i biuro
Azure DevOps 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.