Jak aktualizować aplikację klienta?

Powyższe zasady rozwoju aplikacji pozwalają znacznie uprościć i przyspieszyć proces aktualizacji aplikacji klientów. Aplikacje klientów mogą być aktualizowane na jeden z poniższych sposobów:

1. Podniesienie tylko warstwy technologicznej - jeśli chcemy mieć poprawione stare błędy technologii i dostępne nowe możliwości technologiczne

2. Podniesienie warstwy technologicznej + konfiguracja nowych modułów - j.w. jeśli chcemy dodatkowo uruchomić np workflow, faktury kosztowe, itp.

3. Wgranie aktualizacji z rejestru aktualizacji - jeśli chcemy jedynie dokonać aktualizacji w ramach zgodności systemu z przepisami.

4. Pełna aktualizacja do wersji bieżącej (tylko dla klientów uruchomionych od wersji 5.4).

Wszystkie opisane niżej procesy zakładają, że źródła aplikacji klienta są przygotowane i pielęgnowane zgodnie z poprzednim rozdziałem tej instrukcji.

Sposób 1. Podniesienie tylko warstwy technologicznej

Odbywa się poprzez:

1. Aktualizację źródeł aplikacji klienckiej (TeneumClient.exe) w zakresie submodułu CORE na gicie (SDAS, sdastool, itp) do określonej wersji, kompilację całości i wgranie do klienta.

2. Jeśli aktualizujemy źródła z wersji starszej niż 5.3 do 5.3 lub nowszej, trzeba przeprowadzić wyodrębnienie kodu bibliotek systemowych do submodułu. W tej czynności wspiera ZRT (Adrian Rogala).

3. Aktualizację serwera neos do określonej wersji (bez potrzeby kompilacji). Zwykle bierzemy wersję RTM z folderu: x:\dbr\release\neos\release.to.manufacture\

4. Same projekty neosowe zostawiamy bez zmian, gdyż nie należą one do technologii, tylko do Teneum. Ewentualne ich podniesienie jest opisane w sposobie 2.

5. Uruchomienie neosa i aplikacji i przeprowadzenie migracji bazodanowych, o które Neos poprosi. Migracje bazodanowe można też wygenerować z linii poleceń: Neos.Runtime.exe -s esystem.smd -d log --generate-migration-script C:\skrypt.sql, a następnie poprzez uruchomienie wygenerowanego skryptu w IBExpercie.

6. Przejrzenie not emisyjnych, aby zapoznać się z krytycznymi zmianami nowej wersji lub miejscami, w których naruszono kompatybilność i wymagane są poprawki w kodzie projektów lub w konfiguracji Neosa.

Na co zwrócić uwagę?

1. Drukarki fiskalne. Kilka lat temu kod źródłowy obsługi drukarek fiskalnych zniknął z ssid.bpl i trafił do Core (warstwa technologiczna), ale było to błędem. Obecnie (2021.10) jest to odkręcane i obsługa drukaref fiskalnych przechodzi z warstwy technologicznej z powrotem do Teneum. Należy zwrócić uwagę przy aktualizacji, w której bibliotece będzie obsługa drukarek fiskalnych, i czy będą one działać poprawnie.

2. Jeśli u klientów jest projekt SENTE, to należy z niego wyciąć obiekty schedulerowe, aby projekt SENTE się kompilował z nową technologią.

3. Jeżeli w projektach nie ma wskazanych pól klucza głównego to należy je poustawiać. W najnowyszych wersjach technologicznych jest to wymagane.

4. W związku ze zmianą automatycznego generowania kodu C# na podstawie projektów biznesowych od wersji 6.1.6 należy dodać obowiązkowy namespace LOGIC do wywołań statycznych metod obiektów logiki.

5. Jeżeli używamy funkcji multiwhere w parserze, to od wersji 5.2 zmienił się generowany rezultat dla trybu 4 gdy zaznaczono tylko 1 element. Element ten będzie przekazany bez apostrofów ''. Zmiana ta jest związana ze standaryzacją modyfikacji technologicznych Raw-polu

