Bartek Szafko

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ę.

It’s been quite some time since visual studio 2008 is out… I finally moved one of the project which is under continous integration to newest visual studio version. Unfortunately it turned out that my veeeery old CI Factory supports only .net 2.0.

In MSBuild\Compile.Target.xml I found:

So without hesitation I put:

Kind of quick and dirty. Newer versions of CI Factory support it out of the box.

Swego czasu byłem bardzo wiernym czytelnikiem bloga http://www.joelonsoftware.com. Teksty Joela były naprawdę ciekawe i pouczające, jednak ostatnio naprawdę pogorszyła się ich jakość. Teraz Joel pisze o meblach i układzie biura – nudy. Za to do mojego rss readera dołączył Gojko Adzic ( http://gojko.net/ ), który pisze świetne artykuły o tworzeniu oprogramowania z perspektywy developera. Mało w nich przykładów kodu, za dużo refleksji nad procesem oraz sposobem zarządzania. Polecam.

http://www.nikhilk.net/project.webdevhelper.aspx

ASP.NET Development Helper is a utility for ASP.NET page and control developers that plugs into Internet Explorer. It allows viewing information about the current page such as view state and trace, perform some operations on the server in the context of the running application to aid testing, and also allows monitoring requests and responses for diagnostic scenarios.

With all that after Cebit hype around AJAX, I began to wonder if this is worth it. I mean AJAX heavily relies on JavaScript, frankly for me it’s not a solid foundation. On every browser it runs in a different way, not to mention lack of unit testing. And the most hilarous is that you don’t know if it runs till you execute it in a browser. Generally AJAX like technologies are around for almost ten years and it has no standards defined. It also made me thinking… M$ released today its own ajax implemntation called atlas.
Ostatnio bardzo popularny stal sie temat AJAXa, zastanawiam czy ta technologia wogole jest warta uwagi. Ajax bardzo silnie polega na JavaScript, kt?rej niestety nie uwazam za solidny fundament. Na kazdej przegladarce Javascript wykonuje sie w inny sposob no i oczywiscie nie ma zadnego sposobu na testownie.Nie wspominam juz o tym, ze jedynym sposobem na dowiedzenie sie czy kod zadziala jest uruchomienie go w przegladarce. Technologie podobne do AJAXa sa juz na swiecie prawie 10 lat, a mimo to nadal nie doczekaly sie standardow, to tez jest zastanawiajace…

MS wypuscil dzisiaj swoja wlasna implementacje AJAXa, ktora nazwal ATLAS.

I must admit I like the idea that stands behing Flickr very much. Today I signed up for my account, I was a bit overwhelmed by rich options. But finally I got used to it.

I plan to integrate it with my b2evolution blog, which is possible, at least some people were stating it on the forums.

The feature I like the most is rss photo feeds, I even found screen saver that shows pictures from it

Maybe I will also setup a photo group(??) to put some pictures from high school reunion meeting which takes place tommorow.