Wprowadzenie: Logistyka oprogramowania

System można dostosować na wiele sposobów. Wpływ na funkcje umożliwia m.in. aplikacja Obiekty deweloperskie. Te zmiany lub rozszerzenia mogą być dokonywane wyłącznie dla klientów indywidualnych lub grupowych, w zależności od tego, w jakim systemie deweloperskim mają miejsce modyfikacje.

Zintegrowana w systemie logistyka oprogramowania służy do transportu rozszerzeń i poprawek z jednego systemu do kolejnych systemów. Aktualizacje oprogramowania służą jako środek transportu.

Niniejszy artykuł opisuje możliwości, jakie oferuje logistyka oprogramowania. Przedstawia, w jaki sposób systemy są ze sobą powiązane i w jaki sposób aktualizacje oprogramowania przesyłane są z jednego systemu do drugiego.

Wymagania

Aby zrozumieć ten artykuł, wymagana jest podstawowa wiedza na temat obiektów deweloperskich i ich wersjonowania, a także zadań deweloperskich.

Definicje terminów

• Adaptacja — adaptacja to dostosowanie do istniejącego stanu systemu. Dodano nowe obiekty deweloperskie lub zmieniono istniejące obiekty deweloperskie. Funkcjonalności ze standardu są rozszerzane lub zmieniane.
• Rozwiązanie branżowe — rozwój u partnera obejmujący rozszerzenia umożliwiające dostosowanie do konkretnej branży. Z technicznego punktu widzenia rozwój u partnerów i rozwiązania branżowe nie różnią się od siebie.
• Aktualizacja kodu — aktualizacje kodu zawierają wszystkie metadane dotyczące transportowanych obiektów deweloperskich, a także skompilowanych klas Java. Aktualizacja kodu nie zawiera żadnych źródeł Java, tekstów ani źródeł pomocy.
• System deweloperski — systemu deweloperskie służą (nowemu) rozwojowi i adaptacji. Obiekty deweloperskie można zmieniać i tworzyć w systemach deweloperskich. System deweloperski zapewnia systemom dalszym aktualizacje oprogramowania.
• Eksport folderu — system zapisuje wyeksportowane aktualizacje oprogramowania w folderze /refreshes/export w katalogu semiramis
• Pomoc aktualizacja — pomoc aktualizacji zawiera źródła pomocy, które zostały zmienione w aktualizacji oprogramowania. Każdej aktualizacji kodu może towarzyszyć odświeżenie pomocy dla każdego języka. Ogólnie rzecz biorąc, źródła pomocy nie są dostarczane do dalszych systemów.
• Import folderu — pliki związane z aktualizacją oprogramowania są przed importem przechowywane w folderze /refreshes/import w katalogu semiramis
• System wewnętrzny — system Comarch ERP Enterprise, na którym aktywna jest usługa centralnego zlecenia deweloperskiego, nazywany jest także systemem wewnętrznym. Wewnętrzny system/system wsparcia służy do koordynowania i dokumentowania rozwoju oraz związanych z nim aktualizacji oprogramowania. W tym systemie tworzone są zgłoszenia serwisowe, zgłoszenia rozwojowe i dostawy wsparcia, a aktualizacje oprogramowania są udostępniane do pobrania dla systemów dalszych. System powinien obsłużyć te zadania dla wszystkich systemów. Dlatego generalnie potrzebny jest jedynie wewnętrzny system/system wsparcia.
• Rozwój u partnera — niespecyficzne dla klienta rozszerzenie lub adaptacja standardu systemu Comarch ERP Enterprise, które można dalej dostosowywać, m.in. B. rozwiązanie branżowe lub aplikacja
• System produkcyjny — system produkcyjny to system klienta do rzeczywistego działania. System ten zawiera prawdziwe dane klienta i jest ostatnim systemem, który otrzyma aktualizację oprogramowania.
• System zapewnienia jakości — system zapewnienia jakości to specjalny system testowania. Wszystkie aktualizacje oprogramowania pochodzące z wcześniejszych prac rozwojowych są importowane i testowane w tym systemie. System powinien zawsze zawierać najnowsze aktualizacje oprogramowania. Przykładowo, partner powinien zaimportować wszystkie aktualizacje oprogramowania ze standardowego rozwoju do swojego systemu testowego. W tym systemie może sprawdzić aplikacje, które są dla niego istotne. Jeżeli w systemach zawierających własne adaptacje wystąpi błąd, można za pomocą tego systemu sprawdzić, czy błąd jest już uwzględniony w normie. Wymaga to aktualnego poziomu aktualizacji oprogramowania, w przeciwnym razie nie zostanie rozpoznane, czy błąd został już wyeliminowany.
• Wydanie — wydanie ma dwa znaczenia:
  • Wydanie — to dostawa oprogramowania, która zawiera wszystkie niezbędne obiekty deweloperskie, określone komponenty oprogramowania i informacje, aby móc zainstalować nowy system ERP z zatwierdzonym, określonym statusem rozwoju. Ponadto wydanie zawiera niezbędne narzędzia i informacje do aktualizacji istniejącego systemu i doprowadzenia go do poziomu rozwojowego nowej wersji.
  • Wydanie — określony stan rozwoju zatwierdzony przez Comarch Software and Consulting AG nazywany jest wydaniem. Każde wydanie jest identyfikowane za pomocą unikalnej nazwy.
• Aktualizacja oprogramowania — jednostka logiczna, która transportuje wersje obiektów deweloperskich pomiędzy systemami. Dla każdej aktualizacji oprogramowania można utworzyć kilka plików: aktualizacja kodu (z końcówką .cr), aktualizacja źródła (.sr), a także aktualizacja pomocy (.hr) i aktualizacja tekstu (.tr) dla każdego języka. Każda aktualizacja oprogramowania może być jednoznacznie zidentyfikowana poprzez wydanie, identyfikator i repozytorium pochodzenia (prefiks eksportu, np. babel). Partnerzy mogą generować aktualizacje oprogramowania w celu dostarczania niestandardowych zmian i własnych standardowych rozszerzeń. Aktualizacje oprogramowania zawierają poprawki błędów i udoskonalenia dostarczane dla określonej wersji. Dla każdej wersji można utworzyć dowolną liczbę aktualizacji oprogramowania. Istnieją dwie klasy aktualizacji oprogramowania: kod systemowy (aktualizacje oprogramowania SYS) i kod aplikacji ( ­aktualizacje oprogramowania APP). Aktualizacje oprogramowania SYS obejmują obiekty deweloperskie z obszaru nazw com.cisag.pgm i com.cisag.sys, a także powiązane podobszary nazw z com.cisag.archive i com.cisag.nls. Wszystkie inne obiekty deweloperskie są transportowane wraz z aktualizacjami oprogramowania APP. W szczególności są to wszystkie obiekty deweloperskie, które nie zostały stworzone przez Comarch. W przeciwieństwie do aktualizacji oprogramowania APP, aktualizacje oprogramowania SYS nie zawierają obiektów deweloperskich klasy Java. Są one zawarte w kodzie systemowym w silniku systemowym.
• Aktualizacja źródła — aktualizacja źródła zawiera źródła Java zmienione w aktualizacji oprogramowania. Dla każdej aktualizacji kodu przypada maksymalnie jedna aktualizacja źródła. Licencja określa, czy w systemie można zainstalować aktualizacje źródła.
• Aktualizacja językowa — aktualizacja językowa to specjalna aktualizacja oprogramowania, która zawiera cały aktywny tekst dla danego języka
• System standardowy — system standardowy to system dostarczony przez Comarch lub system opracowany przez partnera, do którego nie wykonano jeszcze żadnych adaptacji
• Rodzina systemów — rodzina systemów to zbiór systemów Comarch ERP Enterprise, które mają ten sam poziom wydania. Sposób transportu aktualizacji oprogramowania jest ściśle określony w obrębie rodziny.
• Topologia systemu — wszystkie rodziny systemowe razem tworzą topologię systemu. Rodziny systemów w topologii systemu mogą mieć różne statusy wersji. W obrębie topologii systemów powinien istnieć dokładnie jeden system wewnętrzny, z którego korzystają wszystkie systemy należące do tej topologii systemów. Ponadto podział różnych komponentów instalacji, takich jak baza danych, serwer aplikacji systemu ERP, menedżer wyników systemu ERP itp., nazywany jest także topologią systemu.
• System testowy — rozwoju nie można prowadzić w systemie testowym, co oznacza, że obiektów deweloperskich nie można tam zmieniać ani tworzyć. System testowy testuje jedynie zainstalowane aktualizacje oprogramowania i powiązane z nimi zmiany lub poprawki. Co więcej, zainstalowane aktualizacje oprogramowania mogą zostać przekazane do dalszych systemów.
• Aktualizacja tekstu — aktualizacja tekstu zawiera teksty zmienione w aktualizacji oprogramowania. Dla każdej aktualizacji kodu może nastąpić aktualizacja tekstu dla każdego języka. Licencja określa, czy system może importować aktualizacje tekstu dla jakich języków.
• System nadrzędny/podrzędny — system b znajduje się poniżej systemu a, jeśli otrzymuje aktualizacje oprogramowania od a, a poziom wersjonowania b jest wyższy niż poziom wersjonowania a. I odwrotnie, a jest poprzedzone b. Jeśli aktualizacje oprogramowania są łączone w systemie nadrzędnym, poziom wersji tego systemu musi wynosić 7 i być skonfigurowany jako system testowy.