6. Pluginy są częścią produktu, a nie technologii. Po aktualizacji powinny pozostać w tej samej wersji, w której były u klienta przed aktualizacją. Jeśli stary plugin nie załaduje się w nowej wersji technologii, to należy pobrać kod źródłowy pluginu w takiej wersji, w jakiej był u klienta i przekompilować.

Sposób 2. Aktualizacja / instalacja modułu (np. Workflow, Faktury Kosztowe)

Ten proces dotyczy jedynie nowych modułów (Workflow, Faktury kosztowe), czyli takich, które są napisane wyłącznie w Neosie i mają swoje struktury bazodanowe w osobnym folderze. Kod źródłowy takich modułów jest w całości odseparowany od reszty kodu aplikacji. (np jest w podfolderze: standard/WORKFLOW). Aktualizacja składa się z następujących kroków:

1. Pobranie z gita źródeł standardu Teneum do siebie i ustawienie się na branchu wersji, do której chcemy zaktualizować klienta.

2. Pobranie źródeł aplikacji klienta do siebie, włącznie ze źródłami bazy danych. Aby pracować na źródłach klienta pobieramy je przez adres zaczynający się od "git@...", a nie od "https", bo tylko wtedy submoduły pobiorą się automatycznie.

3. Od brancha <klient>_master odbijamy brancha na aktualizację.

4. Wstępne porównanie plików w folderze modułu/modułów, które chcemy aktualizować u klienta (np. standard\WORKFLOW, standard\WFFA) i ich skopiowanie do repozytorium klienta wraz z usunięciem plików, które na standardzie zostały usunięte. Należy pamiętać, aby nie ruszać innych folderów, zawerających inne projekty neosowe, bo ich nie aktualizujemy. Należy zwrócić uwagę, że w ten sposób nie można kopiować folderów z projektami, które nie zawierają wydzielonych skryptów bazodanowych (folderu "dbscripts"). Takie projekty mają zmiany bazodanowe zmieszane ze zmianami bazodanowymi wszystkich innych modułów, we wspólnym folderze "dbscripts" i nie da się ich łatwo wyseparować pod kątem aktualizacji klienta.

5. Zacommitowanie przeniesionych źródeł na gicie na branchu aktualizacji.

6. Jeśli chcemy przeprowadzić testową aktualizację, to pobieramy bazę produkcyjną do siebie i będziemy dalej działać na bazie lokalnej.

7. Odpalenie pełnego procesu aktualizacji w SH na lokalnych źródłach i wskazanej bazie (produkcyjnej lub lokalnej) ("Pełny proces" -> "Zaktualizuj bazę"). Jeśli coś idzie nie tak, poprawiamy pliki źródłowe, commitujemy poprawki i ponawiamy proces. W trakcie aktualizacji finalny skrypt aktualizacyjny będzie pokazany na ekranie. Jeśli robimy aktualizację na bazie lokalnej, to możemy go skopiować do schowka i zapisać.

8. Sprawdzamy, czy w wyniku aktualizacji otrzymaliśmy to, co chcemy.

9. Jeśli aktualizowaliśmy bazę lokalną, a w międzyczasie na bazie produkcyjnej nie dokonano żadnych zmian w metadanych, to możemy ten sam skrypt różnicowy wgrać na bazę produkcyjną. Jeśli jednak na produkcji w międzyczasie zaszły już jakieś inne zmiany rozwojowe, należy je zagitować na branchu <klient>_master, pobrać, domergować te zmiany do brancha aktualizacji i ponowić proces aktualizacji w SH.

10. Jeśli wszystko jest ok, to mergujemy branch aktualizacji do brancha<klient>_master i odpalamy proces deploymentu nowej wersji aplikacji na produkcję.

11. Wyrywkowe sprawdzenie podstawowych zmian na produkcji.

🚩 Instalacja modułów KSEF Sprzedaż i KSEF Zakupy

