[Uwaga] Ten artykuł został pierwotnie przygotowany w języku angielskim i został przetłumaczony na język polski.
Mówiąc w skrócie, komenda project, wraz ze swoimi subkomendami, pomoże Ci z łatwością zarządzać zmianami w bazie danych. W tym samouczku krok po kroku opiszę, jak używać tego pomocnego narzędzia CI/CD w nowych lub istniejących projektach.
Mam pusty folder SQLCL_PROJECT_DB_APEX w moim VS Code.
Teraz łączę się z moim schematem HR na DEV.
sql -name HR_DEV_OCI
Nazywam mój projekt „PRETIUS” i chcę go zainicjalizować ze schematem „HR”.
project init -name PRETIUS -schemas HR
Widoczne poniżej foldery i pliki zostały automatycznie utworzone przez SQLcl.
Teraz muszę zainicjalizować nowe repozytorium GIT dla utworzonych plików i wykonać commit.
!git init --initial-branch=main !git add . !git commit -m "initializing repository with default project PRETIUS files"
Teraz tworzę branch „base-release”, łączę się z HR_DEV i eksportuję obiekty bazy danych oraz aplikacje APEX do plików. Kroki są takie same dla nowych projektów. Eksportujesz pliki, gdy tylko w bazie danych zostaną utworzone jakieś obiekty.
--this command creates new branch and switches to it !git checkout -b base-release
Teraz eksportuję wszystkie obiekty bazy danych i aplikacje APEX z DEV.
--connected to HR_DEV_OCI, execute this project export
Moje obiekty bazy danych i aplikacje APEX zostały wyeksportowane.
Teraz wykonuję commit mojego base-release do GIT.
!git add . !git commit -m "Base release"
W następnym kroku używam komendy project stage, aby stage’ować moje zmiany – komenda porównuje branch main z base-release.
--DOCKER_HR_DEV project stage
Pliki niezbędne do wdrożenia zostały automatycznie utworzone w lokalizacji /dist/releases/next.
Teraz używam komendy project verify, aby sprawdzić projekt pod kątem ewentualnych błędów i ostrzeżeń.
project verify -verbose
Wszystko jest gotowe.
Nazywam moje bazowe wydanie „wersją 1.0”.
--HR_DEV_OCI project release -version 1.0 -verbose
Terminal SQLcl jasno informuje, co się stało:
Moje wydanie przenosi się do /releases/1.0, a moje następne wydanie (next) jest puste.
Używając komendy gen-artifact generuję artefakt reprezentujący aktualny status mojego projektu.
--HR_DEV_OCI project gen-artifact -version 1.0-base-release
Nowy plik ZIP PRETIUS-1.0-base-release.zip zostaje wygenerowany (zauważ, że artefakty nie są wersjonowane w GIT).
Skrypt wdrożeniowy jest gotowy, więc mogę go commitować.
!git add . !git commit -m "Version 1.0"
--HR_PROD_OCI project deploy -file artifact/PRETIUS-1.0-base-release.zip -verbose
--HR_PROD_OCI liquibase changelog-sync -chf dist/releases/main.changelog.xml
W tym momencie moje środowisko DEV (base-release) jest równe PROD (main). Dlatego muszę zmergować branch base-release do brancha main.
Najpierw muszę zmienić pewne rzeczy bezpośrednio w środowisku DEV (używając VS Code, SQL Dev itp.). Dokonuję zmian w aplikacjach APEX na DEV.
INSERT INTO HR.COUNTRIES (COUNTRY_ID, COUNTRY_NAME, REGION_ID) VALUES ('PL', 'Poland', '10');
CREATE TABLE HR.PARAMETERS (NAME VARCHAR2(50),
VALUE VARCHAR2(50));
ALTER TABLE HR.EMPLOYEES
ADD (ADDRESS VARCHAR2(100) );
CREATE OR REPLACE PROCEDURE HR.SECURE_DML
IS
BEGIN
IF TO_CHAR(SYSDATE, 'HH24:MI') not between '08:00' and '18:00'
or TO_CHAR(SYSDATE, 'DY') in ('SAT', 'SUN')
THEN
RAISE_APPLICATION_ERROR(-20205,
'You may only make changes during normal office hours (this bracket is a change)');
END IF;
END SECURE_DML;
/
INSERT INTO HR.PARAMETERS (name, value) VALUES ('MY_BLOG_URL','rafal.hashnode.dev');
COMMIT;
Teraz tworzę nowy branch GIT o nazwie „1.1”.
Aby wyeksportować zmiany, używam komendy project export:
--on branch 1.1 --connected to HR_DEV_OCI project export
Ta komenda eksportuje aktualny stan obiektów bazy danych DEV oraz aplikacji APEX.
Po wyeksportowaniu czas na commit zmian na branchu 1.1.
!git add . !git commit -m "Files for version 1.1"
Najpierw używam komendy project stage:
--HR_DEV_OCI project stage
Ta komenda tworzy nowe pliki dla mojego wydania 1.1.
Jak zapewne pamiętasz, na moim środowisku DEV, oprócz zmian w tabelach EMPLOYEES i PARAMETERS oraz procedurze SECURE_DML, wykonałem również dwa inserty do tabel COUNTRIES i PARAMETERS. Jest to coś, czego SQLcl nie będzie śledzić automatycznie, i w tym celu musimy użyć komendy add-custom.
Dlatego utworzyłem dwa pliki dla DML w obu tabelach:
--HR_DEV_OCI project stage add-custom -file-name dml_parameters project stage add-custom -file-name dml_countries
A SQLcl automatycznie utworzył te pliki:
Nie ma potrzeby niczego zmieniać w tych plikach. Umieszczam tam jedynie moje skrypty insert:
Raz jeszcze używam komendy project verify, aby sprawdzić, czy wszystko jest w porządku.
--HR_DEV_OCI project verify
Wszystko gotowe.
Używam następującej komendy:
--HR_DEV_OCI project release -version 1.1 -verbose
Terminal SQLcl jasno informuje, co się stało:
Moje wydanie przenosi się do /releases/1.1, a moje następne wydanie (next) jest puste.
Lubię to robić, aby wszystko było przejrzyste. Ponieważ moje wydanie jest gotowe na PROD, powinienem je wdrożyć z brancha main (PROD). Dlatego wykonuję następujące czynności:
Teraz tworzę artefakt dla mojej wersji 1.1, używając komendy gen-artifact:
--HR_PROD_OCI --on GIT branch MAIN(prod) project gen-artifact -version 1.1
Jestem gotowy do wdrożenia moich zmian na PROD za pomocą komendy project deploy:
--HR_PROD_OCI project deploy -file artifact/PRETIUS-1.1.zip -verbose
Terminal SQLcl wyraźnie informuje, co się stało, ale co najważniejsze, wszystkie moje zmiany, w tym APEX, zostały wdrożone na PROD:
I to by było na tyle. Mam nadzieję, że spodobał Ci się ten artykuł. Radzę poeksperymentować z komendą project i sprawdzić, czy pasuje ona do Twoich konkretnych potrzeb CI/CD. Osobiście jestem pod sporym wrażeniem jej możliwości i możliwe, że będzie to jedyne narzędzie CI/CD, którego będę używać w wielu projektach APEX.
Jeśli masz jakieś pytania, skontaktuj się ze mną pod adresem rgrzegorczyk@pretius.com. I oczywiście sprawdź inne moje artykuły na tym blogu:
