Przejdź do głównej zawartości

Raport zmian (eksport delta)

Większość eksporterów odpowiada „jak to teraz wygląda?”. Raport zmian odpowiada na pytanie, które ludzie faktycznie zadają na spotkaniu dotyczącym statusu: ** „co się zmieniło od ostatniego razu?”**

Dostępne na Standard dla JQL, eksportu tablic, sprintów, wydań i zaległości. Najlepiej sprawdza się jako zaplanowany eksport — cotygodniowy raport „Co się ruszyło”, który ląduje w Twojej skrzynce odbiorczej w poniedziałek rano.

Czym nie jest

To nie jest zrzut dziennika zmian Jira. Komponent historii zmian już to robi dla każdego problemu.

Raport zmian działa na poziomie wyeksportowanego zestawu:

  • które wydania pojawiły się w wyniku,
  • które problemy nie pojawiają się już w wyniku,
  • które wystawia moved — status, cesjonariusz, priorytet, termin realizacji oraz wszelkie dodane przez Ciebie pola,
  • nowe komentarze i dzienniki prac.

„Nie ma już wyniku” nie oznacza usunięcia

To najważniejsza rzecz, którą należy zrozumieć w związku z raportem.

Gdy problem pojawi się w polu Nie występuje już w wyniku, nie jest już częścią zestawu wyników eksportu. To not oznacza, że ​​problem został usunięty. Mógł zostać przeniesiony do innego projektu, ponownie przypisany, oznaczony nową etykietą lub po prostu zmodyfikowany tak, że filtr już do niego nie pasuje.

Na każdej liście pominiętych spraw znajduje się ta uwaga w wyeksportowanym dokumencie, w każdym języku i formacie, a zagęszczanie nigdy jej nie usuwa. Zgłoszenie twierdzące, że utwór został usunięty po zmianie jego etykiety, byłoby kosztownym nieporozumieniem.

Z tego samego powodu nierozwiązane problemy są wymienione tylko według klucza. Exportelier nie zawiera ich kopii, a sprawdzenie ich obecnego stanu nie mówi nic o tym, dlaczego odeszli.

Konfigurowanie

  1. Otwórz szablon w kreatorze.
  2. Włącz Zmień raport i wybierz punkt odniesienia.
  3. Umieść trzy komponenty:
    • Podsumowanie zmian — liczniki, linia referencyjna i ewentualne notatki.
    • Lista problemów Delta — jedna lista, ustawiona na Dodano lub Nie ma już wyniku. Dodaj go dwa razy dla obu.
    • Tabela zmian — jeden wiersz na każde zmienione pole.
  4. Zapisz i używaj szablonu tak samo jak każdego innego.

Punkty odniesienia

OdniesienieZnaczenieUżyj go dla
Poprzedni eksportOstatni raz, kiedy ten szablon wyeksportował ten zakresRaporty ad-hoc
Poprzednie zaplanowane uruchomienieOstatnie pomyślne uruchomienie tego harmonogramuRaporty tygodniowe i miesięczne
Stała dataData, którą wpisujesz„Wszystko od czasu wycięcia gałęzi wydania”

Śledzone pola

Status, cesjonariusz, priorytet i termin są zawsze śledzone. Dodaj własne — punkty historii, sprint, pole niestandardowe — w ustawieniach szablonu. Nowe komentarze i dzienniki zadań również liczą się jako zmiany i można je wyłączyć, gdy stanowią hałas dla odbiorców.

Pierwszy bieg

Pierwszy raport dotyczący szablonu i zakresu nie ma nic do porównania. Zamiast zawieść, generuje pełny raport bieżącego zestawu i mówi tak:

To jest pierwszy raport zmian dla tego szablonu i zakresu, więc zawiera pełny bieżący zestaw. Późniejsze raporty pokażą tylko to, co się zmieniło.

Od drugiego przejazdu otrzymasz prawdziwą deltę.

Sprawdzony przykład

