Buon pomeriggio, Habr!
Oggi vorrei condividere uno dei modi per utilizzare per rendere il compito in Jenkins modo più unificato e comprensibile per l'utente.
Introduzione
Abbreviazioni come DevOps non sono più una novità per la comunità IT. Molte persone associano la frase «fare DevOps» a un pulsante magico che, una volta premuto, trasforma automaticamente il codice dell'applicazione in un'applicazione distribuita e testata (in realtà è tutto più complesso, ma ci asteniamo da tutti i processi).
Quindi, ci è stato chiesto di creare un pulsante magico che permetta agli amministratori di distribuire l’applicazione con un solo clic. Ci sono vari modi per realizzare questo compito: dalla scrittura di un bot per uno dei messaggeri alla creazione di un'applicazione dedicata. Tuttavia, l'obiettivo rimane lo stesso: rendere il lancio della build e della distribuzione dell'applicazione il più chiaro e conveniente possibile.
Nel nostro caso utilizzeremo Jenkins.
Compito
Creare un job Jenkins conveniente che avvii la build e/o il deploy del microservizio scelto in una specifica versione.
Dati di input
Abbiamo diversi repository contenenti il codice sorgente di vari microservizi.
Definizione dei parametri
Il nostro job deve ricevere i seguenti parametri:
- URL del repository con il codice del microservizio che vogliamo costruire e distribuire quando avviamo il job.
- ID del commit da cui partirà la build.
AS IS
Il modo più semplice per completare questo compito è creare due parametri di tipo String.
In questo caso, l'utente dovrà inserire manualmente il percorso del repository e l'id del commit, il che, ammettiamolo, non è molto comodo.
AS TO BE
Ora proviamo un altro tipo di parametri per esaminare tutte le sue potenzialità.
Creeremo il primo parametro come Choice Parameter e il secondo come Active Choices Reactive Reference Parameter. Nel parametro di tipo Choice inseriremo manualmente nel campo Choices i nomi dei repository dove è conservato il codice dei nostri microservizi.
Se questo articolo piace al pubblico, nel prossimo descriverò il processo di configurazione delle attività in Jenkins, utilizzando la descrizione tramite codice (Configuration as code), cioè non dovremo inserire manualmente i nomi dei repository e creare parametri; tutto avverrà automaticamente (il nostro codice otterrà l'elenco dei repository da SCM e creerà un parametro con questo elenco).
I valori del secondo parametro verranno popolati dinamicamente, a seconda del valore assunto dal primo parametro (test1 o test2), dato che ogni repository ha il proprio elenco di commit.
Active Choices Reactive Reference Parameter ha i seguenti campi da compilare:
- Name – nome del parametro.
- Script – codice che verrà eseguito ogni volta che il valore del parametro nel campo Referenced parameter viene modificato (nel nostro caso, quando selezioniamo tra test1 e test2).
- Descrizione – breve descrizione del parametro.
- Choice Type – tipo di oggetto restituito dallo script (nel nostro caso restituiamo codice html).
- Referenced parameter – nome del parametro, la cui modifica nel valore attiverà il codice della sezione Script.
Passiamo ora alla compilazione del campo principale di questo parametro. Abbiamo due tipi di implementazione tra cui scegliere: utilizzare Groovy Script o Scriptler Script.
Scegliamo il primo, poiché Scriptler è solo un plugin che salva gli script già scritti da voi e permette di usarli in altri compiti senza doverli copiare e incollare di nuovo.
Codice Groovy per ottenere tutti i commit dal repository selezionato:
AUTH = "nome utente e password in Base64"
GIT_URL = "url per il vostro SCM (https://bitbucket.org/)"
PROJECT_NAME = "nome dell'area del progetto in cui si trovano i repository"
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()Senza entrare nei dettagli, questo codice prende come input il nome del microservizio (MICROSERVICE_NAME), invia una richiesta a Bitbucket (metodo getCommitsForMicroservice), utilizzando la sua API, e ottiene l'id e il commit message di tutti i commit per questo microservizio.
Come già detto in precedenza, questo codice deve restituire HTML, che sarà visualizzato sulla pagina Build with Parameters in Jenkins, quindi tutti i valori ottenuti da Bitbucket li avvolgiamo in un elenco e li aggiungiamo al select.
Dopo aver eseguito tutte le operazioni, dovremmo ottenere una bella pagina come questa. Build with Parameters.
Se è stato scelto il microservizio test1:
Se è stato scelto il microservizio test2:
Concordate che per l'utente sarà molto più comodo interagire con il vostro compito in questo modo, piuttosto che copiare ogni volta l'url e cercare il commit id necessario.
P.S. In questo articolo viene fornito un esempio molto semplificato, che potrebbe non avere applicazioni pratiche in questo modo, poiché le assemblaggi hanno molti più parametri diversi, ma l'obiettivo di questo articolo era mostrare il funzionamento dello strumento e non fornire una soluzione funzionante.
P.S.S. Come ho già scritto in precedenza, se questo articolo sarà utile, il prossimo tratterà di configurazione dinamica delle attività di Jenkins tramite codice.
Fonte: habr.com
