Narzędzie do automatyzacji deploymentu IBM UrbanCode Deploy, poza podstawowymi funkcjonalnościami, pozwala na tworzenie rozszerzeń, które umożliwiają użytkownikowi dopasowanie narzędzia do potrzeb własnych i organizacji. Daje możliwość pisania skryptów bezpośrednio w kostce procesu (groovy) lub tworzenie pluginów. Najlepszym rozwiązaniem jest właśnie pisanie pluginów, ze względu na ich reużywalność w innych procesach lub aplikacjach. Tak naprawdę wszystkie kostki i elementy które są dostępne w UCD są pluginami, za pomocą których tworzymy procesy automatyzujące. Wartością dodaną jest możliwość pisania indywidualnych skryptów.
Wysokie wymagania naszych klientów sprawiają, że praca nad pluginami jest nasza codziennością. Modyfikujemy już istniejące oraz tworzymy całkowicie nowe rozwiązania. Na podstawie pluginu SetVersionStatus, służącego do nadawania statusu wersjom w celu promowania na kolejne środowiska, omówimy sposób w jaki pisze się pluginy w UrbanCodeDeploy. Plugin, który stworzyliśmy, powstał na potrzeby integracji Jira i UrbanCode Deploy. Integracja umożliwia w skrócie wywoływanie odpowiednich skryptów w UCD i otrzymanie statusu zwrotnego. Zaimplementowaliśmy 4 pluginy po stronie UCD i ułożyliśmy je w proces aplikacyjny o nazwie Jira oraz plugin stworzony po stronie Jira. Integracja została stworzona w celu wywoływania automatycznego deploymentu aplikacji z poziomu Jira.
Rozszerzenia do narzędzia składają się z kilku elementów. Sam skrypt piszemy w języku Groovy, czyli obiektowym języku skryptowym opartym na JAVIE i urozmaicamy kilkoma funkcjonalnościami takimi jak: domknięcia, przeciążenia operatorów czy operacje na kolejkach. Poza samym skryptem wykonującym konkretne zadania w skład pluginu wchodzą trzy pliki xml:
Plugin.xml
Info.xml
Upgrade.xml
Pierwszy plik xml czyli plugin.xml jest głównym plikiem konfiguracyjnym. Ten element ustala interfejs, odwzorowuje specyfikację działania i parametry wejściowy do wtyczki. Określamy tutaj elementy, które są widoczne przez użytkownika.
Jak widać na przykładzie, na początku pliku opisujemy id i nazwę pluginu, a w dalszej części definiujemy propertiesy, które będą następne widoczne w kostce dostępnej przy tworzeniu procesu. Określamy m.in. nazwę pola i wymagalność. Description określa opis działania pluginu. Ilość i rodzaj pól jakie definiujemy jest zależna tylko od autora i przeznaczenia rozszerzenia. SetVersionStatus do swojego działania potrzebuje informacji takich jak listy komponentów, loginy i hasła do UCD, listy komponentów i wersji oraz klucz do statusu wersji. Na końcu plugin.xml przeznaczone jest miejsce na wskazanie ścieżek do skrytpu. Dane zawarte w pliku info.xml określają autora, wersje i inne podstawowe informacje.
Plik upgrade.xml jest używany do wgrywania nowej wersji pluginu. Po zakończeniu prac na skryptem i plikami xml należy wszystkie pliki spakować do formatu .zip i przejść do UrbanCode Deploy w celu jego załadowania. W zakładce settings -> automation plugins jest widoczna lista pluginów wraz z opisem i wersją. W tym oknie także mamy możliwość załadowania nowego pluginu. Załadowaną wtyczkę możemy następnie wykorzystać tworząc proces, będzie ona dostępny na liście kostek dostępnych przy projektowaniu procesu.
Poniżej przykłady kilku innych wtyczek, które wykonaliśmy:
JDBC SQL Scripts
Głównym elementem jest tutaj plik kontrolny wraz z jego strukturą, zawierającą skrypty uruchamiane w odpowiedniej kolejności. Na początku następuje weryfikacja wszystkich połączeń bazodanowych używanych w pliku kontrolnym. W plikach properties określamy nazwę, plik wykonywalny sqlplus, lista plików kontrolnych wg. których będą uruchamiane skrypty, mapowanie identyfikatorów połączeń, mapowanie użytkowników baza hasło.
Przykładowy plik kontrolny:
sqlfile1.sql #RIT_DATABASE# rit continue
sqlfile2.sql #RIT_DATABASE# rit abort
Differential patch
Plugin służy do porównywania wersji. Jeżeli nastąpi próba zapatchowania niższej wersji niż jest obecna, proces zostaje przerwany wraz z wyświetleniem odpowiedniego komunikatu. Następnie wykonywana jest komenda svn diff na obu wersjach, a wynik działania jest zapisywany do pliku konfiguracyjnego.
Merge properties files
Plugin został stworzony w celu scalania plików properties. Wartości plików źródłowych są nadpisywane przez podane pliki z wartościami technicznymi i zapisywane w lokalizacji docelowej.
Zanim zabierzemy się za pisanie pluginu, warto odwiedzić stronę IBM i upewnić się, czy podobny plugin nie został już wcześniej stworzony. https://developer.ibm.com/urbancode/plugins/ibm-urbancode-deploy/
Obecnie na stronie dostępnych jest ponad 130 pluginów stworzonych przez użytkowników, jak i przez dostawcę oprogramowania. Możemy tam znaleźć naprawdę przydatne, gotowe rozszerzenia, służące np. do integracji narzędzia z innymi takimi jak Jira, HP Quality Center czy MS Sharepoint. Są to głównie serwery aplikacyjne, bazy danych, oprogramowanie do automatyzacji testów, systemy typu issue tracking czy platformy cloudowe. Część rozszerzeń, z których korzystamy, została już oficjalnie zaakceptowana przez IBM, pozostałe planujemy udostępnić do końca tego roku. Pluginy które są dostępnie na stronie są otwarte i możemy dostosować je do własnych potrzeb, modyfikując skrypt czy pliki xml.