Zespół przeprowadza cotygodniowy zaplanowany eksport w każdy poniedziałek o 08:00 względem project = EX AND sprint in openSprints(), używając wszystkich trzech komponentów i odniesienia Poprzednie zaplanowane uruchomienie.

Poniedziałek 3 sierpnia — pierwszy przebieg. Nie istnieje żaden wcześniejszy przebieg, więc raport zawiera listę wszystkich 14 problemów związanych ze sprintem i zawiera notatkę dotyczącą pierwszego uruchomienia. To jest podstawa.

W ciągu tygodnia. EX-104 jest tworzony i wciągany do sprintu. EX-77 przechodzi do innego projektu i wypada z filtra. EX-42 przenosi Zadanie → W toku → Przegląd → W toku → Przegląd → Wykonane w ciągu pięciu dni. EX-51 zostaje przeniesiony z Ady do Grace i otrzymuje dwa komentarze. Dziesięć kwestii pozostaje nietkniętych.

Poniedziałek 10 sierpnia — druga edycja. Raport rozpoczyna się od:

Zmiany od 3 sierpnia 2026

Dodano: 1 · Nie ma już w wyniku: 1 · Zmieniono: 2 · Bez zmian: 10

Następnie tabela zmian:

KluczPoleZNaZmiany
EX-42statusDo zrobieniaGotowe5
EX-51cesjonariuszAdaGrace1

Zwróć uwagę na wiersz EX-42. Problem ten zmienił status pięciokrotnie i jest to jedna linia pokazująca, gdzie się zaczęła, gdzie się zakończyła i ile kroków zajęło. Pięć oddzielnych wierszy dla jednego problemu pogrzebałoby dwa problemy, które faktycznie wymagają uwagi.

Czas czytania: około piętnastu sekund, zamiast przewijania czternastu opisów problemów, aby dowiedzieć się, co jest inne.

Kiedy historii nie da się zrekonstruować

Jira nie rejestruje wpisu dziennika zmian dla każdego pola, a bardzo długie historie są obcinane, gdy Exportelier je pobiera. Jeżeli dostępna historia nie może objąć całego okresu raportowania, problem jest zgłaszany w podsumowaniu jako nie do odtworzenia, a nie po cichu traktowany jako niezmieniony.

Zadania podrzędne i głębsze poziomy hierarchii nie mają własnej historii zmian, więc również należą do tej grupy. Nadal są one wliczane do sumy — delta zawsze działa w przypadku płaskiego zestawu wyeksportowanych problemów, więc liczby się sumują.

Co przechowuje Exportelier

Aby powiedzieć Ci, co zostało dodane, a co pozostało, Exportelier musi zapamiętać, które problemy wystąpiły podczas ostatniego eksportu. Przechowuje klucze wydania i nic więcej.

Żadnych podsumowań, żadnych wartości pól, żadnych opisów, żadnych komentarzy. Wartości przed i po w tabeli zmian są odczytywane z własnej historii zmian Jira w momencie generowania raportu i nigdy nie są zachowywane. Przechowywana lista kluczy wygasa po 180 dniach.

Jest to celowe: zachowanie wartości pól ułatwiłoby tworzenie raportu i spowodowałoby, że Exportelier stałaby się drugą kopią Twojej Jira treści, ze wszystkim, co wiąże się z ochroną danych.

Limity

  • Niedostępne w przypadku eksportu pojedynczych numerów — użyj komponentu Historia zmian.
  • Niedostępne w przypadku poszczególnych numerów archiwa ZIP: raport dotyczący całego zestawu nie zawiera pojedynczego dokumentu, w którym można by go uwzględnić.
  • Zapamiętywanych jest do 2000 kluczy wydań na szablon i zakres. Powyżej raport stwierdza, że ​​dodane i opuszczone liczniki mogą być niekompletne.
  • Tabela zmian jest ograniczona do 500 wierszy w całym raporcie; jeśli zostanie osiągnięty, dokument tak mówi.