Przejdź do głównej zawartości

Integracje

Q247 sam nie generuje danych. Wszystko, co widać na dashboardach, pochodzi z systemów, które już działają u Klienta: repozytoriów kodu, Jiry, Confluence, dostawcy tożsamości. Ta część Konfiguracji odpowiada za połączenia z nimi.

Integracje dzielą się na trzy grupy o różnym charakterze. Pierwsza dostarcza dane o pracy i bez niej platforma jest pusta. Druga dotyczy kont i logowania i jest opcjonalna, bo organizacja może zarządzać kontami ręcznie. Trzecia obsługuje funkcje AI: przyjmuje dane o korzystaniu z narzędzi AI i udostępnia model językowy Asystentowi AI.

Integracje dostarczające dane​

IntegracjaCo wnosiKiedy jest potrzebna
Konektorycommity i historia repozytoriów, z których liczone są Kalorie, Przyrosty i Liniezawsze, to podstawa działania Q247
Jirahistoria zmian statusów ticketówgdy organizacja chce mierzyć Czas realizacji i Czas cyklu
Confluencewysiłek wkładany w dokumentacjęgdy dokumentacja jest istotną częścią pracy zespołu
Azure Boardspraca na work itemach Azure DevOpsgdy organizacja prowadzi zadania w Azure DevOps Server zamiast w Jirze albo obok niej
Azure Wikiwysiłek wkładany w dokumentację w Azure DevOpsgdy dokumentacja mieszka w wiki Azure DevOps Server

Konektory to podkategoria: jeden konektor odpowiada jednemu systemowi kontroli wersji, a Q247 obsługuje siedem typów, od GitLaba i GitHuba po repozytoria dodawane ręcznie.

Azure Boards i Azure Wiki dzielą jedną kartę integracji, przełączaną polem zakresu danych. Podłączenie drugiego z tych źródeł sprowadza się do zaznaczenia dodatkowego pola, bez ponownego podawania poświadczeń. Obie strony opisują pełną procedurę, więc wystarczy otworzyć tę, która dotyczy podłączanego źródła.

Uruchomienie analizy kodu to przewodnik po całym procesie od utworzenia konektora do pojawienia się danych na dashboardzie.

Punkt startowy przy wdrożeniu od zera

Kolejność czynności jest ważniejsza niż szczegóły pojedynczych pól. Objaw pominięcia jednego z kroków wygląda identycznie jak awaria integracji: konektor pokazuje status Operacyjny, a dashboardy są puste.

Integracje tożsamościowe​

Te dwie obsługują różne rzeczy i wdraża się je niezależnie.

IntegracjaZa co odpowiadaCzego nie robi
SSO (OIDC)logowanie przez zewnętrznego dostawcę tożsamościnie tworzy kont
Provisioning SCIMzakładanie, aktualizowanie i dezaktywowanie kont oraz zespołównie ma wpływu na sposób logowania

Można wdrożyć jedną z nich, obie albo żadną. Przy obu naraz dostawca tożsamości zakłada konta, a użytkownicy logują się bez hasła po stronie Q247. Przy samym SSO konta trzeba założyć ręcznie, inaczej logowanie nie znajdzie ich odpowiednika w Q247.

Integracje funkcji AI​

Obie są opcjonalne i niezależne od siebie, a każda obsługuje inną funkcję AI.

IntegracjaZa co odpowiadaKierunek danych
Logi narzędzi AIodbiór telemetrii z narzędzi AI, w tym Claude Codedo Q247
Model językowymodel obsługujący Asystenta AIz Q247 do modelu

Pierwsza z nich zasila liczby w Adopcji AI, druga odpowiada za odpowiedzi Asystenta AI. Adopcja AI działa też bez telemetrii, opierając się wtedy na adnotacjach w wiadomościach commitów.

Czynności poza Q247​

Integracje to jedyna część Konfiguracji, która wymaga czynności w innych systemach. W zależności od zakresu wdrożenia będzie potrzebna pomoc osób z odpowiednimi uprawnieniami:

  • administrator systemu kontroli wersji: konto serwisowe i token z prawem odczytu do repozytoriów objętych analizą,
  • administrator Jiry albo Confluence: jednorazowo, do zainstalowania aplikacji Q247 (wersje chmurowe) albo zarejestrowania webhooka (Data Center), gdy konektor pobiera dane webhookami (Jira, Confluence),
  • administrator dostawcy tożsamości: rejestracja aplikacji dla SSO albo konfiguracja konektora SCIM,
  • zespół sieciowy: przy wdrożeniach, w których wtyczka działa w infrastrukturze Klienta.

Każda strona integracji ma własną sekcję wymagań wstępnych z konkretną listą.

Podstrony​

Zobacz też​