„A co, jeśli po aktualizacji nasze przeróbki przestaną działać?". To jedno z pierwszych pytań, jakie słyszę, gdy firma na Impuls EVO myśli o dodatkowej funkcji czy integracji. Obawa jest słuszna: źle zrobiona modyfikacja potrafi zniknąć albo popsuć się przy najbliższej aktualizacji BPSC ERP. Ale to kwestia sposobu, w jaki zmiana została zaprojektowana, a nie tego, czy system w ogóle wolno rozwijać.
Poniżej wyjaśniam, dlaczego modyfikacje czasem nie przeżywają aktualizacji i jak je prowadzić, żeby przeżywały.
Dlaczego modyfikacje znikają po aktualizacji
Problem prawie zawsze sprowadza się do jednego: zmiana została wprowadzona w standardzie systemu, zamiast obok niego. Jeśli ktoś edytuje standardowy obiekt, procedurę czy tabelę dostarczaną przez producenta, to aktualizacja, która nadpisuje te elementy własnymi wersjami, po prostu skasuje wprowadzone zmiany. System wraca do stanu fabrycznego, a firma odkrywa to zwykle w najgorszym momencie.
To nie znaczy, że Impulsa nie da się bezpiecznie rozbudowywać. Znaczy tylko, że trzeba to robić z głową.
Jak robić to dobrze
Oddziel swoje rozwiązanie od standardu. Zamiast edytować standardowe procedury, buduje się własne obiekty i pakiety PL/SQL, które żyją obok systemu. Zamiast dopisywać kolumny do standardowych tabel, zwykle lepiej użyć własnych tabel powiązanych relacją. Aktualizacja nadpisuje standard, ale Twoich obiektów nie dotyka.
Wpinaj się w punktach do tego przeznaczonych. Impuls ERP (Impuls EVO / BPSC ERP) jest elastyczny: otwarta baza Oracle i logika w .NET dają miejsca, w których można podpiąć własną logikę bez ingerencji w rdzeń. To one pozwalają rozszerzać system stopniowo, bez przebudowy całości.
Dokumentuj i wersjonuj. Każda modyfikacja powinna być opisana i trzymana w repozytorium, żeby po aktualizacji dało się szybko sprawdzić, co i gdzie zostało dodane, i w razie potrzeby odtworzyć albo dostosować.
Testuj na kopii przed produkcją. Nową wersję systemu warto zderzyć z modyfikacjami na środowisku testowym, zanim trafią na produkcję. Ewentualny konflikt wychodzi wtedy w bezpiecznym miejscu, a nie na oczach użytkowników.
Co przetrwa, a co nie
Rozwiązania oddzielone od standardu, czyli własne pakiety, tabele i aplikacje wpięte w przewidziane do tego miejsca, przechodzą przez aktualizacje bez szwanku albo wymagają najwyżej drobnego dostosowania. Zmiany wprowadzone bezpośrednio w rdzeniu prędzej czy później zostaną nadpisane. Dlatego trwałość zaczyna się już na etapie projektu, a nie przy pierwszej aktualizacji.
Dlaczego to jeden z moich priorytetów
Jeśli w Twoim Impulsie już są przeróbki, a nie ma kto ich pilnować przy kolejnych wersjach systemu, to jest dokładnie ta praca, którą prowadzę na godziny — opisuję ją na stronie o wsparciu i konsultacjach dla Impuls EVO.
Odporność na aktualizacje traktuję jako część zadania, nie dodatek. Buduję od bazy Oracle i PL/SQL, przez logikę w .NET, po interfejs, a każdą zmianę oddzielam od standardu systemu. Kod, który powstaje na Twoje zlecenie, przekazuję razem z prawami, więc zostaje u Ciebie, łącznie z dokumentacją potrzebną przy przyszłych aktualizacjach.
Pytania o modyfikacje i aktualizacje
Czy modyfikacje unieważnią wsparcie producenta?
Wsparcie dotyczy standardu systemu, a nie tego, co stoi obok niego. Dlatego właśnie zmiany prowadzę w oddzielnych obiektach: jeśli producent ma zdiagnozować problem w swoim module, robi to na swoim kodzie, nietkniętym. Konkretne zapisy warto sprawdzić w Waszej umowie serwisowej, bo to ona rozstrzyga, a nie sposób wykonania zmiany.
Skąd wiadomo, czy istniejące przeróbki są bezpieczne?
Z przeglądu bazy. Widać w niej, czy zmiany siedzą w standardowych obiektach producenta, czy we własnych. To sprawdzenie zajmuje kilka godzin i daje odpowiedź, zanim aktualizacja da ją sama, w najgorszym momencie.
Co się dzieje, gdy modyfikacja jednak wejdzie w konflikt z aktualizacją?
Dostosowanie, nie przepisywanie od zera. Jeśli zmiana jest oddzielona od standardu, konflikt dotyczy zwykle jednego punktu wpięcia, a nie całej logiki. Dlatego testowanie nowej wersji na kopii przed produkcją ma sens — konflikt wychodzi wtedy w bezpiecznym miejscu.
Kto ma prawa do kodu modyfikacji?
Wy. Kod powstający na Wasze zlecenie przekazuję razem z prawami i dokumentacją, zgodnie z umową. To też jest element odporności na aktualizacje: jeśli za rok trzeba coś dostosować, nie zależy to od tego, czy jestem dostępny.
Czy każda zmiana wymaga środowiska testowego?
Praktycznie tak. Bez kopii nie da się zderzyć nowej wersji systemu z modyfikacjami inaczej niż na produkcji, czyli na oczach użytkowników. Jeśli środowiska testowego nie ma, warto zacząć od jego postawienia — to zwykle najlepiej wydany dzień w całym projekcie.
Masz modyfikacje, o które się boisz?
Jeśli w Twoim Impulsie są już przeróbki i nie wiesz, czy przeżyją najbliższą aktualizację, albo planujesz nową funkcję i chcesz mieć pewność, że będzie trwała, napisz. Sprawdzę, jak to wygląda po stronie bazy, i podam, co da się zrobić, zanim cokolwiek ruszy.