Wybór wersji oprogramowania do wdrożenia

Kwestia, którą bardzo często widzę dyskutowaną w kręgach IT, to „którą wersję oprogramowania powinienem zainstalować”. Może to dotyczyć bazy danych, aplikacji, oprogramowania układowego lub, najprawdopodobniej, systemów operacyjnych. W związku ze zbliżającym się końcem okresu wsparcia dla Windows XP temat ten osiągnął gorączkowe natężenie.

Istnieją w zasadzie dwie strony tej dyskusji. Jedna strona uważa, że zawsze należy używać najnowszego i, przypuszczalnie, najlepszego oprogramowania. Druga uważa, że oprogramowanie potrzebuje czasu na dojrzewanie i przyjmuje podejście „poczekaj i patrz”, a nawet traktuje każdą wersję jako odrębny produkt, a nie kontinuum rozwoju.

Oba podejścia mają swoje zalety i żadne z nich nie powinno istnieć całkowicie bez drugiego. ślepe aktualizowanie oprogramowania bez zastanowienia nie jest mądre, podobnie jak unikanie poprawek i aktualizacji bez powodu. Staranne rozważenie czynników i empatia wobec procesu tworzenia oprogramowania są ważne przy podejmowaniu tych decyzji.

Po pierwsze, istnieją dwa zupełnie różne scenariusze do rozważenia. Jeden to aktualizacja obecnego, istniejącego oprogramowania. Założeniem jest, że obecny stan rzeczy „działa”, przy akceptowalnej możliwości, że „działanie” może obejmować lukę bezpieczeństwa, która została wykryta i wymaga aktualizacji w celu jej zamknięcia. Drugi scenariusz to nowe wdrożenie, gdzie nie ma niczego i zaczynamy od zera.

Zacznijmy od drugiego przypadku, ponieważ znacznie łatwiej jest tu udzielić wskazówek.

W przypadku nowych wdrożeń oprogramowania (lub nowych systemów operacyjnych) zawsze używać bieżącej, najnowszej wersji oprogramowania, chyba że istnieje wyraźnie znane ograniczenie technologiczne, które to uniemożliwia — takie jak znane błędy lub niezgodności oprogramowania.

Oprogramowanie nie jest jak inne rodzaje produktów, szczególnie nie w dzisiejszym świecie internetowych wydań poprawek i aktualizacji. Zakładam, że mentalność, że stare wersje oprogramowania mogą być lepsze od bieżących, pochodzi z połączenia fizycznych produktów (zegarki, samochody, naczynia, meble, wino), gdzie określony rok lub model może być lepszy od nowszego modelu z różnych powodów, oraz ze starszych trybów dostarczania oprogramowania, gdzie got owe produkty były po prostu „rzucane przez ścianę” i stan końcowy był, po prostu, stanem końcowym bez żadnych rozsądnych możliwości aktualizacji, poprawek lub napraw. Żaden z tych przypadków nie dotyczy nowoczesnego oprogramowania biznesowego (z jedynie najrzadszymi wyjątkami).

Rozwój oprogramowania to mniej więcej kontinuum. Normalne procesy deweloperskie zakładają budowanie nowego oprogramowania na bazie starego, albo bezpośrednio (przez tworzenie aktualizacji istniejącej bazy kodu) albo pośrednio (przez przebudowę na podstawie wiedzy zdobytej podczas budowania poprzedniej wersji oprogramowania). Idea jest taka, że każda kolejna wersja oprogramowania jest lepsza od poprzedniej. Nie jest to oczywiście gwarantowane — istnieją takie pojęcia jak błędy regresji i po prostu zły development, ale ogólnie rzecz biorąc oprogramowanie poprawia się z czasem – szczególnie gdy mówimy o oprogramowaniu klasy korporacyjnej używanym w firmach i aktywnie rozwijanym. Nowe oprogramowanie to nie tylko kolejna faza starego oprogramowania, reprezentuje ono również, w niemal wszystkich przypadkach, aktualny stan poprawek, napraw błędów, aktualizacji i, gdy jest to konieczne, zmian podejścia lub techniki. Nowe oprogramowanie, pochodzące od firm dbających o jakość, jest niemal wyłącznie lepsze od starego. Oprogramowanie ewoluuje i dojrzewa.

