„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 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
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.
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. Pierwsza ocena wykonalności jest bezpłatna.