Buona giornata, Habr!
Oggi vorrei condividere uno dei modi in cui, utilizzando possiamo svolgere il compito in Jenkins modo più uniforme e comprensibile per l'utente.
Introduzione
L'abbreviazione DevOps non è più qualcosa di nuovo per la comunità IT. Molte persone associano la frase "fare DevOps" a un bottone magico, premendo il quale il codice dell'applicazione si trasforma automaticamente in un'applicazione distribuita e testata (in realtà è tutto molto più complicato, ma ci asteniamo da tutti i processi).
Quindi, abbiamo ricevuto una richiesta di creare questo bottone magico affinché gli amministratori possano distribuire l'applicazione con un solo clic. Ci sono vari modi per implementare questo compito: si va dalla scrittura di un bot per uno dei messaggeri fino allo sviluppo di un'applicazione separata. Tuttavia, l'obiettivo di tutto ciò è uno: rendere il lancio della build e della distribuzione dell'applicazione il più trasparente e comodo possibile.
Nel nostro caso utilizzeremo Jenkins.
Compito
creare un job Jenkins user-friendly che avvii la build e (o) il deployment del microservizio scelto di una certa versione.
Dati di input
Abbiamo a disposizione diversi repository contenenti il codice sorgente di vari microservizi.
Definizione dei parametri
All'input del nostro job devono essere forniti i seguenti parametri:
- URL del repository contenente il codice del microservizio che desideriamo costruire e distribuire all'avvio del job.
- ID del commit da cui avverrà la costruzione.
AS IS
Il modo più semplice per realizzare il 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 tutti i suoi vantaggi.
Creiamo il primo parametro di tipo Choice Parameter e il secondo di tipo Active Choices Reactive Reference Parameter. Nel parametro di tipo Choice, aggiungiamo manualmente i nomi dei repository, dove è conservato il codice dei nostri microservizi, nel campo Choices.
Se questo articolo piacerà al pubblico, nel prossimo articolo descriverò il processo di configurazione delle attività in Jenkins, utilizzando la descrizione tramite codice (Configuration as code), ovvero non sarà necessario 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 di quale valore assumerà il primo parametro (test1 o test2), poiché 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 verrà modificato (nel nostro caso, quando selezioneremo tra test1 e test2).
- Descrizione – breve descrizione del parametro.
- Choice Type – tipo di oggetto restituito dallo script (in questo caso restituiremo codice html).
- Referenced parameter – nome del parametro, al cui cambiamento di valore verrà eseguito il codice della sezione Script.
Passiamo direttamente alla compilazione del campo principale in questo parametro. Sono disponibili due tipi di implementazione: utilizzo Groovy Script o Scriptler Script.
Scegliamo il primo, poiché Scriptler è solo un plugin che salva gli script che hai già scritto e permette di utilizzarli in altri compiti senza dover copiare e incollare di nuovo.
Codice Groovy per ottenere tutti i commit dal repository selezionato:
AUTH = "login e password in Base64"
GIT_URL = "url del tuo SCM (https://bitbucket.org/)"
PROJECT_NAME = "nome dell'area di progetto dove 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()Se non entriamo nei dettagli, questo codice riceve 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 messaggio di commit di tutti i commit per questo microservizio.
Come già detto in precedenza, questo codice deve restituire html che verrà visualizzato nella pagina Build with Parameters in Jenkins, quindi tutti i valori ottenuti da Bitbucket devono essere racchiusi in un elenco e aggiunti a un select.
Dopo aver eseguito tutte le operazioni, dovremmo ottenere una bella pagina Build with Parameters.
Se hai scelto il microservizio test1:
Se hai scelto il microservizio test2:
Concorda che sarebbe molto più comodo per l'utente interagire con il tuo compito in questo modo piuttosto che copiare ogni volta l'URL e cercare il commit ID corretto.
P.S. In questo articolo è fornito un esempio molto semplificato che potrebbe non avere applicazioni pratiche in questo formato, poiché le build hanno molte più variabili diverse, ma l'obiettivo di questo articolo era mostrare il funzionamento dello strumento, e non fornire una soluzione operativa.
P.S.S. Come già scritto in precedenza, se questo articolo risulterà utile, il prossimo sarà su configurazione dinamica dei task di Jenkins tramite codice.
Fonte: habr.com
