Projekty

To druga zakładka panelu Zarządzanie Organizacją: lista wszystkich projektów organizacji, z możliwością wejścia w szczegóły każdego z nich, żeby zarządzać jego źródłami danych, dodatkowymi regułami klasyfikacji i (opcjonalnie) własnymi granicami metryk przepływu.

Lista projektów

Kolumny: Projekt, Kierownicy projektu, Użytkownicy, Operacje. Kolumna Użytkownicy pokazuje osoby wykryte jako aktywne w projekcie na podstawie commitów i ticketów. Lista wypełnia się automatycznie.

Przycisk "Nowy projekt" tworzy pusty projekt, do którego dopiero trzeba przypisać źródło danych, żeby zaczął zbierać dane.

Menu "Operacje" przy każdym wierszu:

• Przypisz kierowników projektu: nadaje poziom dostępu Manager wskazanym osobom, patrz Uprawnienia.
• Przypisz źródło: podpina do projektu repozytorium albo integrację Jira/Confluence z listy Źródeł.
• Przypisz do zespołu: jeden projekt może być przypisany maksymalnie do jednego zespołu naraz. Menedżer tego zespołu automatycznie dostaje wtedy poziom Manager na projekcie.

Szczegóły projektu (Zarządzaj)

Kliknięcie nazwy projektu na liście otwiera jego szczegóły: trzy zakładki obok siebie, Źródła / Dodatkowe reguły / Metryki przepływu, oraz przycisk "Dodaj kierownika projektu" nad nimi.

Źródła

Zakładka pokazuje tabelę źródeł przypisanych do tego konkretnego projektu (Nazwa, Źródło danych, Interwał, Ostatnie skanowanie, Status, Operacje), z przyciskiem Przypisz źródło.

Formularz przypisania obsługuje trzy typy źródeł, wybierane w polu "Wybierz źródło danych":

Typ źródła	Co się podaje	Efekt
Zarządzanie kodem źródłowym	konkretne repozytorium z listy odkrytych przez konektor, interwał skanowania i strefa czasowa	repozytorium zostaje przypisane do projektu, opcjonalnie ze skanowaniem od razu
Jira	klucze projektów Jira, rozdzielone przecinkami, na przykład CORE, API, PAY	zdarzenia z tych projektów Jiry trafiają do tego projektu Q247
Confluence	klucze przestrzeni, rozdzielone przecinkami, na przykład SUPPORT, DOCS, PLATFORM	zdarzenia z tych przestrzeni trafiają do tego projektu Q247

Przy wariancie repozytorium dochodzi pytanie "Czy chcesz rozpocząć skanowanie tego projektu?" z opcją Rozpocznij skanowanie teraz. Wariant Jiry i Confluence takiego wyboru nie ma, bo te integracje działają zdarzeniowo.

Przeniesienie repozytorium do innego projektu

Źródło należy do dokładnie jednego projektu, więc przypisanie repozytorium, które jest już gdzieś przypisane, odłącza je od poprzedniego projektu. Formularz uprzedza o tym tekstem, ale sam zapis odbywa się od razu, bez okna potwierdzenia. Skutki przeniesienia:

• Historia przenosi się razem ze źródłem. Wszystkie dotychczasowe commity tego repozytorium zostają przypisane do nowego projektu, nie tylko te przyszłe. Stary projekt traci je z wyliczeń, nowy je zyskuje, również za okresy sprzed zmiany.
• Dodatkowe reguły nadal mają pierwszeństwo. Commit, który pasuje do aktywnej reguły, trafia do projektu tej reguły, a nie do projektu przypisanego repozytorium. Dotyczy to również przenoszonej historii.
• Uczestnicy znikają ze starego projektu. Osoba, której po przeniesieniu nie zostaje w starym projekcie żadne zdarzenie, przestaje być jego uczestnikiem. Traci przy tym rolę, jaką miała w tym projekcie, i trzeba ją nadać ponownie, jeśli była potrzebna.
• Repozytorium jest skanowane od nowa. Po przeniesieniu wraca do stanu przed pierwszym skanowaniem, a kolumna Ostatnie skanowanie zapełnia się ponownie po przebiegu.

Przeniesienie służy więc do korygowania przypisania. Do rozdzielenia commitów z jednego repozytorium między kilka projektów służą Dodatkowe reguły, opisane niżej.

Dodatkowe reguły

Reguły z tej zakładki dotyczą commitów, nie zdarzeń z Jiry i Confluence. Przypisują commit do tego projektu na podstawie klucza ticketu Jira znalezionego w wiadomości commita. Same integracje Jiry i Confluence podpina się przyciskiem Przypisz źródło w zakładce Źródła, opisanym wyżej.

Reguły przydają się, gdy praca nad jednym projektem Q247 jest commitowana z odwołaniem do kilku różnych kluczy ticketów, a przypisanie repozytoriów tego nie rozstrzyga; na przykład gdy jedno repozytorium obsługuje dwa projekty biznesowe rozróżniane wyłącznie kluczem ticketu.

Zalecana konwencja wiadomości commita

Klucz ticketu wyszukiwany jest w wiadomości commita, w jej temacie i treści. Nazwa gałęzi i zawartość zmian nie są przeszukiwane, więc klucz umieszczony wyłącznie w nazwie brancha zostanie pominięty.

Zalecamy zapis klucza na początku tematu, wielkimi literami, oddzielony od reszty dwukropkiem:

PAY-1042: obsługa zwrotów częściowych

