Czy odniesienie do błędu / problemu w komunikacie zatwierdzenia jest uważane za dobrą praktykę?

11

Pracuję nad projektem, w którym mamy kontrolę źródła skonfigurowaną do automatycznego zapisywania notatek w narzędziu do śledzenia błędów. Po prostu zapisujemy identyfikator problemu w komunikacie zatwierdzenia, a komunikat zatwierdzenia jest dodawany jako notatka do narzędzia do śledzenia błędów.

Widzę tylko kilka wad tej praktyki. Jeśli kiedyś w przyszłości kod źródłowy zostanie oddzielony od oprogramowania do śledzenia błędów (lub zgłoszone błędy / problemy zostaną w jakiś sposób utracone). Lub gdy ktoś patrzy na historię zmian, ale nie ma dostępu do naszego narzędzia do śledzenia błędów.

Moje pytanie brzmi, czy umieszczenie odniesienia do błędu / problemu w komunikacie zatwierdzenia jest uważane za dobrą praktykę? Czy są jakieś inne wady?

programming-practices version-control issue-tracking Christian P.
źródło

Odpowiedzi:

10

Przyjęliśmy tę praktykę i działa ona dla nas bardzo dobrze. Ścisła integracja między systemem kontroli wersji (VCS) a innymi używanymi przez nas systemami, np. Ciągłą integracją, śledzeniem błędów itp. Jest niezwykle cenna. Jeśli kiedykolwiek coś zmienimy w przyszłości, z pewnością będziemy musieli ocenić skutki uboczne, w tym powiązania między VCS a systemem śledzenia błędów.

Ogólnie uważałbym to za dobrą praktykę. W przypadku niektórych systemów śledzenia dostępne są dodatkowe opcje i narzędzia, na przykład właściwości bugtraq dla Subversion (SVN). Sugeruje to, że wiele osób widzi wartość w tej praktyce.

Manfred
źródło
13

Jeśli chcesz się naprawdę upewnić, że nie stracisz żadnych informacji, nawet jeśli w przyszłości będziesz mógł użyć innego narzędzia do śledzenia błędów lub dane z narzędzia do śledzenia błędów w jakiś sposób znikną, dlaczego nie po prostu wstawić zarówno identyfikatora problemu, jak i krótkiego wyjaśnienia błędu komunikat zatwierdzenia?

Napraw błąd nr 123: aplikacja uległa awarii po zalogowaniu

W dalszym ciągu masz link z historii zatwierdzeń do narzędzia do śledzenia błędów - a jeśli narzędzie do śledzenia błędów będzie kiedykolwiek niedostępne, nadal możesz zobaczyć w historii, o czym był ten konkretny błąd.

Christian Specht
źródło
W rzeczywistości to robimy, więc nie musimy przełączać się do śledzenia błędów za każdym razem, gdy przeglądamy historię zatwierdzeń.
Christian P
Okej, po prostu zostawiłbym to tak, jak jest. IMO, to najlepszy sposób, jak to zrobić!
Christian Specht
1
Tak, dobra uwaga. Ale i tak to założyłem. Sam identyfikator błędu / problemu nie jest wystarczająco dobry z mojego doświadczenia. Patrząc na dziennik zatwierdzeń, wciąż chcesz zobaczyć, o co chodziło w każdym zatwierdzeniu, np. Jaki był główny powód tej zmiany kodu. Czasami komunikat zatwierdzenia jest bardziej techniczny, podczas gdy tekst systemu śledzenia błędów jest bardziej ukierunkowany na użytkowników oprogramowania.
Manfred
Jest to ogólnie standardowa praktyka, w której również pracowałem, myślę, że to właściwy sposób, aby to zrobić.
Carson63000,
+1 zawsze to rób! Właśnie zająłem się utrzymaniem projektu, który jest pełen klejnotów, takich jak „mogła to być przyczyna błędu 5423”. Nie mamy dostępu do ich narzędzia do śledzenia błędów.
Kryptic,
2

Jest to bardzo powszechna praktyka i uważam ją za niezwykle wygodną. Korzystam z TRAC, więc mogę odczytać historię kodu i przejść do zadania, które spowodowało zmianę, lub odczytać historię zadania i przejść do zmian kodu.

„Jeśli kiedyś w przyszłości ...” Jeśli oddzielisz kod od narzędzia do śledzenia błędów, stara historia zmian prawdopodobnie nie będzie już interesująca.

Kevin Cline
źródło
2

Ja również używam tej praktyki i uważam ją za bardzo dobrą. Ale oprócz identyfikatora problemu dodaję krótki opis błędu / funkcji (zwykle tytuł z systemu śledzenia błędów). To często pomaga zaoszczędzić czas, ponieważ nie muszę szukać w systemie śledzenia błędów (ponieważ rozpoznaję zmianę) ORAZ, jak powiedziałeś, jeśli w jakiś sposób stracę system śledzenia błędów, nie jestem całkowicie zgubiony.

Nicolae Albu
źródło