Opis

Topologia systemu

Kontekst środowiska składa się z zestawu systemów deweloperskich i testowych. Systemy deweloperskie mają rosnący poziom wersjonowania. Systemy testowe są zwykle dostarczane z aktualizacjami oprogramowania z systemów deweloperskich i zawsze mają poziom wersji 7.

Im wyższy poziom wersjonowania systemu deweloperskiego, tym bardziej szczegółowy jest jego cel. System deweloperski na poziomie wersji 6 zawiera rozwiązania specjalnie dostosowane do klienta. Dlatego systemy te nazywane są także systemami deweloperskimi klienta. Systemy z poziomem wersjonowania 3 nazywane są systemami rozwoju branżowego, ponieważ zawierają rozwiązania przeznaczone do użytku dla więcej niż jednego klienta. Poziomy wersji 4 i 5 można wykorzystać do dalszego mapowania strukturalnego, np. system wyższego poziomu można skonfigurować na poziomie 3, który zapewnia ogólne funkcjonalności, podczas gdy dostosowanie do konkretnej branży odbywa się tylko na poziomie 4 lub 5. Możliwe jest również stworzenie rozwoju klienta na poziomie 5 i udostępnienie klientowi własnego systemu deweloperskiego na poziomie 6. Przeznaczenie i nazwa systemu mają znaczenie drugorzędne. Jedyną ważną rzeczą jest to, że systemy rozwoju są ułożone w kolejności rosnącej.

Po każdym systemie deweloperskim może nastąpić jeden lub więcej systemów testowych. Maksymalnie jeden z nich może znajdować się w łańcuchu dostaw, tj. H. Wszystkie aktualizacje oprogramowania systemu deweloperskiego muszą zostać zaimportowane do systemu testowego i wyeksportowane, aby mogły dotrzeć do systemu znajdującego się poniżej systemu testowego. Oprócz możliwości przeprowadzania testów w systemie testowym niezależnie od aktualnego stanu systemu deweloperskiego, na tych systemach można podsumowywać aktualizacje oprogramowania. Oznacza to, że możliwa jest konwersja wielu zaimportowanych aktualizacji oprogramowania w jedną wyeksportowaną aktualizację oprogramowania. Należy wówczas zaimportować do kolejnego systemu tylko jedną lub mniejszą liczbę aktualizacji oprogramowania.

Systemy tworzenia aplikacji zawsze mają poziom wersjonowania 2. W przeciwieństwie do innych systemów tworzenia aplikacji, do systemu tworzenia aplikacji można również importować aktualizacje oprogramowania z wyższych poziomów wersjonowania (do poziomu wersjonowania 5 włącznie). Aplikacje utworzone za pomocą tego systemu można importować wyłącznie do systemów rozwoju klienta (poziom wersji 6), które mają co najmniej tę samą wersję oprogramowania, co system tworzenia aplikacji. Dzięki temu jest to możliwe np B. stworzyć aplikację w oparciu o rozwój branży. Aplikację można importować wyłącznie do systemów deweloperskich klienta dostarczonych przez ten system rozwoju branży.

Klasyfikacja systemów

Systemy w hierarchii można podzielić na różne klasy:

• System deweloperski — obiekty deweloperskie można zmieniać i tworzyć w systemie deweloperskim. System deweloperski zaopatruje systemy niższego szczebla w rozwiązania deweloperskie.
• System tworzenia aplikacji — aplikacje można zmieniać i tworzyć w systemie tworzenia aplikacji. System tworzenia aplikacji zasila dalszy system testowania aplikacji.
• System testowy lub system produkcyjny — za pomocą tych systemów nie można prowadzić żadnych prac deweloperskich, tj. tj. obiektów deweloperskich nie można zmieniać ani tworzyć. System testowy testuje jedynie zainstalowane aktualizacje oprogramowania i powiązane z nimi zmiany lub poprawki. Co więcej, zainstalowane aktualizacje oprogramowania mogą zostać przekazane do dalszych systemów. Prawdziwa praca odbywa się w systemie produktywnym.

Aktualizacja oprogramowania

Tworzenie aktualizacji oprogramowania

Nowo utworzona aktualizacja oprogramowania ma status Otwarta. Zwykle przechodzi następnie przez statusy Zwolnione i Wyeksportowane. Dopóki aktualizacje oprogramowania są otwarte, można dodawać kolejne obiekty deweloperskie. Po aktywowaniu zadania deweloperskiego automatycznie generowana jest nowa aktualizacja oprogramowania, jeśli nie istnieje żadna aktualizacja oprogramowania, która jest otwarta i powstała w wyniku zadania deweloperskiego dla tego samego zlecenia deweloperskiego.

Wszystkie wersje obiektów deweloperskich w zadaniu deweloperskim są powiązane z tą nową aktualizacją oprogramowania lub znalezioną aktualizacją oprogramowania. Ogólnie rzecz biorąc, wszystkie zadania deweloperskie i zawarte w nich obiekty deweloperskie, które odnoszą się do zlecenia deweloperskiego, są łączone w aktualizację oprogramowania. Jeżeli aktualizacja oprogramowania dla zlecenia deweloperskiego została już wydana, dla tego zlecenia deweloperskiego tworzona jest nowa aktualizacja oprogramowania.

Wszystkie zadania deweloperskie otrzymują odniesienie do przypisanej aktualizacji oprogramowania. Oznacza to, że nie można przypisać dwóch różnych aktualizacji oprogramowania do zadania deweloperskiego.

Po wygenerowaniu aktualizacji oprogramowania można ją udostępnić. W tym stanie w ramach zadań deweloperskich nie można przypisywać do aktualizacji oprogramowania dalszych obiektów deweloperskich.

Po zatwierdzeniu aktualizacja oprogramowania zostaje wyeksportowana. Ten proces powoduje odświeżenie kodu, odświeżenie źródła, odświeżenie tekstu i odświeżenie pomocy.

Kolejność instalacji aktualizacji oprogramowania

Podczas instalowania aktualizacji oprogramowania w innych systemach należy zapewnić spójność metadanych. Oznacza to, że nie można importować obiektów deweloperskich zależnych od obiektów deweloperskich, które jeszcze nie istnieją w systemie lub nie są importowane. W przypadku niektórych typów obiektów deweloperskich poprzednie wersje są również obowiązkowe podczas importu.

Zależności pomiędzy aktualizacjami oprogramowania ustalane są w systemach deweloperskich poprzez dowód użytkowania. Jeśli obiekt deweloperski korzysta z innych obiektów deweloperskich, sprawdzane jest, do jakich aktualizacji oprogramowania są przypisane obiekty deweloperskie. Na tych aktualizacjach oprogramowania tworzona jest zależność.

Dla niektórych obiektów deweloperskich w systemie wymagane są także poprzednie wersje. Aktualizacje oprogramowania uzależniają się zatem od aktualizacji oprogramowania, w których znajdują się poprzednie wersje.

Zależności techniczne są tworzone automatycznie po aktywowaniu zadania deweloperskiego.

Dodatkowo zależności można dodać ręcznie. Zazwyczaj opierają się one na kontekstach technicznych. Dodawanie i usuwanie zależności biznesowych jest możliwe tylko pod warunkiem, że nie została wydana aktualizacja oprogramowania. Podczas instalowania aktualizacji oprogramowania sprawdza, czy w systemie znajdują się już wszystkie bezpośrednio zależne aktualizacje oprogramowania. Jeśli tak nie jest, należy również zaimportować zależne aktualizacje oprogramowania. Zależności nie są sprawdzane rekurencyjnie. Oznacza to, że w przypadku dodania zależnych aktualizacji oprogramowania określane są również ich zależności. Może to spowodować, że dodane aktualizacje oprogramowania będą generować nowe komunikaty o błędach zależności.