W przypadku instalacji nowych modułów KSEF (sprzedaż i zakupy) postępuj zgodnie z krokami od 1 do 3 procesu ogólnego, a następnie:

UWAGA: Moduł KSEF Zakupy wymaga aktualnej wersji modułu WORKFLOW.

1. Podgranie źródeł i aktualizacja bazy (Zmiany modułowe):

   • Podgraj cały folder KSEF (dla KSEF Sprzedaż) i folder WFKSEF (dla KSEF Zakupy) do repozytorium klienta.
   • Uruchom pełny proces aktualizacji w SH, aby wygenerować i puścić skrypt aktualizacyjny bazy danych (kroki 7 i 8 z procesu ogólnego).

2. Plugin KSEF (Zmiana modułowa):

   • Skompiluj plugin z folderu KSEF lub podgraj skompilowany plik z aplikacji standardowej.

3. Licencje (Zmiana konfiguracyjna):

   • Zaktualizuj plik licencji (.ser) o licencje na moduły KSEF Sprzedaż i KSEF Zakupy.

---

Poniższe punkty 4-6 to zmiany zależne, które należy przenieść ze standardowego brancha z commita o SHA: 07df448521fcd0a1a1531efc86f9c540c31187c6 z wyłączeniem zmian dotyczących TD.GLOBALACTION, które należy wdrożyć manualnie na podstawie poniższych instrukcji:

1. Konfiguracja przycisków na wstążce (Zmiana manualna):

   • Dodaj w TD.GLOBALACTION przyciski od konfiguracji KSEF lub odpowiednie przyciski w starej wstążce, jeśli klient używa starszego interfejsu.
     • Przykłady konfiguracji przycisków na wstążce widoczne są w materiałach szkoleniowych:
       • Film 1
       • Film 2

2. Wydruk faktury (Zmiana zależna):

   • Obowiązkowo przenieś kody QR do wydruku faktury klienta.
   • Opcjonalnie (dobrowolnie) uwzględnij tytuł faktury na wydruku.

3. Wydruk potwierdzenia tranzakcji (Zmiana zależna):

   • Zmiana opcjonalna poza folderami KSef a w wydrukach na branchu KSeF

4. Rozszerzona obsługa VAT Marży (opcjonalna Zmiana zależna):

   • Jeśli klient wymaga rozszerzonej obsługi VAT Marży, dograj pliki edittypfaktur.dfm i Controls_esystem_BKDOCTYPES_edit.

5. JPK:

6. Nalezy też wgrać nowey JPK (jesli nie ma ksiegowości to część zmian z projektu KSEF może się nie kompilować i moża to ręcznie załatać) tematy do wgrania PSU-3371 PSU-3599 PSU-3625 PSU-3661 PSU-3673 PSU-3674

Powyższy sposób to instalacja od zera, jesli już mamy zainstalowany KSEF, możemy porać zaminy z brancha KSeF, Cherry-pickując wybrany sprint. zmiany na tych brachach mogą zawierać poprawki poza folderami pprojektów neosowych tak jak zmiany do deklaracji VAT.

Sposób 3. Wgranie aktualizacji z rejestru aktualizacji (gdy wykonujemy to po raz pierwszy u danego klienta)

Sposób ten stosujemy, gdy w rejestrze aktualizacji w zakładce "stan aktualizacji klientów" nie mamy wpisu dla tego klienta informującego, która aktualizacja była ostatnio zainstalowana u tego klienta. Ten proces uzupełni ewentualne dziury w aktualizacji i wyrówna aplikację klienta do określonego stanu.

1. Aby rozpocząć ten proces zamrażamy rozwój aplikacji klienta (od tego momentu nie grzebiemy w metadanych, chociaż użytkownicy mogą dalej pracować w aplikacji).

2. Jeśli proces chcemy przeprowadzić w pełni lokalnie, to kopiujemy bazę klienta do siebie, ale wtedy musimy oczywiście zatrzymać pracę w aplikacji. Na pewno testową aktualizację warto zrobić na bazie lokalnej.