Poza jakością samego oprogramowania istnieje koncepcja inwestowania w przyszłość. Oprogramowanie nie jest czymś, co można trzymać na półce w nieskończoność. Musi pozostawać, w pewnym stopniu, aktualne, albo przestaje działać, ponieważ platforma, na której działa, zmienia się, pojawia się jakiś nowy artefakt, odkrywane są luki bezpieczeństwa lub zmieniają się potrzeby. Instalowanie starego oprogramowania oznacza inwestowanie w przeszłość, inwestowanie w instalowanie, uczenie się, używanie i wspieranie starej technologii. Nazywa się to „długiem technicznym”. Ta stara technologia może trwać przez lata, a nawet dekady, ale stare oprogramowanie traci wartość z czasem i staje się coraz droższe do utrzymania zarówno dla dostawców, jeśli nadal je wspierają, jak i dla użytkowników końcowych, którzy muszą je obsługiwać.

Ta sama koncepcja długu technicznego dotyczy samych dostawców oprogramowania. Tworzenie oprogramowania wiąże się z bardzo dużymi kosztami, a szczególnie utrzymywanie wielu wersji tego oprogramowania. Dostawcy oprogramowania mają duże bodźce do ograniczania wsparcia dla starszych wersji, aby skupić zasoby na bieżących wydaniach (jest to główny powód popularności wdrożeń SaaS, gdzie dostawca kontroluje dostępne wersje i może eliminować starsze wersje poprzez aktualizacje). Jeśli klienci wymagają wsparcia dla starych wersji, koszty muszą być gdziedś pochłonięte i często są pochłaniane zarówno w postaci wpływu finansowego na wszystkich klientów, jak i zmniejszenia koncentracji na nowym produkcie, ponieważ zespoły deweloperskie muszą być podzielone na łatanie starych wersji i rozwijanie nowych.

W ramach tego, co już powiedziałem, ważne jest omówienie dojrzałości kodu. Często dojrzałość kodu jest podawana jako powód do wdrażania „starego kodu”, ale uważam, że jest to nieporozumienie IT w zakresie procesów tworzenia oprogramowania. Jeśli pomyślimy o wydanej linii kodu, tylko dlatego, że jest wydana i w użyciu, nie czyni jej bardziej dojrzałą. Kod nie zmienia się na wolności, po prostu tam siedzi. Jego dojrzałość jest „zablokowana” w dniu wydania. Jeśli jest łatany, to tak, „dojrzałby” po wydaniu. Późniejsze wersje tego samego oprogramowania, oparte na tej samej bazie kodu, ale bardziej aktualne, to naprawdę bardziej „dojrzały” kod, ponieważ został przejrzany, zaktualizowany, przetestowany itp. w większym stopniu niż wczesne wydanie tego samego kodu.

Jest to sprzeczne z intuicją, powiedzmy, w przypadku samochodów, gdzie każde wydanie jest świeżą rzeczą z nowymi możliwościami problemów mechanicznych i różnymi obawami dotyczącymi niezawodności — gdzie czekanie kilka lat daje szansę zobaczyć, jakie problemy z niezawodnością zostaną odkryte. Oprogramowanie nie jest takie. Tak więc koncepcja chęci posiadania bardziej dojrzałego oprogramowania skłaniałaby do wdrożenia „najnowszego i najlepszego” zamiast „sprawdzonego”.

Jeśli pomyślimy o numerach wersji oprogramowania jak o wiekach, staje się to jasne. Linux 3.1 jest znacznie starszy pod względem dojrzałości oprogramowania niż Linux 2.4. Ma dekadę dodatkowego rozwoju.

Użyćmy przykładu z prawdziwego świata, który jest dziś bardzo aktualny. Jesteś w firmie, która zamierza zainstalować swoje pierwsze serwery. Windows Server 2012 R2 właśnie zostało wydane. Czy powinieneś zainstalować Windows Server 2008, 2008 R2 (2010), Server 2012 czy Server 2012 R2 (koniec 2013)?