Zależności są również sprawdzane po wydaniu aktualizacji oprogramowania. Jest to możliwe tylko wtedy, gdy wydano również zależne aktualizacje oprogramowania.

Oprócz zależności, ­ze względów technicznych może być wymuszana stała kolejność instalacji w przypadku aktualizacji oprogramowania systemowego. Aktualizacje oprogramowania o ustalonej kolejności instalacji są zawsze instalowane pojedynczo, w określonej kolejności.

Stała kolejność instalacji stosowana jest wyłącznie w przypadku zmian w kodzie systemu Comarch ERP Enterprise. W przypadku adaptacji nie jest wymagane egzekwowanie ustalonej kolejności montażu.

Modyfikacja klas Java

Za pomocą aktualizacji oprogramowania zmodyfikowane klasy Java są przekazywane partnerom lub klientom w postaci skompilowanej i, jeśli to możliwe (partner nie wprowadził żadnych zmian), są aktywowane w systemie docelowym bez rekompilacji. Działa to tylko wtedy, gdy zmodyfikowane klasy są kompatybilne. Programiści muszą zatem przestrzegać następujących konwencji:

• Usuwanie lub zmienianie nazw stałych, metod, instancji i zmiennych klas, które są publiczne lub chronione, jest niedozwolone
• Zmiana interfejsów jest niedozwolona — nie można również usunąć metody
• Zmiana podpisów metod, które są publiczne lub chronione, jest zabroniona
• W przypadku stałych, które są publiczne lub chronione, wartości nie można zmieniać
• Klasy i metody, które są publiczne lub chronione, nie mogą zostać później uznane za ostateczne

Eksport i historia aktualizacji oprogramowania

Jeśli aktualizacje oprogramowania zostaną zaimportowane do systemu, po instalacji można je ponownie wyeksportować. Wyeksportowane aktualizacje oprogramowania można następnie zaimportować do systemów dalszych.

W systemach poziomu 7 aktualizacje oprogramowania nie są generowane automatycznie. W tych systemach, w zależności od przeznaczenia, aktualizacje oprogramowania można łączyć w nowe aktualizacje oprogramowania lub zaimportowane aktualizacje oprogramowania można dystrybuować do innych systemów.

Historia jest zapisywana podczas eksportowania i podsumowywania aktualizacji oprogramowania. Można to wykorzystać do śledzenia, które aktualizacje oprogramowania spowodowały bieżącą aktualizację oprogramowania. Historia jest dostarczana i dostępna także w systemie docelowym.

Konflikty podczas instalacji aktualizacji oprogramowania

Niektóre typy obiektów deweloperskich można zmieniać w systemie deweloperskim, nawet jeśli zostały utworzone w systemie nadrzędnym, tworząc gałęzie. Potrzeba tworzenia oddziałów wynika z następujących przypadków: naprawiania błędów i dostosowywania standardowego systemu przez partnerów. Jeżeli importowany jest obiekt deweloperski, dla którego istnieje oddział w tym systemie, pojawia się konflikt. Zadanie deweloperskie do obsługi konfliktów jest tworzone automatycznie, patrz poniżej.

Poniższy przykład przedstawia historię zmian obiektu deweloperskiego, który został utworzony w Comarch ERP Enterprise Standard w rozwoju w systemie partnerskim dla branży:

Wszystkie aktualizacje oprogramowania zawierające obiekty deweloperskie powodujące konflikt zostaną dostarczone jako aktualizacja oprogramowania z systemu deweloperskiego wraz z wersjami powodującymi konflikt. Tylko w ten sposób można mieć pewność, że regulacje zostaną zaimportowane do kolejnych systemów wraz z zaimportowanymi aktualizacjami oprogramowania.

Pliki aktualizacji oprogramowania

Aktualizacja oprogramowania zapisywana jest w formie pliku ZIP. Obejmuje to odświeżenie kodu, odświeżenie źródła, odświeżenie tekstu i, jeśli to konieczne, odświeżenie pomocy. Warunkiem utworzenia pliku jest wydanie aktualizacji oprogramowania. Tworzenie pliku można powtarzać tak często, jak to konieczne. Jest to nadal możliwe w późniejszym terminie, pod warunkiem, że w wyniku reorganizacji archiwum nie zostały usunięte żadne metadane wymagane do utworzenia.

Nazwy plików pochodzą z aktualizacji oprogramowania:
Format: <exportprefix>-<release>-<codeClass>-<id>.zip
np.: Np. babel-5.1.0-app-RFR-123456

Zakończenia plików w nim zawartych są następujące:

Plik aktualizacji kodu zawiera opis aktualizacji oprogramowania (definicję odświeżenia kodu), informację, do której wersji należy ta aktualizacja, listę wersji obiektów deweloperskich (ObjectDirEntry i Version) oraz powiązane metadane z tabel archiwum. Może także zawierać listę zależności od innych aktualizacji kodu, które należy zainstalować przed lub razem z tą aktualizacją kodu. Zależności te dotyczą tylko pliku aktualizacji kodu, a nie pełnej aktualizacji oprogramowania. Pliki Source Refresh, Text Refresh i Help Refresh zależą tylko od powiązanego pliku Code Refresh.

Oprócz zależności aktualizacje oprogramowania mogą zawierać dodatkowe informacje instalacyjne:

• Aktualizacje oprogramowania, niezależnie od ich zawartości Neustart, mogą wymusić jeden z systemów, w którym są zainstalowane
• Aktualizacje oprogramowania mogą wymuszać stałą kolejność instalacji. Różne aktualizacje oprogramowania o ustalonej kolejności instalacji nie są instalowane razem
• Aktualizacje oprogramowania mogą wymagać ręcznego wykonania zadań po instalacji

W przypadku obiektów deweloperskich klasy Java plik odświeżania kodu zawiera tylko skompilowane pliki klas. Źródła znajdują się w pliku odświeżania źródła. Teksty obiektów deweloperskich i dokumentów pomocy zawartych w aktualizacji oprogramowania (z wyłączeniem źródeł pomocy) znajdują się w plikach aktualizacji tekstu specyficznych dla języka. Źródła pomocy są przechowywane oddzielnie w plikach aktualizacji pomocy. System może instalować teksty źródłowe lub specyficzne dla języka tylko wtedy, gdy posiada licencję na kod źródłowy lub język jest objęty licencją.

Jeśli obiekty biznesowe zawierają identyfikatory GUID użytkownika, nie są one zastępowane zerowym identyfikatorem GUID. Jeżeli użytkownik nie jest znany w systemie docelowym (np. użytkownik z rozwoju Comarch ERP Enterprise Standard u partnera), to na interfejsie wyprowadzany jest pusty ciąg znaków. Jeśli jednak aktualizacja oprogramowania zostanie zainstalowana we własnym systemie (rozproszony system deweloperski), informacje te nie zostaną utracone.

Podsumowanie aktualizacji oprogramowania

W systemach poziomu 7 możliwe jest połączenie kilku zainstalowanych aktualizacji oprogramowania w jedną aktualizację oprogramowania, zgodnie z określonymi aspektami treści. Zapobiega to dostarczaniu wielu małych aktualizacji oprogramowania do kolejnych systemów, a raczej wielu dużych aktualizacji oprogramowania dla określonego kontekstu. Dzięki temu aktualizacje oprogramowania, które pasują do siebie pod względem treści, tworzą jedną całość. W ramach dostawy aktualizacje oprogramowania są powiązane z dostawami wsparcia. Więcej informacji można znaleźć w artykule Dostawy wsparcia.

Podczas łączenia odbudowywane są także zależności pomiędzy aktualizacjami oprogramowania.

Poniższy przykład wyjaśnia strukturę zależności:

Aktualizacja oprogramowania A jest zależna od aktualizacji oprogramowania B, a aktualizacja oprogramowania B jest zależna od aktualizacji oprogramowania C. Jeśli aktualizacja oprogramowania A i aktualizacja oprogramowania B są połączone w aktualizację oprogramowania A’, aktualizacja oprogramowania C musi albo zostać uwzględnione w aktualizacji oprogramowania A’ lub stać się jedną z innych aktualizacji oprogramowania. Jeżeli aktualizacja oprogramowania C jest połączona z aktualizacją oprogramowania C’, wówczas aktualizacja oprogramowania A’ jest zależna od aktualizacji oprogramowania C’.

Wyłączanie aktualizacji oprogramowania

W pewnych okolicznościach aktualizacje oprogramowania typu importowego można wyłączyć lub całkowicie usunąć z systemu. Każda zaimportowana aktualizacja oprogramowania jest przechowywana w systemie tymczasowo lub na stałe. Tymczasowe aktualizacje oprogramowania można wyłączyć i usunąć, natomiast stałych aktualizacji oprogramowania nie można już wyłączyć ani usunąć. Jeśli dezaktywowana aktualizacja oprogramowania zawiera wersje obiektów deweloperskich, które były aktywne w systemie przed dezaktywacją, aktywowana wcześniej wersja zostanie ponownie aktywowana. Po wyłączeniu aktualizacji oprogramowania system zachowuje się tak, jakby aktualizacja oprogramowania nie została zainstalowana.

Obiekty deweloperskie zawarte w aktualizacji oprogramowania określają, czy aktualizacja oprogramowania może zostać tymczasowo zapisana. Aktualizacje oprogramowania obejmujące obiekty biznesowe, widoki, aktualizacje danych lub określone aktualizacje plików stają się trwałe natychmiast po instalacji.

Tymczasowe aktualizacje oprogramowania automatycznie stają się trwałe w pewnych okolicznościach:

• Kiedy stała zależy od tymczasowej aktualizacji oprogramowania
• Gdy obiekt deweloperski zawarty w tymczasowej aktualizacji oprogramowania jest uwzględniony w zadaniu deweloperskim
• Po reorganizacji informacji o wersji tymczasowej aktualizacji oprogramowania
• Gdy obiekt deweloperski zawarty w tymczasowej aktualizacji oprogramowania jest uwzględniony w zadaniu deweloperskim

Wyłączone aktualizacje oprogramowania pozostają w systemie i zostaną ponownie włączone po zainstalowaniu kolejnej aktualizacji oprogramowania.

Aktualizacje językowe

Aktualizacje językowe zawierają cały tekst w danym języku dla wszystkich obiektów deweloperskich w systemie, w którym utworzono aktualizacje językowe. Aktualizacje językowe umożliwiają modernizację języka wyświetlania w systemie. Podczas instalowania aktualizacji językowej nie ma konfliktów ani zależności. Jeśli w systemie z nowszą wersją utworzono aktualizację językową, wówczas teksty, dla których powiązany obiekt deweloperski nie jest jeszcze dostępny w systemie, nie zostaną w systemie zainstalowane. Jeśli aktualizacja językowa zostanie utworzona w systemie ze starszą wersją, po imporcie może brakować najnowszych tekstów. W dowolnym momencie można ponownie zainstalować brakujące teksty, instalując nowszą, kompletną aktualizację językową.

Aktualizacje językowe nie powodują utworzenia importowanej aktualizacji oprogramowania podczas instalacji, więc aktualizacji językowych nie można wyłączyć.

Jeśli w języku, który ma zostać wyeksportowany, w systemie deweloperskim partnera lub klienta istnieją niestandardowe teksty, wówczas oprócz aktywnych tekstów, wraz z aktualizacją językową zostaną wyeksportowane również niestandardowe teksty. Dzięki temu wszystkie teksty z systemu źródłowego będą dostępne także w systemie kolejnym. Dostosowane teksty są importowane do kolejnego systemu jako teksty adaptowane.

Zmiany w wydaniach i równoległa praca kilku wydań

W przypadku standardowego rozwoju aktualizacje oprogramowania są dostarczane nie tylko dla bieżącej wersji, ale także dla utrzymywanych poprzednich wersji. Dla każdego wydania istnieje oddzielny system dostarczania w ramach standardowego rozwoju.

Aby móc przeprowadzić zmianę wersji, system musi osiągnąć minimalny poziom. Informacje na ten temat zawarte są w dokumentacji dołączonej do wydania.

Zmiana wydania na kolejne wydanie odbywa się poprzez zainstalowanie aktualizacji oprogramowania należących do kolejnego wydania. Zmiana wydania rozpoczyna się od zainstalowania pierwszej aktualizacji oprogramowania będącej częścią kolejnej wersji. Zmiana wydania kończy się instalacją ostatniej aktualizacji oprogramowania, która jest częścią odpowiedniej dostawy. Po rozpoczęciu zmiany wersji nie można już instalować aktualizacji oprogramowania ze starej wersji.

Możliwości zmiany wersji

Zmiana wydania jest możliwa po osiągnięciu minimalnego poziomu. Należy pamiętać, że kolejne wydanie zawiera co najmniej te same poprawki i rozszerzenia. Jeśli poprawka zostanie dostarczona w danej wersji, zostanie ona również uwzględniona i dostarczona w kolejnych wydaniach, jeśli zajdzie taka potrzeba. Ze względu na harmonogram i rozłożone daty dostaw, korekta nie jest dostępna we wszystkich wersjach jednocześnie. Zasadą jest, że wersja poprawkowa kolejnego wydania musi być co najmniej o dwie wersje poprawkowe nowsza, biorąc pod uwagę datę dostarczenia poprawki.

W przypadku systemu oznacza to, że nie można importować najnowszej wersji bieżącego systemu przed zmianą wydania, w przeciwnym razie istnieje ryzyko, że zmiana wydania nie będzie możliwa. Należy o tym szczególnie pamiętać przy zmianie kilku wydań. Tutaj okresy się sumują.

System dostarczany w ramach standardu

Zasadniczo dostępne są dwa podejścia.

Wariant 1: Utrzymanie topologii systemu

Topologia systemu może zostać pozostawiona bez zmian:

Udostępnienie zmiany bez zmiany topologii systemu

W tym przypadku zmienia się niewiele. Konieczna jest jedynie zmiana ograniczeń importu oraz instalacja licencji następczej. Dotyczy to wszystkich systemów, w których wprowadzono niewiele adaptacji i które mogą zostać łatwo przeniesione na nowe wydanie.

Wariant 2: Utworzenie systemu równoległego

W drugim wariancie istniejący system zostaje zduplikowany. Następnie oba systemy działają równolegle.

Ten wariant znajduje zastosowanie w dwóch przypadkach:

• gdy system jest np. rozwiązaniem branżowym, które obsługuje wiele systemów klienckich, a nie ma możliwości przeniesienia wszystkich następczych systemów produkcyjnych na nowe wydanie,
• gdy istnieje wiele adaptacji. W takim przypadku uruchamiany jest drugi system i podnoszony do nowego wydania. Następnie w nowym wydaniu przeprowadzane są prace końcowe (zadania związane z konfliktami, testy). Po zakończeniu tych prac możliwe jest przełączenie ścieżki transportu dla systemów docelowych, które mają przejść na nowe wydanie. Więcej informacji można znaleźć w rozdziale Rozwój branżowy z następczą adaptacją klienta.

Równoległe działanie systemu deweloperskiego w dwóch wydaniach

Kopiowanie systemu poprzedzającego i systemu docelowego

Scenariusz 2. System poprzedni został skopiowany. Istnieją dwa systemy poprzednie: jeden w stanie wydania n, a drugi w stanie wydania n+1.

Ten scenariusz zapewnia możliwie największą elastyczność. Umożliwia podejmowanie decyzji na kilku etapach dotyczących momentu zastąpienia danego wydania. Rozwój branżowy (również dwustopniowy) oraz adaptacja klienta są równolegle utrzymywane w kilku wydaniach. Adaptacja klienta może być jednocześnie utrzymywana i dostosowywana w drugim systemie do nowego wydania.

Rozwój systemu branżowego z adaptacjami klientów

Pełny scenariusz aż do systemu produkcyjnego

Gdy tylko dostosowanie klienta zostanie w pełni podniesione do nowego wydania i wszystkie prace końcowe oraz testy zostaną zakończone (moment T3), wsparcie systemu produkcyjnego może odbywać się poprzez nowe wydanie. Od tego momentu system dostosowania klienta na starym wydaniu nie jest już potrzebny i może zostać usunięty.

Brak zmian w topologii

Zmiana wydania przez system poprzedzający

Najprostszy przypadek występuje wtedy, gdy system poprzedzający zmienia swoje wydanie, a więc nie jest tworzony nowy system. Nie trzeba nic zmieniać w topologii systemu. Zmienia się jedynie wydanie aktualizacji oprogramowania, które eksportuje system poprzedzający. Przypadek ten jest istotny dla:

• dostosowań klienta za systemem rozwoju partnerskiego, który został podniesiony do nowego wydania,
• systemów produkcyjnych za dostosowaniem klienta lub za systemem rozwoju branżowego, jeśli ten został podniesiony do nowego wydania.

Dla systemów, które są zasilane bezpośrednio ze standardu, ten scenariusz nigdy nie ma zastosowania. W takim przypadku zawsze zmienia wydanie system poprzedzający.

W systemie docelowym należy jedynie zainstalować odpowiednią licencję i ewentualnie dostosować ograniczenia importu. Poza tym wszystko działa tak samo, jak we wcześniejszych wydaniach.

Pojedyncza zmiana topologii

Zmiana wydania przez system poprzedzający

Jest to scenariusz dla rozwoju branżowego z następującymi po nim dostosowaniami klienta. Rozwój branżowy zostaje podzielony na dwa równoległe systemy deweloperskie. Następujące po nim systemy dostosowania klienta są w dowolnym momencie przełączane na nowe wydanie. Moment ten (T) może być dowolnie wybrany dla każdego systemu dostosowania klienta. Dzięki temu możliwe jest:

• przeprowadzenie zmiany wydania w systemie rozwoju branżowego i jednoczesne dalsze zaopatrywanie systemów klienta w poprawki i rozwój ze starego wydania, oraz
• ustalenie dla każdego klienta własnego terminu zmiany wydania.

Stary system rozwoju branżowego może zostać usunięty, gdy tylko wszystkie następujące po nim systemy produkcyjne zostaną przeniesione na nowe wydanie.

To nie działa

Scenariusz, który nie działa

Dla każdego systemu musi istnieć system poprzedzający, który ma to samo wydanie. Nie można równolegle utrzymywać systemów dostosowania klienta, a jednocześnie nie utrzymywać równolegle systemów branżowych. To samo dotyczy systemów rozwoju branżowego. Jeśli mają być utrzymywane równolegle, należy również równolegle utrzymywać poprzedzający system QA, z którego te systemy są zasilane.

Tworzenie systemu z kopii

Duplikowanie (deweloperskiego) systemu zawsze obejmuje kopię systemu deweloperskiego oraz powiązanego systemu testowego. Na ilustracjach, dla uproszczenia, przedstawiany jest tylko cały system. Jeśli użytkownik duplikuj pierwszy system deweloperski, musi również zduplikować swój system QAS.

Przy tworzeniu systemu z kopii należy zwrócić uwagę na kilka wymagań wstępnych. Dotyczą one stanu systemu, który jest kopiowany, jak również kilku zasad dla systemu, który jest tworzony.

Dla systemu, który jest kopiowany, obowiązują następujące zasady:

• Wszystkie zadania deweloperskie muszą być aktywowane.
• Wszystkie aktualizacje oprogramowania muszą być wyeksportowane.
• Wszystkie procesy instalacyjne muszą zostać pomyślnie zakończone.

Dla kopii obowiązują następujące zasady:

• Lista identyfikacyjna musi zostać usunięta (wrkidysrv –delIdyLst).
• System musi używać tej samej listy identyfikacyjnej, co system, z którego powstał.
• Po instalacji nowego wydania lista identyfikacyjna może zostać skopiowana do nowego systemu za pomocą cpyIdyLst.

Jeśli nowy system ma:

• wymieniać obiekty deweloperskie ze starym systemem,
• mieć możliwość odczytu baz danych OLTP starego systemu,
• lub później obsługiwać ten sam system następczy,

to systemy muszą korzystać z tej samej listy tożsamości.

Jeśli w utrzymaniu znajduje się kilka wydań tego samego systemu (równoległy rozwój), to systemy te muszą bezwzględnie używać tej samej listy identyfikacyjnej. Dotyczy to również sytuacji, gdy utrzymywanych jest trzy lub więcej wydań tego samego systemu. Wszystkie systemy muszą uzyskiwać dostęp do tej samej listy identyfikacyjnej.

Równoległe utrzymanie

Możliwość równoległego uruchamiania lub utrzymywania dwóch wydań albo kilku aplikacji powoduje konieczność synchronizacji poprawek lub rozwoju na obu systemach. W większości przypadków będą przejmowane poprawki ze starego wydania (wydanie n) do nowego wydania (n+1). Odbywa się to za pomocą usługi deweloperskiej, która przy aktywowaniu zadania blokuje w systemie następczym obiekty deweloperskie zawarte w zadaniu i przenosi ich zawartość, jeśli obiekt deweloperski w systemie docelowym nie został jeszcze zmodyfikowany. Usługa deweloperska jest w równoległym utrzymaniu bezwzględnie wymagana. Przenosi ona np. informacje potrzebne do zmiany wydania dotyczące schematów obiektów biznesowych.

Porównanie zawartości w usłudze deweloperskiej

Podczas przenoszenia obiektu deweloperskiego z jednego systemu do następnego sprawdzane jest, czy obiekt deweloperski został zmodyfikowany w systemie docelowym. W tym celu aktywna wersja w systemie źródłowym porównywana jest z wersją zablokowaną w systemie docelowym albo – jeśli nie istnieje wersja zablokowana – z wersją aktywną w systemie docelowym. Jeżeli wersja w systemie docelowym nie została zmieniona względem wersji w systemie źródłowym, zawartość wersji zostaje również przeniesiona. Porównanie zawartości zapewnia, że treść obiektu deweloperskiego, który został kilkakrotnie zmodyfikowany w systemie źródłowym, zostanie za każdym razem przeniesiona do systemu docelowego, jeśli w systemie docelowym uwzględniono jedynie zmiany ze źródła.

To porównanie zawartości zestawia właściwości techniczne obiektu deweloperskiego. Obiekty deweloperskie, które wyglądają identycznie, mogą mimo to się różnić. Na przykład raport, który został jedynie otwarty i zapisany bez zmian, może zostać rozpoznany jako zmieniony, ponieważ Crystal Reports przy tym może zmodyfikować dokument. W przypadku klas Java porównywane są wyłącznie źródła. Formatowania i informacje o rewizjach są wcześniej w miarę możliwości usuwane. Mimo to może się zdarzyć, że dwa źródła różniące się jedynie formatowaniem zostaną rozpoznane jako zmienione.

W aplikacji Obiekty deweloperskie, na zakładce Informacja, wyświetlana jest informacja, z której wersji powstała wersja zablokowana, jeśli została ona zablokowana w wyniku równoległego utrzymania.

Równoległe utrzymanie w rozwoju aplikacji

Zasadniczo równoległe utrzymanie w rozwoju aplikacji działa tak, jak opisano w poprzednich rozdziałach. W przeciwieństwie do rozwoju w systemach dostosowania branżowego i klientowskiego może być zaangażowanych kilka systemów następczych. Każda aplikacja rozwijana w systemie może mieć inny system następczy. Ustalane jest to w panelu systemowym poprzez przypisanie modułów do grup systemowych. W tym przypadku poziom kodu systemu zleceń deweloperskich musi wynosić co najmniej 5.1, ponieważ należy zarządzać kilkoma zleceniami następczymi w różnych wydaniach.

Usługa deweloperska

Usługa deweloperska służy do synchronizacji poprawek między systemami deweloperskimi. Usługa deweloperska jest uruchamiana podczas aktywacji zadania. Jeśli zdefiniowano system następczy, wykonywane są następujące dodatkowe zadania:

• Utworzenie następczego zlecenia deweloperskiego. Jest to kopia pierwotnego zlecenia dla wydania systemu następczego.
• Utworzenie zadania deweloperskiego w systemie następczym. Zadanie to przypisane jest do użytkownika, który właśnie aktywuje zadanie deweloperskie.
• Ustalenie, które obiekty deweloperskie zablokowane w aktywowanym zadaniu nie są zablokowane w systemie następczym.
• Zablokowanie tych obiektów deweloperskich w zadaniu deweloperskim następczym i oznaczenie ich jako nieusuwalnych.
• Oznaczenie obiektów deweloperskich, które są już zablokowane w innych zadaniach, jako nieusuwalnych również w tych zadaniach.
• Przekazanie do systemu aktywującego informacji o tym, które wersje zostały zablokowane.
  Zapisanie tych zależności w aktualizacji oprogramowania powiązanej z zadaniem deweloperskim.

Jeśli dla systemu następczego zdefiniowano kolejny system następczy, proces jest kontynuowany, gdy tylko zadanie deweloperskie następcze zostanie aktywowane.

Aby aktywować usługę zleceń deweloperskich, w systemie następczym należy uruchomić zlecenie przetwarzania Usługa deweloperska. System następczy wskazywany jest w aplikacji Panel System.

Usługa deweloperska w systemach deweloperskich dla APP

Usługa deweloperska działa w rozwoju APP zasadniczo tak samo, jak opisano w powyższym rozdziale. Różnice wynikają z faktu, że system może mieć kilka systemów następczych, przy czym dla każdej aplikacji może istnieć jeden system następczy.

Po aktywowaniu zadania opisana powyżej procedura jest wykonywana dla wszystkich obiektów deweloperskich w zadaniu, pogrupowanych według aplikacji. Zadanie może zostać aktywowane dopiero wtedy, gdy równoległe utrzymanie dla wszystkich obiektów deweloperskich zawartych w zadaniu zostanie pomyślnie zakończone.

Konfiguracja równoległego utrzymania

Grupy systemowe

Grupa systemowa opisuje topologię systemu deweloperskiego oraz powiązanych systemów testowych lub dodatkowych systemów deweloperskich.

Możliwa struktura grupy systemowej

W grupie systemowej dla systemów deweloperskich zawsze występuje system deweloperski (DV). System testowy (DT) jest zalecany, ale nie jest bezwzględnie wymagany. Można ustalić, czy dostawa odbywa się bezpośrednio z systemu DV, czy też poprzez system DT. Tylko w systemie DT można grupować aktualizacje oprogramowania.

Jeśli wymagane są dodatkowe systemy testowe, mogą one również zostać ujęte w grupie systemowej. Z tych systemów testowych nie można jednak realizować dostaw aktualizacji oprogramowania. Wszystkie systemy testowe są zasilane aktualizacjami oprogramowania z systemu DV.

W razie potrzeby można utworzyć tzw. dodatkowe systemy deweloperskie (DV 1..n). Jest to np. pomocne, gdy większy rozwój ma być zrealizowany w systemie deweloperskim klienta, ale nie może on zakłócać zasilania systemu produkcyjnego poprawkami ze standardu, systemu branżowego lub systemu deweloperskiego klienta. Dodatkowe systemy deweloperskie tworzone są jako kopia systemu DV. Podczas aktywacji zadań deweloperskich w systemie DV za pośrednictwem usługi deweloperskiej, podobnie jak w przypadku równoległego utrzymania, tworzone są zadania deweloperskie w dodatkowych systemach deweloperskich. Zadania te zawierają te same obiekty deweloperskie, co zadanie w systemie DV. O tym, które elementy obiektów deweloperskich zostaną uwzględnione, decyduje porównanie wersji. Jednakże żadne informacje o utworzonych wersjach nie są przekazywane do systemu aktywującego.

Przejęcie zmian z dodatkowych systemów deweloperskich (DV 1..n) z powrotem do systemu DV nie odbywa się automatycznie. Do tego celu służy import/eksport XML. W systemie DV powstaje zadanie deweloperskie ze wszystkimi obiektami deweloperskimi, które w ten sposób zostały przeniesione do systemu. Wszystkie pozostałe informacje, np. historia, zadania deweloperskie, osoby odpowiedzialne itp. nie są przejmowane z dodatkowych systemów DV. Po ponownym przejęciu do systemu DV odpowiednie dodatkowe systemy DV powinny zostać usunięte i w razie potrzeby, po aktywowaniu zadania deweloperskiego, odtworzone na nowo.

Wszystkie systemy DV w grupie systemowej mają ten sam prefiks deweloperski i ten sam poziom wersjonowania. Aktualizacje oprogramowania, które są wgrywane do systemu DV grupy systemowej, powinny być również wgrane do pozostałych systemów deweloperskich grupy. Wszystkie systemy w obrębie grupy systemowej mają to samo wydanie.

Grupy deweloperskie

Grupy deweloperskie łączą kilka grup systemowych. W grupie deweloperskiej ustalane są definicje, które obowiązują dla wszystkich grup systemowych. Są to np. poziom wersjonowania, prefiks deweloperski, prefiks eksportowy aktualizacji oprogramowania, serwer identyfikacji i serwer zleceń deweloperskich.

Grupa deweloperska definiuje niezmienną kolejność grup systemowych. W ten sposób ustala się, który system deweloperski musi zostać powiadomiony podczas równoległego utrzymania.

Systemy deweloperskie w grupie deweloperskiej zawsze mają ten sam prefiks deweloperski. Aby zapewnić jednoznaczne identyfikacje w obiektach deweloperskich, wszystkie systemy deweloperskie używają tego samego serwera identyfikacji.

Do równoległego utrzymania konieczne jest użycie serwera zleceń deweloperskich. Nie musi to być system należący do grupy deweloperskiej. Zazwyczaj jeden serwer zleceń deweloperskich używany jest dla wszystkich systemów deweloperskich. Za pośrednictwem serwera zleceń deweloperskich zarządzana jest organizacyjna część równoległego rozwoju. Aplikacje Zlecenia deweloperskie, Zgłoszenia supportowe i Dostawy wsparcia służą do organizacji obsługi zgłoszeń klienta, przebiegu rozwoju aż po dostawę.

Grupa deweloperska z trzema grupami systemowymi

W rozwoju standardowym lub branżowym poszczególne grupy systemowe mają różne, ale bezpośrednio po sobie następujące rosnące wydania.

W grupie deweloperskiej do rozwoju aplikacji kilka następujących po sobie grup systemowych może mieć to samo wydanie.

Aby można było zdefiniować kolejność w systemach, istnieje ciągły numer, infiks, przypisany do grup systemowych. Numer ten jest używany w systemach deweloperskich dla aplikacji jako początkowa część numeru wersji obiektów deweloperskich. W systemach testowych wydających z grupy numer ten jest także używany jako część oznaczenia aktualizacji oprogramowania. Dzięki temu można zapewnić, że w systemach z tym samym wydaniem i tym samym prefiksem eksportowym nie wystąpią aktualizacje oprogramowania o identycznych nazwach.

Moduł

Grupa systemowa opisuje, w jakiej relacji poszczególne systemy pozostają wobec siebie oraz jaką rolę przy tym pełnią. Grupa deweloperska opisuje kolejność grup systemowych względem siebie. Brakuje jednak definicji, co i gdzie jest rozwijane. To ustalenie następuje w tzw. modułach.

Moduł opisuje, co jest rozwijane oraz w jakich grupach systemowych. Rozróżnia się moduły typu Standard oraz typu APP.

Moduły typu Standard są stosowane w grupach deweloperskich przeznaczonych do rozwoju standardowego, branżowego lub klienckiego. Z reguły wszystkie grupy systemowe są przypisane do modułu. Równoległe utrzymanie tego modułu odbywa się zatem poprzez odwoływane w ten sposób systemy deweloperskie.

Moduły typu APP stosuje się w rozwoju aplikacji. W przeciwieństwie do rozwoju Standard, aplikacja może być rozwijana i utrzymywana w podzbiorze dostępnych grup systemowych. Z chwilą przypisania grupy deweloperskiej do modułu rozpoczyna się równoległe utrzymanie. Więcej informacji na ten temat można znaleźć w artykule Wprowadzenie: APP.

W przypadku modułów typu APP można dodatkowo określić, od jakich innych modułów aplikacji są one zależne lub które mogą być używane. Ustalenie to służy do kontroli referencji w obiektach deweloperskich i chroni przed tworzeniem zależności do niedozwolonych aplikacji. Wymagane moduły są również niezbędne podczas późniejszej instalacji aplikacji.

Rozwój u partnerów

U partnera rozróżnia się dwa przypadki:

• Partner dostarcza system standardowy i dostosowuje go dla każdego ze swoich klientów.
• Partner wprowadza rozszerzenia do systemu, które są przeznaczone dla wielu lub wszystkich klientów (rozwiązanie branżowe), a następnie wykonuje jeszcze adaptacje specyficzne dla niektórych lub wszystkich klientów.

System standardowy

Dla każdego klienta wymagane jest testowe środowisko klienta, które stanowi kopię systemu produkcyjnego klienta. Jeśli dla klienta wykonywane są adaptacje, konieczne jest dodatkowo środowisko adaptacji klienta. Tam wprowadzane są dostosowania systemu standardowego do systemów klienta.

Jeżeli z rozwoju standardowego Comarch ERP Enterprise udostępniana jest aktualizacja oprogramowania, to najpierw wgrywana jest ona do systemu standardowego partnera i tam testowana.

Jeżeli aktualizacja oprogramowania jest istotna dla klienta albo jej wgranie jest konieczne ze względu na zależności od innych aktualizacji, wgrywa się ją do systemu adaptacji klienta lub do systemu testowego klienta. W systemie adaptacji klienta podczas instalacji mogą wystąpić konflikty, jeśli aktualizacja oprogramowania zawiera obiekty deweloperskie, które partner dostosował dla klienta. Konflikty te muszą zostać rozwiązane w systemie adaptacji klienta.

