God dag, Habr!
I dag vil jeg gerne dele en af måderne, hvordan man med hjælp af kan gøre opgaven i Jenkins den mest ensartede og forståelige for brugeren.
Introduktion
Forkortelsen DevOps er ikke længere noget nyt for IT-miljøet. Mange mennesker forbinder sætningen "gøre DevOps" med en eller anden magisk knap, der ved at trykke på den automatisk forvandler applikationens kode til en udrullet og testet applikation (det hele er faktisk mere kompliceret, men vi abstraherer fra alle processerne).
Så vi har fået en opgave om at lave en sådan magisk knap, så administratorer kan udrulle applikationen med et enkelt klik. Der er forskellige måder at realisere denne opgave på: fra at skrive en bot til en eller anden messenger til at udvikle en separat applikation. Men målet for alle disse er det samme – at gøre lanceringen af bygger og udrulning af applikationen så gennemsigtig og brugervenlig som muligt.
I vores tilfælde vil vi bruge Jenkins.
Regler for godkendelse af merge-requests
Oprette et brugervenligt Jenkins-job, der vil starte byggeriet og (eller) udrulningen af den valgte mikrotjeneste i en bestemt version.
Inddata
Vi har flere repositories, hvor kildekoden til forskellige mikrotjenester ligger.
Definition af parametre
På input til vores job skal følgende parametre komme ind:
- URL til repository med koden til den mikrotjeneste, som vi ønsker at bygge og udrulle under udførelsen af jobbet.
- Commit-ID'et, som byggeriet vil blive udført ud fra.
AS IS
Den enkleste måde at løse opgaven på er at oprette to parametre af typen String.
I dette tilfælde skal brugeren manuelt indtaste stien til repository og commit-ID, hvilket, indrømmet, ikke er særligt praktisk.
AS TO BE
Lad os nu prøve en anden type parametre for at se alle dens fordele.
Lad os oprette den første parameter som en Choice Parameter, og den anden som en Active Choices Reactive Reference Parameter. I parameteren med typen Choice tilføjer vi manuelt repository-navne, hvor vores mikrotjenesters kode er gemt.
Hvis denne artikel bliver godt modtaget af publikum, vil jeg i næste artikel beskrive konfigurationsprocessen for opgaver i Jenkins ved hjælp af kodebeskrivelse (Configuration as code), dvs. vi behøver ikke manuelt at indtaste repository-navne og oprette parametre; alt vil ske automatisk (vores kode vil få en liste over repositories fra SCM og oprette en parameter med denne liste).
Værdierne for den anden parameter vil blive udfyldt dynamisk afhængigt af hvilken værdi den første parameter (test1 eller test2) får, da hver repository har sin egen liste over commits.
Active Choices Reactive Reference Parameter har følgende felter til udfyldning:
- Navn – parameterens navn.
- Script – koden, der vil blive udført hver gang værdien af parameteren fra feltet Referenced parameter ændres (i vores tilfælde når vi vælger mellem test1 og test2).
- Beskrivelse – en kort beskrivelse af parameteren.
- Choice Type – typen af objekt, der returneres af scriptet (i vores tilfælde vil vi returnere html-kode).
- Referenced parameter – navnet på parameteren, hvis værdiforandring vil trigge koden i sektionen Script.
Lad os gå videre til udfyldningen af det vigtigste felt i denne parameter. Vi har to muligheder for implementering: Groovy Script eller Scriptler Script.
Vi vælger den første, da Scriptler blot er et plugin, der gemmer de scripts, du tidligere har skrevet, og gør det muligt at bruge dem i andre opgaver uden at skulle kopiere og indsætte igen.
Groovy-koden til at hente alle commits fra det valgte repository:
AUTH = "login og password i Base64"
GIT_URL = "url til dit SCM (https://bitbucket.org/)"
PROJECT_NAME = "navnet på projektområdet, hvor repositorierne findes"
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()Uden at gå for meget i detaljer modtager denne kode navnet på mikrotjenesten (MICROSERVICE_NAME) og sender en forespørgsel til Bitbucket (metoden getCommitsForMicroservice), ved at bruge dens API, og modtager id og commit message for alle commits til denne mikrotjeneste.
Som tidligere nævnt skal denne kode returnere html, som vises på siden Build with Parameters i Jenkins, derfor indkapsler vi alle de modtagne værdier fra Bitbucket i en liste og tilføjer dem til select.
Efter at have udført alle handlinger bør vi få en sådan flot side. Build with Parameters.
Hvis du valgte mikrotjenesten test1:
Hvis du valgte mikrotjenesten test2:
Erkend, at det vil være meget mere bekvemt for brugeren at interagere med din opgave på denne måde end hver gang at kopiere url og finde den nødvendige commit id.
P.S. Denne artikel giver et stærkt forsimplet eksempel, som muligvis ikke har praktisk anvendelse i denne form, da konfigurationer har mange forskellige parametre. Formålet med denne artikel var at demonstrere værktøjets funktion og ikke at præsentere en fungerende løsning.
P.S.S. Som nævnt tidligere, hvis denne artikel er nyttig, vil den næste handle om dynamisk konfiguration af Jenkins-opgaver via kode.
Kilde: habr.com