3. Aby pracować na źródłach klienta, pobieramy je z gita przez adres zaczynający się od "git@...", a nie od "https", bo tyko wtedy submoduły pobiorą się automatycznie.

4. Upewniamy się, że proces autocommitowania opisany wcześniej zapewnił nam źródła bazy na gicie zgodne z faktycznym stanem aktualizowanej bazy danych. Jeśli nie mamy podłączonego procesu autocommitowania to wykonujemy zacommitowanie ręczne zmian zgodnie z punktem "Pierwsze przeniesienie bazy na gita" tego rozdziału niniejszej instrukcji. Ustawiamy się na branchu <klient>_master i odbijamy od niego nowego brancha o nazwie "aktualizacja_do_XXX", gdzie XXX jest nazwą ostatniej aktualizacji w rejestrze aktualizacji - gdyż to do tej aktualizacji będziemy się podnosić. Od tego momentu będziemy pracować na branchu aktualizacji.

5. Naniesienie aktualizacji na źródła. Aktualizację po raz pierwszy nanosimy w sposób zbiorczy - czyli za jednym razem wyrównujemy aplikację wszystkimi aktualizacjami z rejestru aktualizacji. Robimy to następująco:

   1. Należy podłączyć repozytorium standardowe (git@git.office.sente.pl:dro/s4.git) jako nowy remote o nazwie "standard". W SourceTree jest to: Settings -> Add, podajemy nazwę i adres repo.

   2. Należy robić fetcha z tego repozytorium. W SourceTree: drzewo po > lewej -> remotes -> standard -> fetch from standard.

   3. Należy zrzucić sobie gdzieś na bok aktualne wersje plików esystem.rpt i esystem.dbi. Przydadzą się później.

   4. Pod git bashem wykonujemy polecenie: "git config merge.renamelimit 30000"

   5. A następnie polecenie naniesienia aktualizacji: "git cherry-pick <SHA hipersquasha>" (należy znaleźć na standardowym repo brancha wersja_zero_plus_hipersquash, i użyć SHA ostatniego / jedynego commita na tym branchu)

6. Rozwiązywanie konfliktów w plikach. Z pewnością naniesienie tak dużej aktualizacji wygenerowało konflikty w kilkuset plikach. Aby rozwiązać te konflikty należy zrozumieć ich przyczyny:

   Przyczyna 1: w aktualizacji dany plik jest nowym elementem, a u klienta on już jest i się nieco różni, bo np. był w wersji innej niż najnowsza, albo został indywidualnie zmodyfikowany

   Przyczyna 2: pliki po obu stronach mają całkiem odmienną historię zmian, ale finalnie niewiele się różnią

   1. Większość konfliktów rozwiązujemy poprzez wyrównanie zawartości plików do tego, co weszło w aktualizacji ze standardu. W SourceTree robimy to przez zaznaczenie plików -> prawy klawisz -> resolve conflicts -> resolve using "theirs". Tak możemy rozwiązać konflikty w s_appini, descriptions, positions.

   2. Konfilkty w procedurach i triggerach najlepiej rozwiązać poprzez użycie zewnętrznego edytora do rozwiązywania konfliktów. W SourceTree robimy to poprzez prawy klawisz na pliku -> resolve conflicts -> launch external merge tool. Najlepiej użyć do tego programu kdiff3. W tym programie przechodzimy przez wszystkie konflikty od góry do dołu i decydujemy, czy w danym fragmencie bierzemy kod ze standardu, czy od klienta, czy może zostawiamy oba jeden pod drugim. Można także ręcznie zredagować fragmenty pliku wynikowego, ale robi się to niezmiernie rzadko.

   3. W plikach esystem.dbi, esystem.rpt może być wiele konfliktów. Najlepiej rozwiązać je "using theirs", a następnie programem kdiff3 porównać pliki aktualne po rozwiązaniu konfliktów z pierwotnymi wersjami przed aktualizacją, które zrzuciliśmy na bok. Bywa, że rozwiązanie konfliktu usunęło lub zmodyfikowało sekcje, które nie powinny być tknięte aktualizacją. Przywracamy takie sekcje ręcznie.

   4. Uważamy na procedury XK_, pewnie zmiany naniesione ze standardu trzeba zdiscardować i pozostawić wersję klienta tych plików.

   5. Po rozwiązaniu konfliktów commitujemy źródła na branchu "aktualizacja_do_XXX".

   6. kompilujemy aplikację, aby się upewnić, że źródła c++ też są poprawne. Jeśli pojawią się problemy, to robimy poprawki i je commitujemy.

