Narzędzia programisty PL/SQL - wstęp
Gdy zaczynałem pracę przy bazach danych Oracle jako programista to procesy wytwórcze były żenująco ręczne, w żaden sposób niezaautomatyzowane. Brak było żadnego systemu zarządzania wersjami kodu, a właściwie był ręczny - robiło się tworząc kolejne katalogi z wersjami i dokładnym komentowaniem zmian z jawnym przypisaniem zmiany do autora. Zakomentowywany był stary kod i wstawiony nowy miał jasno opisany początek i koniec, numer zadania i inicjały autora. Jak chciałeś robić zmianę to developowałeś bezpośrednio zmianę na bazie DEV, gdzie w specyfikacji było specjalne miejsce na wpisanie inicjałów programisty rezerwującego w danym momencie pakiet. Potem ręczne wdrażanie kolejnych obiektów na bazę i skryptów zmieniających. Można tak robić, ale też da się prościej. W obecnym projekcie w innej firmie wyszła potrzeba optymalizacji procesu wytwórczego i został wypracowany nowy model tworzenia i wdrażania. Jest on dużo bardziej sprawny i sam z siebie eliminuje wiele błędów, które mogą wyjść dopiero na ostatecznym środowisku
Warstwy nowego procesu:
- git system zarządzania kodem źródłowym
- liquibase program do wykonywania i pilnowania wdrożeń
- docker separowane środowisko do szybkiego tworzenia bazy dla każdego developera
- utPLSQL framework do testów jednostkowych
- --jailer program do przygotowywania przypadków testowych z istniejącego środowiska-- - nie przyjął się
- --pldoc jako standard dokumentowania kodu plsql-- - nie przyjął się
- opcjonalnie jira/bitbucket/bamboo jako jedno z możliwych rozwiązań webowych do zarządzania wdrożeniami z poziomu spójnego systemu webowego
W tej chwili obsługiwane są pełne ścieżki wytwórcze dla kilku coreowych systemów. Zastosowane rozwiązania umożliwiają odseparowany rozwój poszczególnych części systemu, gdzie poszczególni programiści nie wchodzą sobie w paradę - pracują na oddzielnych bazach. Zaczynają z tym samym startowym zestawem danych. Integracja zmian poszczególnych programistów pracujących równolegle odbywa się po akceptacji kodu i zaliczeniu standardowego zestawu testów jednostkowych. Po tym tworzona jest paczka standardowo wdrażana na środowiska developersko testowe automatycznie, a gdy przejdzie testy to dokładnie ta sama paczka wdrażana na wyższe środowiska.
Skończyły się problemy z przypadkowymi zmianami wywalającymi działające już partie systemu. Admini nie narzekają już na jakość ręcznie tworzonych paczek wdrożeniowych - bardzo rzadko wypływają jakieś problemy przy wdrożeniach. System działa poprawnie po wykonanych wdrożeniach i ewentualnej rekompilacji.
W kolejnych artykułach opiszę kolejne warstwy i etapy tworzenia kodu baz danych.