Zalety powtarzalności w tworzeniu oprogramowania

Ostatnio zastanawiałem się nad procesem tworzenia oprogramowania. Również na podstawie własnych doświadczeń, wydaje mi się, że kluczem do sprawnego przeprowadzenia projektu developerskiego jest powtarzalność. Powtarzalnością powinno być objęte budowanie, testowanie oraz deployment.

Do zapewnienia powtarzalności potrzebne jest parę niezbędnych składników:

  • Repozytorium kodu
  • Automatyczne testowanie
  • Ciągła Integracja(Continuous Integration) szczególnie dla zespołów, w których jest wiele developerów
  • Automated Deployment

Repozytorium kodu

Kod Ľródłowy powinien mieć jedno centralne miejsce, w którym jest składowany. Mam na myśli serwer, a nie folder moje dokumenty. To centralne, ogólnie znane w firmie miejsce zapewnia, że zawsze kiedy zachodzi potrzeba sięgnięcia do najaktualniejszej wersji dawno zapomnianego rozwiązania wiadomo gdzie trzeba szukać.

W dawnych czasach naturalnym wyborem wydawał się CVS, teraz ( jeśli chodzi o darmowe produkty) tryumfy świętuje Subversion, który zapewnia wszystko to co CVS z prostszą filozofią. Istnieje wiele rozwiązań pozwalających na kontrolę kodu i generalnie wybór zależy od preferowanego producenta itp. Według mnie najważniejsze jest, żeby tylko używać jakiegoś.

Automatyczne testowanie

Pisania testów to dla mnie niezbędna rzecz. Gwarantuje, że na każdym etapie życia projektu jesteśmy w stanie w krótkim czasie sprawdzić czy wszystko działa jak należy. Ile razy dokonywałeś zmian kodu, które powodowały nieprzewidziane zachowanie w innych miejscach? No właśnie, z testami automatycznymi natychmiast można znaleĽć problem i co ważniejsze zanim znajdą go Twoi klienci. Nie bez znaczenia jest również koszt naprawy błędu, gdy okazuje się, że musisz np.: poinformować o błędzie np 1000 użytkowników. A co w sytuacji gdy masz ich np 10k ?

Automatyczne testowanie narzuca też pewien specyficzny sposób pisania kodu i myśleniu o rozwiązaniu/aplikacji. Żeby kod był testowalny musi zostać napisany w przemyślany sposób, a nie “jak się uda”.

Czasami testowanie może okazać się trudne szczególnie gdy architektura nie jest odpowiednio dostosowana, wówczas trzeba niestety polegać na testowaniu UI. Taka sytuacja często ma miejsce przy klasycznych aplikacjach WebForms w ASP .NET.

Ciągła integracja(Continuous Integration)

CI zapewnia ciągłe pobieranie najaktualniejszego kodu z repozytorium i budowanie całego rozwiązania. Najlepiej, żeby proces był wykonywany na maszynie nie skażonej bibliotekami SDK jak to często bywa na maszynach deweloperskich. Jeżeli rozwiązanie buduje się na prawie czystej maszynie mamy pewność, że gdy ktoś zupełnie inny zacznie pracować nad projektem będzie w stanie w krótkim czasie stworzyć działającą aplikację.

Bardzo często CI integruje się z automatycznym testowaniem. Gdy testy nie zakończą się sukcesem cały build jest oznaczany jako failed i wymagana jest interwencja ze strony developera. Pozwala to także szybko wychwycić, czy nie dokonano tzw. breaking changes, czyli zmian które spowodowały niepoprawne działanie innych części aplikacji.

Dla mnie szczególnie ważnym aspektem CI jest natychmiastowa informacja zwrotna dla developera, czy jego zmiany są poprawne oraz czy np nie zapomniał dodać jakiegoś pliku

W wersji dla paranoików CI można poszerzyć o code coverage i na przykład sprawdzać czy testy pokrywają ponad 80% kodu. Jeśli tak nie jest wówczas cały build znowu można oznaczyć jako failed.

Automated deployemnt

Automated deployment, czyli automatyczne instalowanie najaktualniejsze wersji. Tutaj sprawa jest bardziej skomplikowana, bo w wypadku np.: aplikacji webowej można bez problemu oskryptować taką operację. Czasem jednak trzeba dostarczyć ręcznie odpowiednie pliki .zip albo .msi.

Czasem automatyczna instalacja musi zostać ograniczona tylko do środowiska testowego lub tzw. staging, szczególnie w wypadku gdy wdrożony jest bardzo sztywny proces akceptacji wersji dostępnych dla klienta.

Podsumowanie

Konsekwentne zastosowanie paru stosunkowo prostych kroków, spowoduje że będziesz mógł być spokojny o swój projekt. Szybko się dowiesz, że z projektem dzieje się coś niedobrego i nawet kiedy (ty lub inni deweloperzy) będziesz sięgał do kodu za jakiś czas będziesz w stanie szybko dostarczyć działającą wersję.