Integracja bez dokumentacji: naprawiać po kimś czy zbudować od nowa?

Skąd się biorą integracje, których nikt nie rozumie

Scenariusz jest prawie zawsze ten sam. Kilka lat temu firma potrzebowała szybko połączyć sklep albo BaseLinker z programem handlowym. Zrobił to informatyk na etacie, znajomy albo mała firma. Działało, więc nikt nie zamawiał opisu. Potem ta osoba odeszła, a integracja została na serwerze jako czarna skrzynka. Dziś każda prośba „dodajmy jeszcze jedno pole” zaczyna się od pytania, czy w ogóle wiadomo, gdzie to zmienić.

Objawy, że integracja stała się ryzykiem

• Ktoś musi ją uruchamiać ręcznie, a gdy jest na urlopie, zamówienia albo stany się nie synchronizują.
• Po aktualizacji programu handlowego albo sklepu coś przestaje działać i nikt nie wie dlaczego.
• Nie ma żadnego zapisu, co integracja przesłała i kiedy, więc błąd wychodzi dopiero przy reklamacji albo inwentaryzacji.
• Nie wiadomo, gdzie są hasła i klucze, których używa, ani kto ma do nich dostęp.
• Wykonawca, który mógłby ją poprawić, odmawia albo podaje wycenę „po zapoznaniu się z kodem”.

Jak ocenić integrację w godzinę

Do tej oceny nie trzeba być programistą. Wystarczy dostęp do serwera, na którym działa integracja, oraz osoba, która ją obsługuje na co dzień. Odpowiedz na osiem pytań:

1. Czy istnieje jakikolwiek opis: umowa z wykonawcą, instrukcja, korespondencja z ustaleniami?
2. Czy integracja działa sama (harmonogram), czy wymaga uruchomienia przez człowieka?
3. Czy zapisuje dziennik: co przesłała, kiedy i z jakim wynikiem?
4. Czy ktoś dostaje powiadomienie, gdy coś się nie uda?
5. Z ilu plików i jakiego języka się składa, i czy kod jest w repozytorium z historią zmian, czy tylko na serwerze?
6. Jakich danych dostępowych używa i gdzie są zapisane: w kodzie czy w bezpiecznym miejscu?
7. Kiedy ostatnio była zmieniana i czy ktoś pamięta, co wtedy zmieniono?
8. Co dokładnie przestanie działać w firmie, jeśli integracja stanie na dwa dni?

Jeśli na większość pytań odpowiedź brzmi „nie wiadomo”, każda zmiana w tej integracji jest ryzykowna, niezależnie od tego, kto ją wykona.

Kiedy poprawiać, a kiedy budować od nowa

Z mojego doświadczenia: gdy integracja powstała bez opisu i była już kilka razy poprawiana przez różne osoby, rozpracowanie jej i bezpieczna poprawka zajmują często tyle czasu, co zbudowanie nowej na sprawdzonych narzędziach. Różnica jest taka, że po nowej zostaje opis, dziennik i powiadomienia, a po poprawce nadal czarna skrzynka, tylko z jedną zmianą więcej.

Jak przejąć integrację bez zatrzymania sprzedaży

1. Zrób kopię kodu i konfiguracji, zanim cokolwiek zmienisz, i zapisz, gdzie leży.
2. Spisz, co integracja robi dziś: jakie dane, w którą stronę, jak często. To pierwsza strona przyszłej dokumentacji.
3. Przenieś hasła i klucze z kodu do bezpiecznego magazynu i wymień je, jeśli znał je ktoś spoza firmy.
4. Nową integrację uruchom równolegle ze starą na kilka dni i porównuj wyniki, zamiast przełączać wszystko jednego dnia.
5. Starą wyłącz dopiero wtedy, gdy wyniki się zgadzają, i zostaw ją zarchiwizowaną na wypadek, gdyby trzeba było coś sprawdzić.

Minimum dokumentacji po każdej integracji

Żeby za kilka lat nie wrócić do tego samego problemu, przy zamawianiu nowej integracji wpisz do umowy, że wykonawca przekazuje:

• opis na jedną lub dwie strony: co integracja robi, w którą stronę idą dane i jak często,
• listę pól, które przesyła, z nazwą po obu stronach,
• informację, gdzie działa, jak ją uruchomić i zatrzymać oraz gdzie są dane dostępowe,
• opis, co się dzieje przy błędzie i kto dostaje powiadomienie,
• kod w repozytorium firmy, a nie wyłącznie na serwerze albo u wykonawcy.

FAQ: najczęstsze pytania