Następnie tworzona jest kolejna aktualizacja oprogramowania, która razem z zawartością zainstalowanej aktualizacji dostarczana jest do klienta. Dla każdej aktualizacji oprogramowania, która nie prowadzi do konfliktów, system adaptacji klienta podczas instalacji automatycznie tworzy nową aktualizację o tym samym zakresie. Odpowiedni plik musi zostać ręcznie wyeksportowany do systemu plików.

Rozwój własnego systemu przez partnera

Jeżeli partner dokonuje własnych rozszerzeń w standardowym systemie Comarch ERP Enterprise, instalacja aktualizacji oprogramowania musi przebiegać dwuetapowo.
Najpierw są one wgrywane do systemu rozwojowego lub korekcyjnego partnera i tam rozwiązywane są konflikty, a następnie przenoszone do systemu adaptacyjnego klienta. Tam zmiany mogą ponownie prowadzić do konfliktów, które muszą zostać usunięte. Następnie aktualizacje oprogramowania są dostarczane do klienta.

Ścieżki transportu aktualizacji oprogramowania

Ścieżki transportu u partnera

Aktualizacje oprogramowania ze standardowego rozwoju Comarch ERP Enterprise są wgrywane do systemu zapewnienia jakości (system standardowy) partnera. Stąd istnieją różne możliwości, które systemy zostaną zaktualizowane aktualizacjami oprogramowania z systemu zapewnienia jakości.

Jeżeli partner korzysta ze standardowego systemu opisanego w rozdziale System standardowy, rozróżnia się dwa przypadki:

• Systemy produkcyjne (wraz z powiązanym systemem testowym) są aktualizowane bezpośrednio aktualizacjami oprogramowania. Ta metoda dostawy jest zalecana tylko wtedy, gdy w najbliższym czasie nie są planowane modyfikacje dla klienta. Jeżeli jednak musi zostać przeprowadzona adaptacja dla klienta, do ścieżki transportu należy włączyć system adaptacji klienta. Dodatkowy nakład pracy jest uzasadniony tylko wtedy, gdy dzięki temu przez dłuższy czas można było uniknąć konieczności utrzymania systemu.

• Jeżeli partner dokonał modyfikacji dla klienta, aktualizacje oprogramowania należy zaimportować do systemu adaptacji klienta. Od tego momentu system klienta jest aktualizowany.

Jeżeli partner rozwija własne rozwiązanie branżowe (więcej informacji można znaleźć w rozdziale Rozwój własnego systemu przez partnera), wówczas rozróżnia się dwa przypadki:

• Jeżeli partner rozwija rozwiązanie branżowe i znajduje się ono właśnie w fazie rozwoju, aktualizowany jest wyłącznie system rozwojowy aktualizacjami oprogramowania.

• Jeżeli rozwiązanie branżowe znajduje się już w fazie utrzymania, wgrywane są aktualizacje oprogramowania do partnerskiego systemu korekcyjnego. Za pośrednictwem partnerskiego systemu korekcyjnego wgrywane są następnie obiekty deweloperskie partnera oraz ze standardowego rozwoju Comarch ERP Enterprise do partnerskiego systemu testowego. Możliwe jest jednak także wgranie pojedynczych aktualizacji oprogramowania do partnerskiego systemu deweloperskiego dla następnego wydania (np. poprawki błędów). W systemie testowym klienta aktualizacje oprogramowania są grupowane według kryteriów merytorycznych. Z systemu testowego zebrane aktualizacje oprogramowania są następnie wgrywane bezpośrednio albo za pośrednictwem systemu adaptacji klienta do systemu klienta.

Ścieżki transportu w środowisku produkcyjnym

W środowisku produkcyjnym aktualizacje oprogramowania są wgrywane z systemu zapewnienia jakości, systemu adaptacji lub systemu testowego partnera do systemu testowego klienta. Z systemu testowego można następnie zaktualizować system produkcyjny.

Przykładowa ścieżka transportu w środowisku produkcyjnym

Możliwe ścieżki transportu

Poniższy schemat przedstawia możliwe ścieżki transportu aktualizacji oprogramowania.

Możliwe ścieżki transportu aktualizacji oprogramowania

Aktualizacja systemu docelowego

Podczas aktualizacji systemu docelowego jest on zaopatrywany w aktualizacje oprogramowania z systemu źródłowego. System źródłowy ustala, które aktualizacje oprogramowania zostały już zaimportowane do systemu docelowego. Nie muszą one być ponownie wgrywane. Aktualizacje oprogramowania, które nie zostały jeszcze zainstalowane w systemie docelowym, są automatycznie przenoszone do systemu docelowego i odkładane w folderze Import systemu docelowego. Dopiero gdy w folderze Import znajdują się pliki odświeżania kodu, pliki odświeżania źródeł itp., można rozpocząć proces instalacji. Aktualizacje oprogramowania mogą być w systemie docelowym instalowane automatycznie. Aktualizacje muszą zostać wyeksportowane, zanim będą mogły zostać przeniesione. W systemach testowych aktualizacje oprogramowania muszą najpierw zostać zebrane, zanim będzie możliwe ich przeniesienie za pomocą funkcji aktualizacji systemu docelowego.

Automatyczna instalacja

Aktualizacje oprogramowania mogą i powinny być instalowane automatycznie w systemie. Podczas automatycznej instalacji system samodzielnie wykonuje niezbędne kroki instalacyjne. Na końcu automatycznej instalacji tworzony jest protokół instalacji. Jeśli podczas automatycznej instalacji wystąpią błędy, instalacja zostaje przerwana, aby można było ewentualnie ręcznie usunąć błędy. Następnie można wznowić automatyczną instalację i pozostałe kroki instalacyjne zostaną wykonane. Automatyczna instalacja rozpoznaje ręcznie wykonane kroki instalacyjne i nie wykonuje ich ponownie.

Automatyczna instalacja instaluje aktualizacje oprogramowania systemowego i aplikacyjnego sekwencyjnie, tzn. najpierw SYS, potem APP. Instalacja aktualizacji oprogramowania dzieli się na fazę przygotowawczą i fazę aktywacyjną. Faza przygotowawcza wykonywana jest podczas pracy systemu. Podczas fazy aktywacyjnej, w zależności od instalowanych aktualizacji oprogramowania, system może nie być dostępny.

Automatyczna instalacja obejmuje zasadniczo następujące kroki instalacyjne:

1. Przygotowanie instalacji — w folderze Import tworzony jest plik XML. Plik ten zawiera wszystkie informacje o aktualnym statusie instalacji. Ponadto tworzony jest katalog, w którym zapisywane są w plikach wyniki instalacji. Nazwa katalogu ma postać: AI-JJJJMMTTHHMMSS (JJJJ – rok, MM – miesiąc, TT – dzień, HH – godzina, MM – minuta, SS – sekunda utworzenia katalogu). Dla bezpieczeństwa plik XML również jest zapisywany w tym katalogu.
2. Import SYS — importowane są wszystkie aktualizacje oprogramowania zawierające systemowe obiekty deweloperskie (wywołanie narzędzia: imprfr –all –codeClass:sys). Import jest protokołowany w pliku SYS_IMPORT.log.
3. Dostawa plików SYS – restart — jeśli aktualizacje oprogramowania zawierają dostawy plików, wykonywany jest restart w celu wymiany odpowiednich plików.
4. Przygotowanie SYS — przygotowanie instalacji zaimportowanych aktualizacji oprogramowania (wywołanie narzędzia: upgaps –prepare –codeClass:sys). Przygotowanie jest protokołowane w pliku SYS_PREPARE.log.
5. Zakończenie przygotowania SYS — obiekty deweloperskie przeznaczone do instalacji są przenoszone z archiwum do tabel systemowych (wywołanie narzędzia: upgaps –upgrade –codeClass:sys). Informacja jest protokołowana w pliku SYS_UPGRADE.log.
6. Zakończenie przygotowania SYS – restart — restart po zakończeniu przygotowania systemowych aktualizacji oprogramowania.
7. Aktywacja SYS — aktywacja obiektów deweloperskich (wywołanie narzędzia: upgaps –activate –codeClass:sys). Informacja jest protokołowana w pliku SYS_ACTIVATE.log.
8. Aktywacja SYS – restart — restart po aktywacji systemowych aktualizacji oprogramowania.
9. Zwolnienie SYS — wykonanie aktualizacji danych (wywołanie narzędzia: upgaps –release –codeClass:sys). Informacja jest protokołowana w pliku SYS_RELEASE.log.
10. Import APP — importowane są wszystkie aktualizacje oprogramowania zawierające obiekty deweloperskie aplikacyjne (wywołanie narzędzia: imprfr –all –codeClass:app). Import jest protokołowany w pliku APP_IMPORT.log.
11. Dostawa plików APP – restart — jeśli aktualizacje oprogramowania zawierają dostawy plików, wykonywany jest restart w celu wymiany odpowiednich plików.
12. Przygotowanie APP — przygotowanie instalacji zaimportowanych aktualizacji oprogramowania (wywołanie narzędzia: upgaps –prepare –codeClass:app). Przygotowanie jest protokołowane w pliku APP_PREPARE.log.
13. Zakończenie przygotowania APP — obiekty deweloperskie przeznaczone do instalacji są przenoszone z archiwum do tabel systemowych (wywołanie narzędzia: upgaps –upgrade –codeClass:sys). Informacja jest protokołowana w pliku APP_UPGRADE.log.
14. Zakończenie przygotowania APP – restart — restart po zakończeniu przygotowania aktualizacji oprogramowania.
15. Aktywacja APP — aktywacja obiektów deweloperskich (wywołanie narzędzia: upgaps –activate –codeClass:sys). Informacja jest protokołowana w pliku APP_ACTIVATE.log.
16. Aktywacja APP – restart — restart po aktywacji systemowych aktualizacji oprogramowania.
17. Zwolnienie APP — wykonanie aktualizacji danych (wywołanie narzędzia: upgaps –release –codeClass:app). Informacja jest protokołowana w pliku APP_RELEASE.log.
18. Zakończenie — plik XML zostaje usunięty z folderu Import. Dzięki temu system może być ponownie automatycznie aktualizowany. Dopóki plik XML znajduje się w folderze Import, aktualizacja z systemu źródłowego nie jest możliwa.