Dla wielu firm brzmi to jak rozmów o dwóch do czterech zupełnie różnych produktach, które prawdopodobnie mają różne powody, by wybrać każdy. Jest to, ogólnie rzecz biorąc, nieprawda. Każda nowsza wersja to po prostu ulepszenie, aktualizacja, poprawka i zwiększenie funkcji poprzedniej. Każda z kolei jest bardziej zaawansowana i dojrzała niż poprzednia. Każda nowa wersja korzysta z pracy wykonanej nad oryginalnym wydaniem swojego poprzednika, jak również z poprawek błędów, łatek i dodatków funkcji wykonanych w czasie między oryginalnym wydaniem a wydaniem następcy. Każde nowe wydanie jest w rzeczywistości „mniejszym wydaniem” poprzedniego. Jeśli spojrzymy na numery rewizji jądra zamiast marketingowych nazw wydań, może to mieć więcej sensu.

Windows Server 2008 był Windows NT 6.0. Windows Server 2008 R2 był Windows NT 6.1 — oczywiście mniejszą rewizją lub nawet „poprawką” poprzedniego wydania. Windows Server 2012 był Windows NT 6.2, a nasz obecny Windows Server 2012 R2 to Windows NT 6.3. Gdybyśmy używali numerów rewizji zamiast marketingowych nazw, brzmiałoby niemal szalenie celowe instalowanie starej, mniej dojrzałej, mniej zaktualizowanej i mniej łatanej wersji. Chcemy najnowszych aktualizacji, najnowszych poprawek błędów i najnowszych rozwiązanych problemów bezpieczeństwa.

W przypadku nowych wdrożeń oprogramowania, im nowsze zainstalowane oprogramowanie, tym lepsze możliwości wykorzystania najnowszych funkcji i więcej czasu przed nieuchronnym starzeniem się. Całe oprogramowanie starzeje się, więc instalowanie nowszego oprogramowania daje najlepszą szansę, że będzie trwało jak najdłużej. Zapewnia najlepszą elastyczność dla nieznanej przyszłości.

Podążanie za tym tokiem myślenia może prowadzić do wniosku, że wdrażanie wersji przedwydaniowych lub beta oprogramowania również miałoby sens. I choć mogą istnieć konkretne przypadki, gdzie ma to sens, takie jak „grupy testowe” sprawdzające oprogramowanie przed udostępnieniem go całej firmie, generalnie nie ma to sensu. Natura oprogramowania przedwydaniowego jest taka, że nie jest wspierane i może zawierać kod, który nigdy nie będzie wspierany. Używanie takiego kodu w izolacji może być korzystne, ale do ogólnego użytku nie jest zalecane. Istnieją ważne procesy, które są przestrzegane między wydaniami podglądu lub beta a finalnymi wydaniami kodu, niezależnie od poziomu dojrzałości całego produktu.

To prowadzi nas do drugiej sytuacji, w której aktualizujemy istniejące oprogramowanie. Jest to oczywiście zupełnie inny scenariusz niż świeża instalacja i wiele, wiele więcej czynników jest zaangażowanych.

Jednym z największych czynników w większości sytuacji jest licencjonowanie. Regularne aktualizowanie oprogramowania może wiązać się z opłatami licencyjnymi, które należy uwzględnić w równaniu korzyści i kosztów. Niektóre produkty, jak większość oprogramowania open source, nie mają tego kosztu i mogą być aktualizowane, gdy tylko dostępne są nowe wersje.

Innym naprawdę dużym czynnikiem przy aktualizowaniu oprogramowania jest ludzki koszt wysiłku aktualizacji — w przeciwieństwie do świeżej instalacji, gdzie wysiłek instalacji jest w zasadzie wyrównanym między starym a nowym oprogramowaniem. W rzeczywistości nowe oprogramowanie jest zazwyczaj łatwiejsze do zainstalowania niż stare, po prostu ze względu na ulepszenia i postępy. Utrzymywanie pojedynczej wersji oprogramowania przez dekadę oznacza, że zasoby nie były poświęcane w tym czasie na procesy ulepszania. Coroczne ulepszanie w tym czasie oznacza, że zasoby były używane dziesięć razy do przeprowadzenia oddzielnych aktualizacji. To sprawia, że aktualizacja jest znacznie trudniejsza do uzasadnienia kosztowego. Ale jest więcej niż tylko wysiłek samego procesu aktualizacji — jest też ciągłe szkolenie potrzebne użytkownikom końcowym, którzy będą zmuszeni doświadczać więcej zmian, częściej poprzez ciągłe aktualizacje.

