Producent oprogramowania informatycznego a cykl wydań produktu

Produkt i projekt w pracy producenta oprogramowania

Producent oprogramowania informatycznego wykonuje dwa rodzaje pracy, które łatwo pomylić, bo w obu powstaje kod. Projekt wdrożeniowy ma termin oraz zakres, a kończy go protokół odbioru. Produkt nie ma daty końca: istnieje tak długo, jak jest utrzymywany, a jego kolejne wydania trafiają do wszystkich użytkowników według jednego planu.

Różnica ma skutki praktyczne. Zamawiający projekt płaci za wynik, który zostaje mu przekazany, natomiast użytkownik produktu płaci za dostęp do kolejnych wersji oraz za wsparcie. Ten sam producent prowadzi zwykle oba modele naraz: rdzeń programu jest produktem, a jego dopasowanie do firmy jest projektem.

Rdzeń wspólny i konfiguracja u klienta

Podział widać w opisie wersji Framework programu Studio WMS.net. Rdzeń aplikacji jest wspólny dla wszystkich magazynów, a wdrożenie włącza wybrane moduły i ustawia konfigurację. Program w wersji web działa na Microsoft ASP.NET i bazie SQL Server, o czym pisze strona o produkcie Studio WMS.net, więc jedna poprawka po stronie serwera obsługuje wielu użytkowników.

Z tego podziału wynika prosty test przy każdej zgłoszonej zmianie. Jeżeli zmiana dotyczy jednego klienta, trafia do konfiguracji albo do osobnego projektu. Jeżeli dotyczy wszystkich, wchodzi do planu wydań produktu.

Reguła: zmiana potrzebna jednemu klientowi nie zmienia rdzenia produktu, a zmiana rdzenia trafia do każdego klienta.

Wersjonowanie i numer wydania

Numer wersji i jego znaczenie

Numer wersji jest umową między producentem a użytkownikiem o tym, jak duża jest zmiana. Najczęściej stosuje się zapis trzech liczb rozdzielonych kropkami, opisany w zasadach semantycznego wersjonowania. Pierwsza liczba oznacza wydanie główne, druga podrzędne, a trzecia poprawkę, natomiast numer kompilacji wskazuje konkretny plik wynikowy.

• Wydanie główne - zmiana niezgodna wstecz, zwykle z migracją danych albo interfejsów.
• Wydanie podrzędne - nowa funkcja zgodna z poprzednią wersją.
• Poprawka - usunięcie błędu bez zmiany zachowania programu.
• Numer kompilacji - identyfikator konkretnego pliku wykonywalnego, potrzebny przy zgłoszeniu błędu.

Numer kompilacji ma znaczenie dopiero przy diagnozie. Gdy użytkownik zgłasza błąd, pierwsze pytanie brzmi, na której kompilacji się on pojawił, bo od tego zależy, czy poprawka już istnieje.

Wersja aplikacji a wersja schematu bazy

Program biznesowy ma dwie warstwy z własną numeracją: pliki aplikacji oraz schemat bazy danych. Rozdzielenie numerów pozwala sprawdzić przy starcie, czy aplikacja trafiła na zgodną bazę. Prosty mechanizm to tabela z zapisem każdej zastosowanej zmiany schematu. Poniższy skrypt jest przykładem mechanizmu, a nazwy tabel są przykładowe.

CREATE TABLE dbo.WersjaSchematu (
    Numer    varchar(20)  NOT NULL PRIMARY KEY,
    Wdrozono datetime2(0) NOT NULL DEFAULT SYSDATETIME(),
    Opis     nvarchar(200) NULL
);

IF NOT EXISTS (SELECT 1 FROM dbo.WersjaSchematu WHERE Numer = '3.2.0')
BEGIN
    ALTER TABLE dbo.Dokument ADD UwagiSerwisowe nvarchar(500) NULL;
    INSERT INTO dbo.WersjaSchematu (Numer, Opis)
    VALUES ('3.2.0', N'Pole uwag serwisowych w dokumencie');
END

Skrypt jest idempotentny: drugie uruchomienie niczego nie zmienia, bo zmiana ma już wpis w tabeli. Dzięki temu ten sam skrypt można bezpiecznie ponowić po przerwanej aktualizacji.

Gałęzie w repozytorium i wydanie

Numer wersji ma odpowiednik w repozytorium kodu. Rozwój nowych funkcji odbywa się w gałęzi głównej, a każde wydanie dostaje własną gałąź lub znacznik, który zamraża stan kodu na dzień publikacji. Poprawka błędu powstaje w gałęzi wydania, a potem trafia także do gałęzi głównej, żeby błąd nie wrócił w następnej wersji.

Ten układ ma konsekwencję dla klienta, który pozostaje przy starszej wersji. Może on dostać poprawkę bez nowych funkcji, bo gałąź wydania nie zawiera zmian z gałęzi głównej. Bez takiego rozdziału każda poprawka wymuszałaby przejście na najnowszą wersję razem z całym jej zakresem.

Rodzaje wydań i ryzyko wdrożenia

Nie każde wydanie niesie to samo ryzyko, więc nie każde wymaga tego samego procesu. Poprawka błędu może przejść skrócony test, natomiast wydanie zmieniające schemat bazy wymaga próby na kopii danych klienta.

Wersje web i desktopowe

Sposób dostarczenia wydania zależy od architektury. W aplikacji webowej aktualizuje się serwer, a użytkownicy dostają nową wersję przy następnym otwarciu przeglądarki. Aplikacja desktopowa wymaga aktualizacji na każdej stacji roboczej, co potwierdza opis wersji Framework, czyli aplikacji desktopowej dla Windows.

W praktyce producent utrzymuje dla wersji desktopowej kanał aktualizacji klienta i sprawdza zgodność wersji klienta z serwerem. Stacja z nieaktualnym klientem nie powinna zapisywać danych do bazy, która przeszła już migrację.

Reguła: wydanie główne nie trafia na produkcję bez próby migracji na kopii bazy klienta.

Notatki do wydania

Każde wydanie powinno mieć dokument, który odpowiada na pytania działu IT i użytkowników jeszcze przed instalacją. Minimalna treść to cztery elementy.

• Numer i data - wersja aplikacji i schematu oraz dzień publikacji.
• Zmiany funkcji - co dodano lub zmieniono z perspektywy użytkownika oraz co usunięto.
• Zmiany w bazie - nowe obiekty oraz migracje danych wraz z szacowanym czasem ich trwania.
• Znane ograniczenia - błędy przeniesione do następnego wydania wraz z obejściem.

Zgodność wsteczna interfejsów i integracji

Program biznesowy rzadko działa sam. Wymienia dane z systemem ERP, drukarkami etykiet albo aplikacjami przewoźników, a każda z tych integracji zakłada określony format komunikatu. Zmiana formatu w nowym wydaniu psuje integrację po stronie, której producent nie kontroluje, dlatego interfejsy wersjonuje się osobno od samego programu.

Jeżeli program udostępnia interfejs HTTP, numer wersji interfejsu umieszcza się w adresie. Starsza wersja pozostaje dostępna przez uzgodniony okres, a nowa działa równolegle, co daje integratorowi czas na zmianę. Poniższe wywołanie AJAX z biblioteką jQuery jest przykładem mechanizmu i nie opisuje rzeczywistego interfejsu produktu.

$.ajax({
    url: '/api/v2/dokumenty/1234',
    method: 'GET',
    dataType: 'json',
    headers: { 'X-Wersja-Klienta': '3.2.0' }
}).done(function (dokument) {
    console.log(dokument.numer);
});

Nagłówek z numerem wersji klienta pozwala po stronie serwera odróżnić zgłoszenia pochodzące ze starych instalacji i wskazać, które z nich trzeba objąć okresem przejściowym. Zmiana niezgodna wstecz, na przykład zmiana nazwy pola, wchodzi wyłącznie w wydaniu głównym i z wyprzedzeniem trafia do notatek.

Środowiska wydania i plan wycofania

Wydanie przechodzi najpierw przez środowisko deweloperskie, następnie przez testowe, a na produkcyjne trafia po zatwierdzeniu wyników testów. Środowisko testowe powinno mieć strukturę i wolumen danych zbliżone do produkcyjnych, bo błąd wydajności w migracji nie ujawnia się na pustej bazie. O organizacji takich prac w magazynie pisze strona o przebiegu wdrożenia systemu WMS.

Przed aktualizacją produkcyjnej bazy wykonuje się kopię pełną i sprawdza jej czytelność. Polecenie BACKUP z opcją CHECKSUM zapisuje sumy kontrolne stron, a RESTORE VERIFYONLY potwierdza, że plik da się odczytać. Składnię opisuje dokumentacja polecenia BACKUP w Microsoft Learn.

BACKUP DATABASE Magazyn
TO DISK = N'D:\Kopie\Magazyn_przed_3_2_0.bak'
WITH CHECKSUM, INIT;

RESTORE VERIFYONLY
FROM DISK = N'D:\Kopie\Magazyn_przed_3_2_0.bak'
WITH CHECKSUM;

Podział odpowiedzialności przy wydaniu

Wydanie angażuje trzy strony, a niejasny podział czynności jest częstą przyczyną opóźnień okna serwisowego. Poniższe zestawienie pokazuje typowy układ, który umowa może zmienić.

Testy akceptacyjne po stronie klienta

Testy producenta sprawdzają zgodność z założeniami technicznymi, ale nie zastępują testów zespołu, który zna własny proces. Przed wydaniem na produkcję klient przechodzi zestaw scenariuszy na środowisku testowym: zakłada dokument i zatwierdza go, a następnie drukuje wydruk i sprawdza raport wynikowy. Wynik zapisuje się w krótkim protokole, do którego można wrócić przy sporze o przyczynę błędu.