Dostawy plików

Dostawy plików to specjalne obiekty deweloperskie typu Plik, które umożliwiają dołączanie większych plików do aktualizacji oprogramowania i tym samym ich dostarczanie do innych systemów. Ta forma dostawy jest stosowana w sytuacjach, gdy pliki nie mogą być użyte jako obiekty plikowe:

• pliki są zbyt duże, aby mogły być zarządzane w repozytorium,
• warunki licencyjne uniemożliwiają dostarczenie tego pliku,
• pliku nie można wymienić, dopóki korzysta z niego SAS.

Do każdej dostawy pliku w aplikacji Obiekty deweloperskie tworzy się obiekt pliku. Obiekt ten może znajdować się wyłącznie w obszarze nazw com.cisag.sys.delivery lub com.xxx.app. Plik ma postać pliku XML opisującego dostawę i zawiera:

• datę wydania wersji,
• typ dostawy pliku: FILE, CHECKSUM,
• typ ponownego uruchomienia: NONE, SERVER, SHELL,
• informacje o wersji,
• dla wszystkich przypisanych plików: nazwę pliku z relatywną ścieżką do katalogu semiramis.

Dostawa pliku typu FILE dostarcza zawartość przypisanych plików. Dostawy FILE stosowane są dla wszystkich grup plików, które powinny być dostępne w każdym systemie.

Dostawa pliku typu CHECKSUM nie dostarcza zawartości plików, lecz tylko ich sumy kontrolne. Taka dostawa jest wymagana, gdy warunki licencyjne zabraniają dostarczenia zawartości lub gdy instalacja tych plików jest opcjonalna.

Podczas eksportu aktualizacji oprogramowania sprawdzane jest, czy zawiera ona dostawy plików. Dla każdej dostawy w katalogu <Nazwa dostawy>+<Numer wersji> muszą być umieszczone pliki dołączane do tej dostawy. Katalog ten jest tworzony podczas importu dostawy i musi zostać uzupełniony przed eksportem. Jeżeli dostawa jest typu FILE, aktualizacja oprogramowania zawiera opisane w niej pliki wraz z ich sumami kontrolnymi. Jeżeli dostawa jest typu CHECKSUM, aktualizacja zawiera jedynie sumy kontrolne opisanych plików.

Podczas eksportu aktualizacji z dostawą plików sumy kontrolne dostarczonych plików zapisywane są w osobnym pliku. Dzięki tym sumom kontrolnym można upewnić się, że metadane dostawy odpowiadają rzeczywistym danym. Plik sum kontrolnych zawiera dla każdego pliku w dostawie:

• relatywną nazwę pliku,
• sumę kontrolną,
• rozmiar pliku,
• datę pliku.

Przy imporcie aktualizacji pliki dostawy są rozpakowywane do katalogu przypisanego tej dostawie z daną wersją, przykładowo <„semiramis“-Verzeichnis/file-deliveries/object_0X1>.

Podczas aktywacji aktualizacji pliki dostawy z opcją ponownego uruchomienia NONE kopiowane są bezpośrednio do katalogu semiramis. Pliki z opcją SERVER lub SHELL kopiowane są do katalogu fileupdate. Jeżeli wśród importowanych aktualizacji znajduje się dostawa pliku z opcją SERVER lub SHELL, po imporcie aktualizacji serwer zostaje zatrzymany. Po zatrzymaniu SAS pliki z katalogu fileupdate kopiowane są do katalogu serwera. Jeżeli opcja to SERVER, ponownie uruchamiany jest tylko SAS. Jeżeli opcja to SHELL, SAS zostaje zatrzymany, a użytkownik proszony jest o zakończenie powłoki, skopiowanie plików (za pomocą dostarczonego skryptu) i ponowne uruchomienie powłoki wraz z serwerem. Po każdej operacji przejęcia plików do katalogu serwera katalog fileupdate jest usuwany.

Podczas importu aktualizacji zawierających dostawy plików są one zapisywane w katalogu <Nazwa dostawy> + <Numer wersji>. W systemie produkcyjnym katalogi dostaw plików można usuwać. W innych systemach powinno się tego unikać. Za pomocą narzędzia chkfd można porównać aktualnie używany plik z plikiem w katalogu dostawy, aby sprawdzić, czy plik nie został w międzyczasie zmieniony.

Protokół instalacji

Dla każdej automatycznej instalacji aktualizacji oprogramowania tworzony jest protokół instalacji. Protokół instalacji zawiera następujące informacje:

• przegląd wszystkich aktualizacji oprogramowania zainstalowanych w procesie instalacji,
• przegląd wszystkich aktualizacji danych zainstalowanych w procesie instalacji,
• w razie potrzeby numer zadania konfliktowego,
• listę wszystkich zadań, które należy wykonać po instalacji,
• listę wszystkich błędów, jakie pojawiły się podczas instalacji.

Protokół instalacji obejmuje zatem wszystkie informacje, które są istotne po wgraniu aktualizacji oprogramowania. Jest on generowany po zakończeniu procesu instalacji. Protokół instalacji zapisywany jest w katalogu o nazwie AI-JJJJMMTTHHMMSS (JJJJ – rok, MM – miesiąc, TT – dzień, HH – godzina, MM – minuta, SS – sekunda, w której utworzono katalog) w folderze Import.

Protokół instalacji można przeglądać w aplikacji Panel System, na zakładce Procesy instalacyjne.

W aplikacji Konfiguracja w głównej funkcji Aktualizacje oprogramowania można ustalić, w jaki sposób odbywa się powiadomienie po zakończeniu instalacji aktualizacji oprogramowania. Dostępne metody powiadamiania to:

• Działania workflow — osobą przypisaną do wygenerowanych działań workflow jest rola workflow cis.SysAdmin. Jeżeli do tej roli nie przypisano osób, wykorzystywany jest odpowiedzialny za system. Dla każdego zadania związanej z aktualizacją oprogramowania zainstalowaną w procesie instalacji tworzone są działania. Działania zawierają opis i aplikację zarejestrowaną przy zadaniu. Jeżeli w procesie instalacji zawarte są aktualizacje danych w trybie dialogowym lub niewykonane jeszcze aktualizacje danych w tle, tworzone jest działanie do ich wykonania.
• E-mail — jeżeli protokół instalacji wysyłany jest pocztą e-mail, nadawcę i odbiorcę wiadomości można określić w aplikacji Konfiguracja. Jeśli nadawca nie zostanie określony, jako nadawca używany jest administrator. Jeżeli nie zostanie określony odbiorca, e-mail zostanie wysłany do osoby odpowiedzialnej za system. Wiadomość e-mail zawiera protokół instalacji.