Kupując dany produkt zależy nam, aby był dobrej jakości. Często zwracamy uwagę na dojrzałość firmy, która go produkowała, jej doświadczenie, know how. Chcemy wiedzieć, czy to pierwsza próba z danego obszaru działalności danego biznesu czy też produkt od wielu lat cieszy się dużym powodzeniem na rynku. Podobnie sprawa ma się z oprogramowaniem, a także jego cząstkami – bibliotekami i frameworkami.
Wytwarzając software nie zawsze programujemy wszystko od początku, od przysłowiowego zera. Stosunkowo często zdarza się, że korzystamy z tak zwanych third parties, którymi mogą być na przykład biblioteki i frameworki. W uproszczeniu możemy powiedzieć, że stanowią one fragmenty kodu napisane i utrzymywane przez kogoś innego. Rozwiązują one popularne problemy i są reużywalne. Możemy na przykład wyobrazić sobie bibliotekę do formatowania dat i wyświetlania ich w zależności od lokalizacji (przykład: Moment.js) lub bibliotekę do tworzenia Gantt Chartów (przykład: Bryntum Gantt).
Jak zapewne przypuszczasz, tworząc dany produkt, również softwarowy, bardzo istotna jest dla nas jego jakość. Za nią wszak bierzemy również odpowiedzialność jako zespół deweloperski, PO lub Project Manager. Na tę jakość ie wpływa jedynie jakość kodu napisanego przez nasz zespół deweloperski, ale również jakość wykorzystanych w rozwiązaniu bibliotek. Decydując się na dodanie do kodu każdej kolejnej biblioteki tworzymy zależność zewnętrzną. Należy to robić mądrze, gdyż od tej pory jakość tworzonego przez nas oprogramowania nie zależy tylko od naszego kodu, ale tez jakości tej właśnie biblioteki. Dodatkowo musimy dbać o kompatybilność bibliotek między sobą. Przypuszczalnie więc dostrzegasz już, dlaczego decyzja o dodaniu każdej nowej biblioteki powinna być przemyślana, a rozwiązaniem nie jest adresowanie w ten sposób każdego najmniejszego wyzwania. Każda nowo dodana zależność wpływa na nasze kolejne decyzje.
Dzisiaj chciałabym Ci pokazać, że oprogramowanie również ma swoje miary dojrzałości, a w IT przyjęta jest standardowa nomenklatura do określania poszczególnych wersji oprogramowania w zależności od ich stopnia dojrzałości. Z aktualizacją danej wersji publikowane są zazwyczaj poprawki dotyczące znanych/wykrytych błędów (ang. fixes for known issues). Być może kojarzysz jedno z takich określeń – wersję beta. Zdarza się, że dane oprogramowanie jest właśnie w ten sposób reklamowane do użytkowników końcowych. Dzięki temu wiedzą oni, że software nie jest jeszcze w 100% gotowy i świadomie godzą się na niższą jakość- od początku jej oczekują. Jednocześnie oprogramowanie jest testowane przez użytkowników końcowych, firma może więc otrzymać feedback z pierwszej ręki.
Odrobina historii.
Początków nomenklatury obecnie używanej w IT doszukuje się w historii firmy IBM, która w latach pięćdziesiątych XX wieku wykorzystywała litery z początku alfabetu do określania poszczególnych etapów dojrzałości produktu. Produkt wydany do weryfikacji przed podaniem do wiadomości publicznej był określany literą „A”. „B” oznaczało weryfikację przed rozpoczęciem masowej produkcji. „C” było finalnym testem przed powszechnym udostępnieniem produktu dla użytkowników końcowych. Mimo że w latach sześćdziesiątych zarzucono tę terminologię, zdążyła się już ona stosunkowo mocno rozpowszechnić. Co ciekawe, w IBM nie używano już później pojęcia beta testów. Zamiast tego zjawisko testowania produktu przez użytkowników końcowych określano mianem „field testów”.
Pre-alpha zazwyczaj odnoszone jest do wszystkich czynności wykonywanych przed oficjalnym rozpoczęciem testów końcowych przed wydaniem. Te aktywności mogą dotyczyć inżynierii wymagań, projektowania, wytwarzania oprogramowania, testów jednostkowych. W przypadku bardziej rozbudowanych flow zdarza się, że mamy kilka różnych rodzajów wersji pre-alpha. Z pewnością nie należy oczekiwać, że są to wersje stabilne.
Mianem alpha określa się wersję, która wciąż znajduje się jeszcze we wczesnej fazie testowania. Jest już na tyle funkcjonalna, aby być używana, ale wciąż jeszcze brak jej finalnego szlifu (wygładzenia) jak również niejednokrotnie kilku funkcjonalności, które będą zawarte w wersji finalnej. Wersje alpha oprogramowania są zazwyczaj testowane wewnętrznie. Czasami wersja alpha ma również znaczenie komercyjne- firmy nie chcą wyjawiać funkcjonalności (tzw. featurów), które będą zawarte w nowej wersji. Zdarzają się jednak także odwrotne sytuacje, szczególnie w przypadku bibliotek wykorzystywanych przez zewnętrzne aplikacje. Deweloperom może zależeć na jak najszybszym opublikowaniu wersji, nawet alpha, po to, aby inni zaczęli jej używać i tym samym pomogli znaleźć w niej potencjalne błędy jak najwcześniej.
Wersja Beta.
Beta to kolejna po alfie litera greckiego alfabetu. Wersja beta jest więc już dojrzalsza, zawiera również wszystkie planowane na dany release funkcjonalności. Na tym etapie software może jeszcze zawierać zbiór znanych lub nieznanych błędów. Mogą one dotyczyć zarówno funkcjonalności, jak również wydajności aplikacji (performance) lub utraty danych. Na tym etapie kontynuujemy również badania nad użytecznością aplikacji. Dla wielu firm beta release jest pierwszym releasem dostępnym dla użytkowników końcowych. Może być dostępny publicznie lub ograniczony do prywatnej, zdefiniowanej grupy odbiorców. Być może kojarzysz niektóre z gier komputerowych prowadzące specjalne zapisy na korzystanie z ich beta release. Służy to przede wszystkim zebraniu użytecznego feedbacku i znalezieniu jak największej ilości błędów przed finalnym releasem.
Warto pamiętać, że zazwyczaj wersji beta mamy więcej. W odpowiedzi na feedback od użytkowników powstają nowe, ulepszone wersje. Nie oznacza to jednak, że mogą one od razu zostać oficjalną, finalną wersją danego oprogramowania.
Release candidate (RC).
Release candidate jest zazwyczaj jedną z wersji beta, która ma potencjał zostać wydana jako stabilny produkt. Wciąż jest on testowany pod względem znalezienia potencjalnych bugów, jeśli jednak nie zostanie znalezione nic, co mogłoby przekreślić wydanie stabilnej wersji, release candidate staje się oficjalną wersją oprogramowania.
Inne wersje.
Być może zastanawiasz się, czy istnieją jakieś inne wersje oprogramowania, które warto znać? Postanowiłam przytoczyć Ci jeszcze kilka innych przykładów. Nie złożymy je w jeden ciąg następujących po sobie wersji jak powyżej, ale z pewnością ułatwimy w ten sposób codzienne interakcje w zespołach deweloperskich.
Nightly.
Tak zwany nightly build jest wersją oprogramowania, która wytwarzana jest automatycznie każdej nocy. Zazwyczaj bazuje na najnowszej zintegrowanej wersji kodu i jest wytwarzana podstawie jednego z głównych branchy. Idea nightly builda polega na budowaniu wersji w momencie, kiedy zespół nie pracuje. Tak, aby po przyjściu następnego dnia do pracy mógł otrzymać wersję do testowania, a także jakieś pojęcie o jakości aktualnej wersji kodu. To pojęcie budowane jest zazwyczaj w oparciu o testy automatyczne, pipeliny mogą zostać również skonfigurowane w odpowiedni sposób, tak, aby dokonać szeregu operacji sprawdzających. Daje to natychmiastowy feedback deweloperom. Wiedzą, czy „build przeszedł”, czy „aplikacja się buduje”.
Snaphot.
Innym pojęciami, z którymi możecie się spotkać w kontekście wersji oprogramowania są snapshoty i tagi. Snapshot to pojęcie związane z Maven’em i odnosi się do wersji, która nie została jeszcze wydana. Przykładowo możemy mieć 1.0-SNAPSHOT jako wersję, która może stać się wersją 1.0, ale jest póki co jeszcze w dewelopmencie. Co ciekawe również snapshoty mogą mieć wersje, tzn. ten sam snapshot dzisiaj może wskazywać na inną wersję oprogramowania niż w dniu jutrzejszym. Inaczej odbywa się to w przypadku releasów, gdzie poprawki do releasu 1.0 nie będą nazywać się również dokładnie „1.0”.
Tag.
Tag to nic innego jak specjalnie oznaczony commit w Git czyli podobnie nic innego jak wersja oprogramowania. Jeśli rozumiesz, jak działa git, wiesz, że możemy mieć tam branche, na których odkładamy poszczególne commity. Nadanie nazwy takiemu commitowi (otagowanie go) tworzy tag.
A Ty, z jakimi rodzajami wersji oprogramowania się spotkałeś? Milestone, wave, a może jeszcze coś innego?