Automatyczny strażnik commit’ów

You shall not passJesteśmy ludźmi – lubimy porządek, ale nie lubimy sami sprzątać. Dlatego też dobrze jest jeżeli niektóre rzeczy same dbają o porządek.

Codzienną czynnością programistów jest oddawanie (operacja commit) kodu do repozytorium kodu źródłowego. Przy tej operacji można wpisać komentarz opisujący jakie zmiany funkcjonalne są oddawane, np. „dodana możliwość usuwania kontrahentów” czy „poprawienie błędu przy definiowaniu nowej operacji”. Wszyscy wiedzą, że opisywanie tych zmian jest bardzo ważne – ale też bardzo często w repozytorium lądują zmiany bez żadnych opisów. A sprawdzenie listy zmienionych obiektów oraz zmian w ich w celu określenia co się zmieniło jest bardzo pracochłonne…

Co wtedy robimy?

Punktem pierwszym jest spotkanie zespołu, powiedzenie dlaczego te opisy są ważne i wprowadzenie zasady „od dzisiaj wpisujemy zmiany przy operacji commit”. Czy to pomaga? Przeważnie tak, ale nie do końca – w praktyce, pomimo określenia pewnych zasad, zdarzają się przypadki zmian, które nie są opisane. Można wtedy wprowadzić ręczne kontrole opisów przy ostatnich zmian – codziennie ktoś sprawdza wczorajsze operacje commit, czy są poprawne. Ale można też oszczędzić sobie niepotrzebnej pracy i napisać króciutki skrypt, który dołączymy jako pre-commit hook – czyli fragment kodu wykonywany przed operacją commit i potrafiący ją zablokować przy niespełnieniu pewnych warunków. Poniższy przykład pokazuje kod takiego skryptu napisanego dla systemu kontroli wersji SVN.

Co więcej – kontrola obecności komentarza to tylko najprostsze automatyczne sprawdzenie, które możemy zaimplementować. Można przed commit’em sprawdzać również jeszcze inne rzeczy, poniżej dwa przykłady.

Sprawdzenie czy użytkownik nie próbuje oddać do kontroli wersji fragmentów, które są markerami konfliktów:

Możemy również wymusić niestosowanie pewnych konstrukcji programistycznych:

Tworzenie takich skryptów jest proste – a oszczędzają one manualnej pracy i w prosty sposób zapobiegają niepożądanym praktykom.

Pomysł oraz kod skryptów: Witold Bołt. Tekst wpisu: Stanisław Matczak.

4 thoughts on “Automatyczny strażnik commit’ów

  • 2 września 2011 at 15:00
    Permalink

    Drobne uwagi do skryptów:

    1. Skrypt sprawdzający markery konfliktów powinien działać tylko na plikach tekstowych (można sprawdzić Mime Type pliku w SVN i na tej podstawie decydować), bo przy „commitowaniu” np. obrazków trudno będzie rozwiązać problem bez wyłączenia skryptu.

    2. Skrypt sprawdzający zakazane konstrukcje językowe powinien działać tylko na plikach tekstowych z określonymi rozszerzeniami – System.gc() ma sens w przypadku *.java, ale nie koniecznie w pliku instrukcja.txt informującym o zakazie użycia takiego polecenia ;-)

    Oczywiście sam pomysł automatyzacji jest jak najbardziej sensowny, tylko trzeba uważać na pułapki…

    Reply
    • 2 września 2011 at 21:06
      Permalink

      Skrypty pokazane w artykule to tylko ilustracja. Oczywiście, że mają wady – te, które wymieniłeś to jedno. Inna rzecz, że powinny bardziej dokładnie informować użytkownika co i gdzie było nie tak. Tak czy inaczej na tyle na ile zrozumiałem intencje Stasia :) chodzi o pokazanie samej (nie nowej – ale bardzo produktwynej i mądrej) idei automatyzowania wszystkiego co się da w kwestii trzymania jakości.

      Z resztą powyższe przykłady napisano z myślą o subversion, ale podobne techniki można użyć w git i innych bardziej cywilizowanych narzędziach :) Idea jest więc ogólna i bardzo skuteczna.

      Z drugiej strony nie można przesadzać, żeby hooki nie trwały pół godziny na dużych commitach :)

      Reply
  • 15 września 2011 at 11:55
    Permalink

    Witaj,

    fajny przyklad, ale w drugim przypadku znacznie mniej pracochlonne bedzie podpiecie PHP_CodeSniffer’a pod hook z ustalonymi regulami dla calej firmy/projektu no i oczywiscie znacznie wiecej mozliwosci zyskujemy dzieki temu.

    Reply
    • 17 września 2012 at 19:37
      Permalink

      Uważam, że podpisanie Code Sniffera pod SVN mija się z celem. SVN jest systemem kontroli wersji, a nie narzędziem do Continous Integration. O ile weryfikacja komentarzy przy commicie, wysyłanie powiadomień mailowych po commicie i tym podobne mają sens, to już szczegółowa analiza kodu powinna następować w narzędziach do tego przeznaczonych jak np. Jenkins.

      Reply

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *