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.