7. Jeśli aktualizację robimy na bazie produkcyjnej, to w tym momencie musimy zatrzymać pracę wszystkich użytkowników aplikacji.

8. Uruchamiamy w SH pełny proces aktualizacji i obserwujemy co się dzieje. UWAGA: Obecnie zalecamy użycie do tego SH z kanału beta. Jeśli proces się przerywa z błędem, to czytamy dlaczego, poprawiamy pliki źródłowe i ponawiamy proces. SH nanosi zmiany w trybie delty, więc błąd zawsze powoduje powrót bazy danych do stanu sprzed aktualizacji. Najczęstsze przyczyny problemów, to:

   1. elementy x-owe które zostały i odwołują się do elementów standardowych zaktualizowanych, które już nie istnieją bądź się zmieniły - poprawiamy je w plikach źródłowych.

   2. trasferówki, które z jakichś względów się wysypały - komentujemy ich treść w plikach źródłowych i możemy je potem wgrać i uruchomić ręcznie na zakończenie procesu

   3. inne znane problemy zostały opisane tutaj

9. Jeśli proces aktualizacji zakończył się poprawnie to wykonujemy następujące czynności końcowe:

   1. commitujemy zmiany w plikach źródłowych, które musieliśmy zrobić, aby proces przeszedł

   2. odpalamy SET_ALL_GRANTS_FOR dla odpowiednich użytkowników

   3. W celach czysto kontrolnych w SH wykonujemy pełny eksport. Jeśli aktualizacja wykonała się poprawnie, to baza klienta powinna być zgodna ze stanem źródeł na git, a więc pełny eksport nie powinien wygenerować żadnych nowych zmian, lub jedynie niewielkie zmiany kosmetyczne. Sprawdzamy to np w SourceTree patrząc czy jest coś nowego do zacommitowania. Drobne kosmetyczne zmiany możemy zacommitować, a jeśli zmian jest podejrzanie dużo i są merytoryczne, to znaczy, że coś mocno poszło nie tak.

10. Jeśli to była tylko aktualizacja testowa, to na tym proces kończymy, sprawdzamy czy działa to, co powinno. Ewentualnie udostępniamy wersję testową klientowi. Aktualizację produkcyjną będziemy mogli wykonać w sposób uproszczony poprzez podłączenie się do produkcyjnej bazy danych i ponownienie jedynie kroków 7 i 8. Nie musimy ponownie nanosić aktualizacji na gita i rozwiązywać konfliktów. Jeśli aktualizację produkcyjną od testowej dzieli pewien czas, w którym na produkcji pojawiło się już trochę rozwoju, to wystarczy domergować brancha <klient>_master do brancha "aktualizacja_do_XXX" i na branchu aktualizacji będziemy mieli gotowy stan aplikacji do ponowienia kroków 7 i 8. Jeśli upłynęło dużo czasu i zmian na produkcji jest bardzo dużo, to najlepiej porzucić obecnego brancha aktualizacyjnego i założyć nowego (z końcówką _1, _2, itp) odbijając go od aktualnego mastera i ponawiając kroki od 4 do 8.

