Instrukcja wydzielenia Core’a (S4 4.6 do Teneum 5.4)

Poniższa instrukcja została zrealizowana na bazie repozytorium Tofamy: podniesienie z wersji 4.1.7 na 5.4.17. Niektóre opisane poniżej kroki mogą nie być potrzebne dla podniesienia z wersji wyższych (np. 4.6), a dodatkowe kroki mogą pojawić się w sytuacji podniesienia z wersji niższych. Ponadto im więcej zmian indywidualnych w modułach biznesowych klienta tym więcej może wystąpić dodatkowych problemów. Należy pamiętać o ewentualnych zmianach technologicznych dedykowanych danemu klientowi. Jeśli chcemy je zachować, należy skontaktować się z ZRT aby ustalić jak przenieść je na standard.

Aby wydzielić core’a wykonujemy następujące kroki:

1. Ustalamy z opiekunem klienta, z którego repozytorium pobrać źródła S4 i na którym branchu znajduje się bieżąca wersja do przeniesienia. Ściągamy źródła i kompilujemy. Wersja musi się skompilować przed dalszymi krokami.

2. Od podnoszonego brancha odbijamy gałąź roboczą (np teneum5.4). Następnie dodajemy na niej z poziomu konsoli submoduł “core” poleceniem: git submodule add git@git.office.sente.pl:dro/s4core.git core oraz commitujemy zmiany. W submodule ustawiamy się na ostatnim commicie gałęzi 5.4 lub ostatniej tagowanej wersji jeśli na niej chcemy budować wersję dla klienta. Commitujemy zmianę przepięcia core’a.

3. Uruchamiamy buildera z grupą projektów eSystem.groupproj. Robimy screenshota okienka z projektami, i wklejamy do painta, żeby pamiętać kolejność modułów biznesowych klienta. Aby w przyszłości zachować odpowiednią kolejność usuwamy wszystkie projekty. Uruchamiamy drugiego buildera ze standardowymi źródłami teneum z wersji 5.4 aby widzieć prawidłową kolejność projektów technologicznych.

4. W celu uniknięcia pomyłki, usuwamy z głównego repozytorium stare foldery technologiczne: Neos3, ProReport3, SDAS3 i SdasTool3. Dodajemy w pierwszym builderze projekty technologiczne z submodułu core (aż do devices), następnie neos3, TeneumClient i sserwer3 z submodułu core. Następnie moduły biznesowe w kolejności z painta (zazwyczaj począwszy od common3). Nie dodajemy tutaj LogStartTime, DeviceTest, które są technologiczne, ale u klientów niepotrzebne. Zapisujemy zmiany w projektach w pierwszym builderze oraz zamykamy buildery w następującej kolejności: najpierw drugi, potem pierwszy.

5. W programie Notepad++ otwieramy wszystkie pliki projektów biznesowych *.cbproj (wszystkie, które nie są w core) aby pozmieniać referencje do projektów technologicznych. Klikamy ctrl+H i każde wystąpienie ścieżki ..\sdas3 zamieniamy na ..\core\sdas3 oraz ..\sdastool3 na ..\core\sdastool3. Jeśli mamy stare mapowania przez S:\ to robimy analogicznie, aby efekt końcowy był ten sam.

6. Uruchamiamy buildera z poprawionymi projektami i budujemy wszystkie projekty technologiczne. Jeśli coś się nie skompilowało/zlinkowało to najprawdopodobniej pominęliśmy przy dodawaniu jakiś projekt technologiczny lub pomyliliśmy kolejność.

7. (Od wersji 5.4.18 ten krok pomijamy) W projekcie SSID wycinamy pliki z folderu drukfisk oraz biblioteki libposcmbth.lib i Serial.lib. Usuwamy też folder z dysku. Dodajemy referencje do projektu drukfisk z core’a w projekcie SSID.

8. Z projektu common3.bproj usuwamy browsesecuritylogf, który został przeniesiony do technologii. Można to zrobić w programie Notepad++. Usuwamy też useform tej formy i rejestrację w common3.cpp.

9. Buildujemy pozostałe projekty (biznesowe). Jeśli natrafimy na błąd w kompilacji porównujemy analogiczny fragment kodu ze standardu i sprawdzamy czy się czymś różni. Nie usuwamy “nieużywanych referencji” podczas zapisu plików .cpp zawierających szablon dfm, gdyż te referencje często są niejawnie wykorzystywane. Najczęstsze błędy:

   • “Unable to open include file…” - prawdopodobnie brakuje ścieżki w projekcie w includach do tego pliku.
   • [BCC32 Error] commonact.cpp(3434): E2316 'PrintDocument' is not a member of 'TEmbeddedED' - usuwamy metodę PrintHTML.
   • Problem z DB.storage->PutFile - zastępujemy wartość typu UnicodeString podaną wprost w 2 argumencie zmienną z podstawioną tą wartością.
   • Inicjalizacja FactoryProperties - należy usunąć trzeci niepotrzebny parametr.
   • max i min zamieniamy na std::max, std::min.
   • DB.settings->LogProfiler - zamieniamy na TLogFile::LogProfiler.

10. Warto wyczyścić pozostałe zbędne pliki z repozytorium: katalog TestComplete, pliki projektów esystem3 lub sentes4. Po wszystkim sprawdzamy, czy całość się buduje.

11. Wykonujemy ostateczny test budowania - ściągamy repo w inne miejsce na dysku i tam na czystej instancji w builderze wybieramy opcję Build all. Jeśli wszystko się buduje, to znaczy, że core został wydzielony poprawnie. Można zacząć testy uruchomieniowe aplikacji.