Może to sprawiać, że aktualizowanie oprogramowania brzmi negatywnie, ale tak nie jest. Jest to po prostu równanie, gdzie każda strona musi być ważona. Regularne aktualizacje często oznaczają małe, przyrostowe zmiany zamiast dużych skoków, pozwalając użytkownikom końcowym naturalnie się adaptować. Regularne aktualizacje oznaczają, że procesy aktualizacji są często łatwiejsze i bardziej przewidywalne. Regularne aktualizacje oznaczają, że dług techniczny jest zawsze zarządzany, a korzyści z nowszych wersji — które mogą być funkcjami, wydajnościami lub ulepszeniami bezpieczeństwa — są dostępne wcześniej, co pozwala na ich dłuższe wykorzystanie.

Biorąc pod uwagę to, czego nauczyliśmy się z dwóch powyższych scenariuszy, istnieje jednak inny ważny wniosek do wyciągnięcia. Gdy zostanie podjęta decyzja o przeprowadzeniu aktualizacji, pytanie często brzmi: „do której wersji aktualizujemy?”. W rzeczywistości jednak każda aktualizacja wykraczająca poza standardowy proces łatania jest naprawdę jak miniaturowa decyzja zakupu „nowego oprogramowania” i logika, dlaczego „zawsze” instalujemy najnowszą dostępną wersję przy świeżej instalacji, ma tu również zastosowanie. Tak więc przy przeprowadzaniu aktualizacji prawie zawsze powinniśmy aktualizować tak daleko, jak możemy — miejmy nadzieję, do bieżącej wersji.

Stosując ponownie przykład Microsoft, możemy wziąć organizację, która ma dziś wdrożony Windows XP. Firma decyduje się zainwestować w cykl aktualizacji do nowszej wersji, nie tylko kontynuować łatanie. Istnieje kilka wersji platformy desktopowej Windows, które nadal są objęte aktywnym wsparciem Microsoft. Należą do nich Windows Vista, Windows 7, Windows 8 i Windows 8.1. Aktualizacja do jednej z mniej bieżących wersji skutkuje krótszym czasem do końca życia tej wersji, co zwiększa ryzyko organizacyjne; używanie starszych wersji oznacza dalsze inwestowanie w już stare technologie, co oznacza wzrost długu technicznego i mniejszy dostęp do nowych funkcji, które mogą okazać się korzystne po udostępnieniu. W tym konkretnym przykładzie nowsze wersje są również uważane za bezpieczniejsze i wymagają mniejszych zasobów sprzętowych.

Każda firma musi znaleźć odpowiednią równowagę dla siebie w zakresie cyklów aktualizacji istniejącego oprogramowania. Każda firma i każdy pakiet oprogramowania są inne. Oprogramowanie korporacyjne, takie jak Microsoft Windows, Microsoft Office czy Oracle Database, bardzo dobrze pasuje do tych modeli. Małe projekty oprogramowania i te zbliżające się do zakresu bespoke mogą mieć bardziej dynamiczny i nieprzewidywalny cykl wydań, ale generalnie nadal będą przestrzegać większości tych zasad. Rozważ zastosowanie empatii wobec procesu tworzenia oprogramowania, aby zrozumieć, jak ty i twój dostawca oprogramowania możecie najlepiej współpracować, aby dostarczyć największą wartość twojej organizacji, i połącz to ze swoją potrzebą redukcji długu technicznego, aby jak najlepiej wykorzystać inwestycję w oprogramowanie dla swojej organizacji.

Ale zasady ogólne są stosunkowo proste:

Przy wdrażaniu nowego lub aktualizacji dążyć do najnowszej rozsądnej wersji oprogramowania. Używać każdej okazji do wdrożenia, aby eliminować dług techniczny w jak największym stopniu.

Gdy oprogramowanie już istnieje, ważyć czynniki takie jak ludzki wysiłek, koszty licencji, spójność środowiska i testowanie zgodności wobec korzyści w zakresie funkcji, wydajności i długu technicznego.