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

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