Ręczne wdrożenia. Ryzyka, których można uniknąć.

Typowy przebieg pracy pokazuje, gdzie praca utyka i które kroki mogą wykonać tylko pojedyncze osoby. Wspólnie analizujemy zmianę, budowanie, testy, przekazania i zatwierdzenie do produkcji. Nie chodzi przy tym o to, by z zasady likwidować każdą czynność wykonywaną ręcznie. Najpierw musi być jasne, jakiemu celowi ona służy i jakie informacje są potrzebne do podjęcia decyzji. Niektóre opóźnienia wynikają z braku dostępów, inne z niejasnej odpowiedzialności lub różnic w konfiguracji. Każda z tych przyczyn wymaga innego rozwiązania.

Na podstawie analizy opracowywane jest pierwsze zlecenie o jasno określonym zakresie. Określa ono, która część przebiegu pracy zostaje usprawniona, którzy uczestnicy biorą w tym udział i po czym można rozpoznać wynik. Uwzględniane są funkcjonujące procedury i dostępne narzędzia. Dzięki temu zmiana pozostaje dla Państwa zespołu łatwa do opanowania i można ją ocenić na podstawie rzeczywistego wydania. Zdobyte w ten sposób wnioski można następnie wykorzystać przy kolejnych aplikacjach, bez konieczności przestawiania od samego początku wszystkich procesów rozwoju i eksploatacji naraz.

Jeśli środowisko testowe i produkcyjne są skonfigurowane inaczej, udane testy tracą część swojej wartości informacyjnej. W uzgodnionym zakresie infrastruktura jest więc opisywana jako przejrzysta, wersjonowana konfiguracja. Zmiany można sprawdzić i przypisać do właściwego środowiska. Dochodzi do tego ścieżka wdrażania, której kroki są dokumentowane. Nie chodzi o to, by wszystkie środowiska były identyczne: zamierzone różnice pozostają widoczne, a niezamierzone odstępstwa łatwiej rozpoznać i omówić.

Wyniki budowania, testy i zatwierdzenia są łączone z odpowiednią zmianą. Dane dostępowe wymagają odrębnego zarządzania, a zmiany produkcyjne są wprowadzane zgodnie z uzgodnionymi decyzjami. Wspólnie ustala się, które kontrole odbywają się automatycznie i gdzie wciąż potrzebna jest ocena odpowiedzialnej osoby. Pełny przebieg pokazuje, czy uczestnicy potrafią obsługiwać ten proces i rozumieją jego wyniki. Dopiero wtedy techniczny pipeline staje się procedurą, na której rozwój i eksploatacja mogą się wspólnie opierać w codziennej pracy.

Procedura wydawania musi dawać jasność również wtedy, gdy jakiś krok się nie powiedzie. Kto ocenia błąd, jakie informacje są dostępne i kiedy można ponownie uruchomić proces? Sposoby wycofania zmian są omawiane z wyprzedzeniem, przy czym zmiany danych lub zależności zewnętrzne mogą wymagać szczególnej uwagi. Przywrócenie poprzedniej wersji aplikacji nie usuwa automatycznie każdego skutku zmiany produkcyjnej. Uzgodnione przypadki błędów są więc rozpatrywane na przykładzie konkretnego przebiegu i, o ile to przewidziano, wspólnie testowane.

Po przekazaniu również automatyzacja potrzebuje osób odpowiedzialnych. Narzędzia, aplikacja i infrastruktura zmieniają się, dlatego kontrole i konfigurację trzeba odpowiednio utrzymywać. Państwa zespół otrzymuje więc dokumentację i praktyczne wprowadzenie do uzgodnionego przebiegu. Istniejące ograniczenia są jasno wskazywane, a nie ukrywane za udanym przebiegiem demonstracyjnym. Dzięki temu rozwiązanie może być rozwijane po zakończeniu projektu i nie jest uzależnione od wiedzy osób, które je pierwotnie skonfigurowały.