11. Jeśli to była aktualizacja produkcyjna to na koniec:

    1. mergujemy brancha "aktualizacja_do_XXX" do brancha <klient>_master. Tutaj nie powinno być żadnych konfliktów.

    2. uruchamiamy proces deploymentu aplikacji opisany w rozdziale powyżej, który zbuduje dla klienta aplikację z brancha <klient>_master

    3. pozwalamy użytkownikom klienta zalogować się do aplikacji

    4. robimy wpis w rejestrze aktualizacji na zakładce "Stan aktualizacji klientów", aby mieć bieżącą informację, do jakiej aktualizacji został dociągnięty klient

    5. sprawdzamy jak będzie wyglądał pierwszy commit procesu autocommitu. Generalnie powinny się pojawić jedynie niewielkie zmiany kosmetyczne w plikach. Jeśli zmian jest podejrzanie dużo i dotyczą merytoryki kodu, to znaczy, że coś mocno poszło nie tak.

Sposób 3. Wgranie aktualizacji z rejestru aktualizacji (po raz kolejny)

Warunek początkowy: Klient był już podnoszony do którejś aktualizacji z rejestru aktualizacji. Najlepiej sprawdzić zakładkę "Stan aktualizacji klientów" w rejestrze aktualizacji.

1. Aby rozpocząć ten proces zamrażamy rozwój aplikacji klienta (od tego momentu nie grzebiemy w metadanych, chociaż użytkownicy mogą dalej pracować w aplikacji).

2. Pobieramy z gita źródła z repozytorium dla danego klienta. Aby pracować na źródłach klienta pobieramy je przez adres zaczynający się od "git@...", a nie od "https", bo tyko wtedy submoduły pobiorą się automatycznie.

3. Ustawiamy się na branchu <klient>_master i odbijamy od niego nowego brancha o nazwie "aktualizacja_do_XXX", gdzie XXX jest nazwą ostatniej aktualizacji w rejestrze aktualizacji - gdyż to do tej aktualizacji będziemy się podnosić. Od tego momentu będziemy pracować na branchu aktualizacji.

4. Upewniamy się, że proces autocommitowania bazy danych opisany wcześniej zapewnił nam źródła bazy na gicie zgodne z faktycznym stanem aktualizowanej bazy danych. Jeśli nie mamy podłączonego procesu autocommitowania to wykonujemy zacommitowanie ręczne zmian zgodnie z punktem "Pierwsze przeniesienie bazy na gita" tego rozdziału niniejszej instrukcji.

5. Naniesienie aktualizacji na źródła. Robimy to następująco:

   1. Jeśli do listy "remotes" nie podpięliśmy jeszcze repo standardowego, to należy podłączyć (git@git.office.sente.pl:dro/s4.git) jako nowy remote o nazwie "standard". W SourceTree jest to: Settings -> Add, podajemy nazwę i adres repo.

   2. Należy robić fetcha z repozytorium standard. W SourceTree: drzewo po lewej -> remotes -> standard -> fetch from standard.

   3. W zakładce "Stan aktualizacji klientów" sprawdzamy, która aktualizacja była ostatnio naniesiona u klienta. Dla wszystkich kolejnych aktualizacji, aż do najnowszej wykonujemy polecenie naniesienia aktualizacji: "git cherry-pick <SHA aktualizacji>" (należy znaleźć na standardowym repo brancha wersja_zero_plus_aktualizacje, i użyć SHA właściwych commitów na tym branchu)

   4. Rozwiązujemy ewentualne konflikty. Ponieważ zmian nanoszonych jest niewiele, a aplikacja klienta była już wcześniej aktualizowana, to konfliktów nie powinno być wiele. Do ich rozwiązania można stosować zalecenia z procesu pełnej aktualizacji.

   5. kompilujemy aplikację, aby się upewnić, że źródła c++ są poprawne. Jeśli pojawią się problemy, to robimy poprawki i je commitujemy.

   6. Po rozwiązaniu konfliktów commitujemy źródła na branchu "aktualizacja_do_XXX".

6. W tym momencie musimy zatrzymać pracę wszystkich użytkowników aplikacji.