Wymagania, które musi spełnić klucz, żeby dał się wyłuskać:

• Wielkie litery. pay-1042 i Pay-1042 nie zostaną rozpoznane.
• Kształt PREFIKS-NUMER: prefiks od 2 do 15 znaków (litera, dalej litery, cyfry albo podkreślenia), łącznik, od 1 do 8 cyfr.
• Odstęp przed kluczem. Klucz doklejony do słowa albo do dłuższego łańcucha z łącznikami zostanie pominięty, na przykład fixPAY-1042 czy MOJ-PROJEKT-1042. Sam nawias kwadratowy jest w porządku: [PAY-1042] opis działa.
• Liczy się pierwszy klucz. Wiadomość z dwoma kluczami zostanie powiązana tylko z pierwszym z nich, dlatego warto zaczynać temat od klucza właściwego dla danej zmiany.

Pola formularza

Przycisk Dodaj regułę otwiera okno "Dodaj dodatkową regułę" z sekcją "Szczegóły reguły":

Pole	Co wpisać	Przykład
Nazwa	własna nazwa reguły, do rozpoznania na liście	Commity z kluczem PAY
Wzorzec klucza ticketu	wzorzec dopasowywany do klucza ticketu wykrytego w wiadomości commita	PAY
Status	Aktywny albo Nieaktywny	Aktywny

Wzorzec dopasowuje się do fragmentu klucza i nie rozróżnia wielkości liter, więc PAY złapie PAY-1042 i PAY-7. Z tego samego powodu warto wzorce pisać precyzyjnie: PAY dopasuje również klucz PREPAY-3.

Kilka kluczy w jednej regule rozdziela się pionową kreską, na przykład PAY|BILL|INVOICE. Rozdzielenie przecinkami nie zadziała, bo wzorzec traktowany jest jako całość.

Kolejność reguł zmienia się przeciąganiem wierszy i decyduje o tym, która reguła wygra, gdy commit pasuje do kilku naraz: liczy się pierwsza dopasowana. Porządek obowiązuje w obrębie jednego projektu.

Reguła nadpisuje przypisanie wynikające z repozytorium

Bez dopasowanej reguły commit zostaje w projekcie, do którego przypisane jest jego repozytorium. Dopasowana reguła zmienia to przypisanie na projekt, w którym reguła została utworzona. Tym samym narzędziem rozdziela się commity z jednego repozytorium między kilka projektów.

Status Nieaktywny wyłącza regułę z dopasowywania, zachowując jej treść. Przydaje się, gdy trzeba czasowo wstrzymać przekierowanie bez utraty konfiguracji.

Zasięg czasowy reguł

Reguła rozstrzyga przypisanie commita w momencie, w którym Q247 go rejestruje, i to przypisanie zostaje zapisane razem ze zdarzeniem. Skutki tego są dwa:

• Nowa, zmieniona albo usunięta reguła działa od momentu zmiany. Commity zarejestrowane wcześniej zostają w projektach, do których zostały wtedy przypisane. To samo dotyczy zmiany kluczy projektów Jiry i kluczy przestrzeni Confluence w formularzu Przypisz źródło.
• Reguły warto ustawić przed uruchomieniem skanowania, a przynajmniej przed pierwszym pełnym przebiegiem repozytorium, bo późniejsza korekta nie poprawi już zebranej historii.

Jeśli historia mimo wszystko wymaga korekty, jedyną operacją, która przypisuje zdarzenia ponownie, jest przeniesienie repozytorium do innego projektu. Obejmuje ona całą historię danego repozytorium, więc nie nadaje się do poprawiania pojedynczych commitów.

Natychmiastowy zapis kolejności

Zmiana kolejności reguł przelicza ich priorytety i zapisuje się natychmiast.

Metryki przepływu

Ta zakładka jest widoczna tylko wtedy, gdy projekt ma podpiętą integrację ticketingową (Jira). Pozwala nadpisać dla tego jednego projektu granice metryk przepływu ustawione globalnie dla organizacji w Konfiguracji.

Nagłówek "Nadpisania granic metryk przepływu dla tego projektu" zbiera pięć ustawień, każde z osobnym przełącznikiem Dziedzicz / Nadpisz:

Ustawienie	Co obejmuje
Początek czasu realizacji	start Lead Time
Początek czasu cyklu	start Cycle Time
Koniec (czas realizacji i cyklu)	koniec wspólny dla obu metryk
Typy ticketów	które typy wchodzą do wyliczeń
Kategorie rozkładu przepływu	które typy liczą się jako Funkcje, a które jako Błędy

Domyślnie każde z nich stoi na Dziedzicz, a pod przełącznikiem widać wartość odziedziczoną z organizacji, z podpisem "Dziedziczy z organizacji". Projekt bez żadnego nadpisania liczy się więc dokładnie tak jak reszta organizacji, a późniejsza zmiana ustawienia organizacji przenosi się na niego automatycznie.

Przełączenie pojedynczego pola na Nadpisz odcina je od organizacji i wymaga podania własnej wartości; pozostałe cztery pola nadal dziedziczą. Nadpisanie granicy początku albo końca przelicza metryki tego projektu wstecz, tak samo jak zmiana granicy na poziomie organizacji.

Więcej o samych metrykach w Metrykach przepływu.

Zobacz też

• Źródła: pełna lista źródeł danych organizacji, niezależnie od przypisania do projektu
• Uprawnienia: jak przypisanie kierownika projektu przekłada się na poziom dostępu
• Metryki przepływu: co oznaczają Lead Time i Cycle Time