La integració contínua s’ha consolidat en el desenvolupament de programari com un model imprescindible en la construcció d’aplicacions.
I això és principalment a causa de la sèrie d’avantatges que ofereix respecte a mètodes més tradicionals, d’entre les que podríem destacar:
- més petit temps de construcció (i per tant posteriorment, de desplegaments)
- facilitat d’execució de proves unitàries
- Estalvi de costos
No obstant això, i malgrat les eines disponibles, fins i tot de programari lliure, per dur a terme la integració contínua, no és gratuït fer aquest pas, i molts menys mantenir-lo.
En aquest cas, el major cost no és directament l’econòmic, sinó el de l’especialització, que repercuteix sobre el temps necessari tant per a l’aprenentatge de l’domini de les diferents eines que s’han d’utilitzar, com el de l’experiència a l’hora de resoldre les incidèncie ies més habituals, o dedicar el necessari per al manteniment i actualitzacions que permetin disposar d’una infraestructura estable i segura.
Així que avui, fem un pas més enllà en el foment de la cultura devops, per parlar de aquest treball tan fonamental com és el de mantenir i configurar les eines necessàries per dur a terme la integració contínua.
eines necessàries
les eines són necessàries són bàsicament dos.
Principalment, un servidor d’automatització, que serà l’encarregat de realitzar les tasques necessàries per a la compilació de el projecte.
Però, a més, i com avui en dia no n’hi ha prou amb desenvolupar programari, sinó que cal desenvolupar-lo amb qualitat, i en la integració contínua també s’inclouen les proves unitàries, cada vegada és més important complementar-lo amb una eina d’anàlisi de codi, que ajudarà a assegurar que el producte es construeix complint amb els requisits establerts.
I n primer lloc, com a servidor per a la integració continua, parlarem de Jenkins, per la versatilitat que ofereix i la quantitat de plugins disponibles per obtenir una configuració d’acord a les nostres necessitats.
Mentre que la part d’inspecció de codi , prendrem SonarQube com a referència.
Jenkins, el majordom que construeix aplicacions
Ja hem parlat en diverses ocasions de Jenkins i òbviament de fonamental paper en la integració contínua.
Però el major aprofitament d’aquesta eina, s’obté principalment per 3 elements:
1) configuració de sistema (Configureu System)
En aquest apartat de la configuració, és on es ha de definir els aspectes bàsics de la seva instància com, per exemple, l’URL mitjançant la qual es podrà accedir a l’eina.
I també en aquest apartat serà on s’ha d’especificar les dades relatives a la instància de Sonarqube que tinguem disponible.
En la majoria de situacions, sobretot si les eines pertanyen a una organització empresarials, també és imprescindible que es configuri un testimoni, necessari per poder connectar amb la instància de SonarQube sense necessitat que sigui pública i per tant calgui posar en risc la seguretat.
2) Configuració global de les eines (global Tool Configuration)
d’altra banda, la resta de eines es configuraran en aquesta secció, i on s’ha de prestar especial atenció és en els apartats:
- SonarQube Scanner: Inclou tant la configuració per als escàners de projectes MSBuild, com per a la resta de projectes
- Maven: per fer ús de l’eina per a la gestió i construcció de projectes Java més utilitzada
- JDK: on s’ha d’especificar les diferents configuracions i instal·lacions de Java per als projectes que ho requereixin
- Docker: per a configurar i instal·lar en entorn neces ri per a la construcció i gestió de contenidors
3) Gestió de connectors (Manage Plugins)
Una de les característiques més destacables de Jenkins és la seva gran quantitat de plugins disponibles que permeten ampliar la seva versatilitat
No només és admirable el nombre de Jenkins connectors existents, sinó la facilitat per instal·lar-los.
Si bé és fàcil la seva selecció i instal·lació, sempre serà necessari conèixer el plugin, per poder validar la seva compatibilitat, tant amb la instància de Jenkins, com amb els projectes que s’integrin en ella.
a més, per poder configurar les eines de la secció anteriorment presentada, és necessari en molts casos instal·lar el seu respectius connectors: com, per exemple, el Maven connector o el SonarQube connector.
SonarQube, l’inspector de codi
Com dèiem abans, la integració contínua, no es limita només a compilar, en ella s’inclouen també les proves unitàries, de manera que una eina de inspecció de codi es converteix en el complement ideal.
i quan parlem de SonarQube, no hem de fer referència simplement a la seva instància i la seva sonar scanner.
També és recomanable comptar amb sonarlint a els respectius IDE ‘s de desenvolupament de l’equip, amb el que podrem evitar un bon nombre d’evidències arribin a el repositori, per tant, a la seva construcció en Jenkins.
Tot això, tenint sempre en ment l’objectiu de comptar amb un codi net i segur.
En aquest cas, la configuració necessària per a la correcta sincronització Jenkins Sonar, passa per les següents seccions:
1) configuració general
On s’han d’establir els paràmetres de la instància de SonarQube, necessaris com explicàvem anteriorment per estable -ho en la instància de Jenkins
A més, en aquest apartat és on s’especifiquen els diferents valors necessaris per a la correcta anàlisi de codi d’un projecte en funció de l’llenguatge que s’utilitzi.
Per altra banda, SonarQube compta amb un arxiu anomenat sonar properties, en el qual es poden establir aquests valors.
2) Marketplace
en aquest cas, també SonarQube compta amb una àmplia varietat de connectors que permeten ampliar les seves funcionalitats i, com en el cas anterior, encara que la seva instal·lació és senzilla, cal assegurar la compatibilitat i escollir els adequats per obtenir els millors resultats i mantenir una instància estable i segura.
a
a
Contacta’ns i et guiarem cap a la millor implementació.
a