7. Uruchamiamy w SH pełny proces aktualizacji i obserwujemy co się dzieje. UWAGA: Obecnie zalecamy użycie do tego SH z kanału beta. Jeśli proces się przerywa z błędem, to czytamy dlaczego, poprawiamy pliki źródłowe i ponawiamy proces. SH nanosi zmiany w trybie delty, więc błąd zawsze powoduje powrót bazy danych do stanu sprzed aktualizacji.

8. Jeśli proces aktualizacji zakończył się poprawnie to wykonujemy następujące czynności końcowe:

   1. odpalamy SET_ALL_GRANTS_FOR dla odpowiednich użytkowników

   2. commitujemy zmiany w plikach źródłowych, które musieliśmy zrobić, aby proces przeszedł poprawnie

   3. mergujemy brancha "aktualizacja_do_XXX" do brancha <klient>_master. Tutaj nie powinno być żadnych konfliktów.

   1.uruchamiamy proces deploymentu aplikacji opisany w rozdziale powyżej, który zbuduje dla klienta aplikację z brancha <klient>_master i umieści ją w repozytorium, z którego Starter pobiera aplikacje dla użytkowników.

   1. pozwalamy użytkownikom klienta zalogować się do aplikacji

   2. robimy wpis w rejestrze aktualizacji na zakładce "Stan aktualizacji klientów", aby mieć bieżącą informację, do jakiej aktualizacji został dociągnięty klient

   3. sprawdzamy jak będzie wyglądał pierwszy commit procesu autocommitu. Generalnie powinny się pojawić jedynie niewielkie zmiany kosmetyczne w plikach. Jeśli zmian jest podejrzanie dużo i dotyczą merytoryki kodu, to znaczy, że coś mocno poszło nie tak.

Sposób 4. Pełna aktualizacja do wersji bieżącej

Warunek początkowy: Proces ten stosujemy jedynie dla klientów uruchomionych na wersji 5.4.1 lub nowszej. Celem tego procesu jest podniesienie całej aplikacji (wszystkich modułów do jeszcze nowszej wersji, np wersji 5.7.3).

Materiały pomocnicze (rada: warto ustawić prędkość odtwarzania x1.5 i jakość 1080p):

Filmik ze szkolenia - kroki 1-4,
Filmik ze szkolenia - kroki 5-8

1. Ustalamy jaka jest aktualna wersja u klienta (powinna być zapisana w rejestrze aktualizacji w załadce "stan aktualizacji klientów") i do jakiej wersji chcemy się podnieść. Zalecamy podniesienie do najnowszego RTM-a. Tutaj można sprawdzić, która wersja jest najnowszym RTM-em.

2. Aby rozpocząć ten proces zamrażamy rozwój aplikacji klienta (od tego momentu nie grzebiemy w metadanych, chociaż użytkownicy mogą dalej pracować w aplikacji).

3. Ustawiamy się na branchu <klient>_master i odbijamy od niego nowego brancha o nazwie "aktualizacja_do_XXX", gdzie XXX jest pełnym trzyczęściowym numerem wersji standardu, do której będziemy się podnosić (np 5.4.12). Od tego momentu będziemy pracować na branchu aktualizacji.

4. Upewniamy się, że proces autocommitowania bazy danych opisany wcześniej zapewnił nam źródła bazy na gicie zgodne z faktycznym stanem aktualizowanej bazy danych. Jeśli nie mamy podłączonego procesu autocommitowania to wykonujemy zacommitowanie ręczne zmian zgodnie z punktem "Pierwsze przeniesienie bazy na gita" tego rozdziału niniejszej instrukcji.