Scenariusze rosną razem z produktem. Po każdym błędzie, który przedostał się na produkcję, dodaje się jeden scenariusz odtwarzający ten przypadek, więc zestaw testowy klienta zbiera doświadczenie z kolejnych wydań.

Wycofanie wydania

Plan wycofania powstaje przed wydaniem, nie po awarii. Najprostsza ścieżka to przywrócenie kopii bazy oraz poprzednich plików aplikacji. Przywrócenie kosztuje jednak dane wprowadzone po aktualizacji, więc okno serwisowe ustawia się poza godzinami pracy operacyjnej.

Wycofanie samej aplikacji bez bazy działa tylko wtedy, gdy zmiana schematu była zgodna wstecz. Dodanie kolumny dopuszczającej wartość NULL takie wycofanie przeżyje, natomiast usunięcie kolumny albo zmiana typu danych już nie. Ta zależność jest powodem, dla którego producent w wydaniach podrzędnych unika zmian destrukcyjnych.

Wsparcie produktu po wydaniu

Diagnoza zgłoszenia i poprawka

Wsparcie produktu zaczyna się od klasyfikacji zgłoszenia, bo od niej zależy ścieżka i priorytet. Umowa SLA opisuje czas reakcji i czas usunięcia usterki dla każdej kategorii, a same wartości ustala się w umowie, nie w opisie produktu.

Monitoring środowiska

Część zgłoszeń da się wyprzedzić. SoftwareStudio opisuje w swojej ofercie całodobowy monitoring infrastruktury w systemie Zabbix, który obejmuje serwery fizyczne i wirtualne oraz urządzenia sieciowe, a także obciążenie łączy i warunki środowiskowe, na przykład temperaturę podzespołów. Alert o kończącym się miejscu na dysku bazy dociera wtedy przed pierwszym zgłoszeniem użytkownika.

Cykl życia wersji i koniec wsparcia

Każda wersja produktu przechodzi przez kilka etapów. Najpierw jest rozwijana i dostaje nowe funkcje, potem trafia do okresu utrzymania, w którym powstają wyłącznie poprawki błędów i luk bezpieczeństwa. Na końcu producent ogłasza koniec wsparcia i od tej daty nie przyjmuje zgłoszeń dotyczących tej wersji.

Klient powinien znać te terminy z wyprzedzeniem, bo od nich zależy plan aktualizacji własnej infrastruktury. Jeżeli wersja programu wychodzi z utrzymania, a firma nie może jej zmienić z powodu integracji, potrzebny jest osobny projekt migracji z budżetem i harmonogramem.

Zależność od platformy

Producent programu nie przedłuży wsparcia producenta platformy. Jeżeli program działa na bazie SQL Server w wersji objętej już tylko wsparciem rozszerzonym albo pozbawionej wsparcia, to poprawki bezpieczeństwa samej bazy nie powstają, niezależnie od jakości aplikacji. Przypadek starszej wersji bazy opisuje tekst o SQL Server 2008 w systemie magazynowym.

Z tego powodu polityka wsparcia produktu wymienia obsługiwane wersje Windows Server i SQL Server oraz wskazuje moment, od którego starsza platforma przestaje być obsługiwana przez nowe wydania.

Wybór między produktem a projektem

Wybór modelu zaczyna się od analizy przedwdrożeniowej, która pokazuje, jaka część procesów firmy mieści się w standardowych modułach. Jeżeli mieści się większość, kupuje się produkt z konfiguracją. Jeżeli proces jest wyjątkowy i stanowi o przewadze firmy, powstaje osobny projekt.

Różnice kosztowe opisuje tekst o licencji jednorazowej i abonamencie: cena zakupu jest tylko jedną z pozycji, do których należą też wdrożenie i szkolenia, a także utrzymanie i rozszerzenia. Wymagania techniczne produktu zbiera specyfikacja programu WMS.net dla działu IT, a ogólne zasady współpracy z wykonawcą opisuje strona o producencie oprogramowania.

Pytania do producenta przed zakupem

Przed podpisaniem umowy dział IT powinien uzyskać odpowiedzi na cztery pytania, które oddzielają produkt utrzymywany od projektu bez dalszej opieki.

• Plan wydań - jak często ukazują się wydania i czy poprawki pilne mają osobny tryb.
• Polityka wsparcia - ile wersji wstecz producent obsługuje i jak ogłasza koniec wsparcia.
• Ścieżka migracji - czy między wydaniami głównymi istnieje udokumentowana procedura przeniesienia danych.
• Notatki do wydań - czy zmiany w bazie i znane ograniczenia są opisane przed instalacją.

Utrzymanie i rozwój po wdrożeniu omawia osobny tekst o tworzeniu programów informatycznych, a porównanie z pokrewnym profilem wykonawcy znajduje się na stronie o producencie systemów informatycznych. Karta produktu jest dostępna także na stronie producenta, w zakładce aplikacji Studio WMS.net.