Dzień dobry, Hub!
Dzisiaj chciałbym podzielić się jednym ze sposobów, jak za pomocą wykonać zadanie w Jenkins najbardziej unifikujący i zrozumiały sposób dla użytkownika.
Wprowadzenie
Akronim DevOps od dawna nie jest niczym nowym dla społeczności IT. Wielu ludzi kojarzy frazę „wprowadzić DevOps” z jakimś magicznym przyciskiem, po naciśnięciu którego kod aplikacji automatycznie zamienia się w wdrożoną i przetestowaną aplikację (wszystko jest w rzeczywistości bardziej skomplikowane, ale abstrahujemy od wszystkich procesów).
Zatem otrzymaliśmy zamówienie na stworzenie takiego magicznego przycisku, aby administratorzy mogli wdrażać aplikację za jednym kliknięciem. Istnieją różne sposoby realizacji tego zadania: od napisania bota dla dowolnego z komunikatorów do opracowania oddzielnej aplikacji. Niemniej jednak celem jest uczynienie uruchamiania kompilacji i wdrażania aplikacji najbardziej przejrzystym i wygodnym.
W naszym przypadku użyjemy Jenkins.
Zadanie
Stworzyć wygodną pracę w Jenkins, która będzie uruchamiać kompilację i (lub) wdrożenie wybranego mikroserwisu w określonej wersji.
Dane wejściowe
Mamy kilka repozytoriów, w których znajduje się kod źródłowy różnych mikroserwisów.
Określenie parametrów
Do naszej pracy powinny trafiać następujące parametry:
- URL repozytorium z kodem mikroserwisu, który chcemy skompilować i wdrożyć podczas uruchamiania pracy.
- ID commita, z którego będzie pochodziła kompilacja.
AS IS
Najprostszym sposobem wykonania zadania jest stworzenie dwóch parametrów typu String.
W tym przypadku użytkownik będzie musiał ręcznie wprowadzić ścieżkę do repozytorium i id commita, co, przyznacie, nie jest zbyt wygodne.
AS TO BE
A teraz spróbujmy innego typu parametrów, aby omówić wszystkie jego zalety.
Utworzymy pierwszy parametr typu Choice Parameter, a drugi — Active Choices Reactive Reference Parameter. Do parametru typu Choice ręcznie dodamy w polu Choices nazwy repozytoriów, w których przechowywany jest kod naszych mikroserwisów.
Jeśli ten artykuł spodoba się czytelnikom, w następnym opiszemy proces konfigurowania zadań w Jenkins, używając opisu przez kod (Configuration as Code), co oznacza, że nie będziemy musieli ręcznie wprowadzać nazw repozytoriów i tworzyć parametrów, wszystko odbędzie się automatycznie (nasz kod otrzyma listę repozytoriów z SCM i stworzy parametr z tą listą).
Wartości drugiego parametru będą wypełniane dynamicznie, w zależności od tego, jakie wartość przyjmie pierwszy parametr (test1 lub test2), ponieważ każde repozytorium ma swoją własną listę commitów.
Active Choices Reactive Reference Parameter ma następujące pola do wypełnienia:
- Nazwa – nazwa parametru.
- Script – kod, który będzie wykonywany za każdym razem, gdy wartość parametru w polu Referenced parameter zostanie zmieniona (w naszym przypadku, kiedy będziemy wybierać między test1 a test2).
- Opis – krótki opis parametru.
- Choice Type – typ obiektu zwracanego przez skrypt (w naszym przypadku będziemy zwracać kod html).
- Referenced parameter – nazwa parametru, przy zmianie wartości którego będzie wykonywany kod z sekcji Script.
Przejdźmy bezpośrednio do wypełnienia najważniejszego pola w tym parametrze. Mamy do wyboru dwa rodzaje realizacji: użycie Groovy Script lub Scriptler Script.
Wybieramy pierwsze, ponieważ Scriptler to tylko wtyczka, która przechowuje wcześniej napisane skrypty i pozwala używać ich w innych zadaniach bez ponownego kopiowania i wklejania.
Kod Groovy do uzyskania wszystkich commitów z wybranego repozytorium:
AUTH = "login i hasło w Base64"
GIT_URL = "url do Twojego SCM (https://bitbucket.org/)"
PROJECT_NAME = "nazwa obszaru projektu, w którym znajdują się repozytoria"
def htmlBuild() {
html = """
<html>
<head>
<meta charset="windows-1251">
<style type="text/css">
div.grayTable {
text-align: left;
border-collapse: collapse;
}
.divTable.grayTable .divTableCell, .divTable.grayTable .divTableHead {
padding: 0px 3px;
}
.divTable.grayTable .divTableBody .divTableCell {
font-size: 13px;
}
</style>
</head>
<body>
"""
def commitOptions = ""
getCommitsForMicroservice(MICROSERVICE_NAME).each {
commitOptions += "<option style='font-style: italic' value='COMMIT=${it.getKey()}'>${it}</option>"
}
html += """<p style="display: inline-block;">
<select id="commit_id" size="1" name="value">
${commitOptions}
</select></p></div>"""
html += """
</div>
</div>
</div>
</body>
</html>
"""
return html
}
def getCommitsForMicroservice(microserviceRepo) {
def commits = [:]
def endpoint = GIT_URL + "\/rest\/api\/1.0\/projects\/${PROJECT_NAME}\/repos\/${microserviceRepo}\/commits"
def conn = new URL(endpoint).openConnection()
conn.setRequestProperty("Authorization", "Basic ${AUTH}")
def response = new groovy.json.JsonSlurper().parseText(conn.content.text)
response.values.each {
commits.put(it.displayId, it.message)
}
return commits
}
return htmlBuild()Nie wdając się w szczegóły, kod ten przyjmuje nazwę mikrousługi (MICROSERVICE_NAME), wysyła zapytanie do Bitbucket (metoda getCommitsForMicroservice), używając jej API, i otrzymuje id oraz wiadomość commitów dla danej mikrousługi.
Jak już wcześniej wspomniano, kod ten powinien zwracać html, który będzie wyświetlany na stronie Build with Parameters w Jenkins, dlatego wszystkie uzyskane wartości z Bitbucket opakowujemy w listę i dodajemy do select.
Po wykonaniu wszystkich czynności powinniśmy uzyskać taką ładną stronę. Build with Parameters.
Jeśli wybrano mikrousługę test1:
Jeśli wybrano mikrousługę test2:
Zgadzam się, że użytkownikowi wygodniej będzie współpracować z twoim zadaniem w ten sposób, niż za każdym razem kopiować URL i szukać odpowiedniego id commitu.
P.S. W tym artykule przedstawiono bardzo uproszczony przykład, który być może nie ma praktycznego zastosowania w tej formie, ponieważ konfiguracje mają znacznie więcej różnych parametrów, ale celem tego artykułu było pokazanie działania narzędzia, a nie przedstawienie gotowego rozwiązania.
P.S.S. Jak już wcześniej pisałem, jeśli ten artykuł okaże się przydatny, to następny będzie dotyczył dynamicznego konfigurowania zadań Jenkins za pomocą kodu.
Źródło: habr.com