5. Naniesienie aktualizacji na źródła. Robimy to następująco:

   1. Jeśli do listy "remotes" nie podpięliśmy jeszcze repo standardowego, to należy podłączyć (git@git.office.sente.pl:dro/s4.git) jako nowy remote o nazwie "standard". W SourceTree jest to: Settings -> Add, podajemy nazwę i adres repo.

   2. Należy robić fetcha z repozytorium standard. W SourceTree: drzewo po lewej -> remotes -> standard -> fetch from standard.

   3. Wykonujemy polecenie naniesienia aktualizacji: "git merge <SHA wersji>" (należy znaleźć na standardowym repo taga docelowej wersji i użyć SHA commitu tego taga)

   4. przeglądamy zmiany naniesione w procedurach XK_. Jeśli ich nie chcemy, to robimy discard

   5. Rozwiązujemy ewentualne konflikty. Standardowe zalecenia do rozwiązania konfliktów są następujące:

      1. dbscripts\descriptions -> resolve using "theirs" (bo nie ma sensu z tym walczyć). "Theirs" znaczy, że przenosimy plik w całości ze standardu.

      2. tr\ -> remove (gdyż konflikty powstają jedynie na transferówkach już wgranych lub nieistotnych w tej wersji. Transferówki nowe wejdą bez konfliktów)

      3. struktury, których klient na pewno nie używa (np w WMS-ie, jeśli u klienta nie odpalono WMSa) -> resolve using "theirs"

      4. sekcje s_appini -> użycie kdiff3 przez "Launch external merge tool" powinno samo w pełni rozwiązać konflikty

      Poza powyższymi konfliktów nie powinno być wiele. Do ich rozwiązanianajlepiej użyć kdiff3 przez wywołanie "Launch external merge tool".

   6. jeśli robimy równocześnie podniesienie technologiczne (bibliotek klienckich czyli: sdas3.bpl, sdastool3.bpl, neos3.bpl, itp) to commitujemy zmianę w pliku “core” wskazującą na aktualny commit w submodule core. Jeśli nie robimy nic w warstwie technologicznej, to discrdujemy zmiany w tym pliku.

   7. kompilujemy aplikację, aby się upewnić, że źródła c++ są poprawne. Jeśli pojawią się problemy, to robimy poprawki i je commitujemy.

   8. Po rozwiązaniu konfliktów commitujemy źródła na branchu “aktualizacja_do_XXX”.

6. W tym momencie musimy zatrzymać pracę wszystkich użytkowników aplikacji.

7. Uruchamiamy w SH pełny proces aktualizacji i obserwujemy co się dzieje. Jeśli proces się przerywa z błędem, to czytamy dlaczego, poprawiamy pliki źródłowe i ponawiamy proces. SH nanosi zmiany w trybie delty, więc błąd zawsze powoduje powrót bazy danych do stanu sprzed aktualizacji.

8. Jeśli proces aktualizacji zakończył się poprawnie to wykonujemy następujące czynności końcowe:

   1. odpalamy SET_ALL_GRANTS_FOR dla odpowiednich użytkowników

   2. commitujemy zmiany w plikach źródłowych, które musieliśmy zrobić, aby proces przeszedł poprawnie

   3. mergujemy brancha “aktualizacja_do_XXX” do brancha <klient>_master. Tutaj nie powinno być żadnych konfliktów.

   4. uruchamiamy proces deploymentu aplikacji opisany w rozdziale powyżej, który zbuduje dla klienta aplikację z brancha <klient>_master i umieści ją w repozytorium, z którego Starter pobiera aplikacje dla użytkowników. Jeśli nie mamy tego procesu to kompilujemy aplikację i ręcznie wgrywamy pliki do klienta.

   5. pozwalamy użytkownikom klienta zalogować się do aplikacji

   6. robimy wpis w rejestrze aktualizacji na zakładce “Stan aktualizacji klientów”, aby mieć bieżącą informację, do jakiej wersji został dociągnięty klient

   7. Jeśli mamy podłączony proces autocommitowania zmian, to sprawdzamy jak będzie wyglądał pierwszy commit procesu autocommitu. Generalnie powinny się pojawić jedynie niewielkie zmiany kosmetyczne w plikach. Jeśli zmian jest podejrzanie dużo i dotyczą merytoryki kodu, to znaczy, że coś mocno poszło nie tak.