En el cas que l’aplicació utilitzi el servei de custòdia de codi i la seva tecnologia permeti la construcció i desplegament automatitzat d’artefactes, s’hauran d’acomplir una sèrie de requeriments per a que es pugui dur a terme la construcció de les corresponents pipelines de desplegament.
Es tracta d’una guia ràpida per a informar dels aspectes més rellevants a tenir en compte quan una aplicació es vol integrar amb el SIC.
Cal que es pugi el codi font de l’aplicació al sistema de gestió de codi font (SCM - Source Code Management) del SIC:
Els projectes han de crear-se dins el codi de diàleg adient, de forma que tota la gestió posterior de jobs i creació de peticions Remedy s’associïn a l’aplicació corresponent. Per aquest mateix motiu, no està contemplat la creació de subgrups de projectes, tot i que l’eina ho permeti.
Aquest repositori no és un entorn de desenvolupament, per la qual cosa només les persones assignades com a Release Managers seran les encarregades de consolidar el codi i lliurar-lo. Aquest codi font ja haurà d’estar validat en entorns de desenvolupament i es lliurarà quan es decideixi distribuir als entorns dels serveis TIC centrals.
Els repositoris poden tenir tantes branques com siguin necessàries, però sempre s’haurà d’incloure la branca MASTER i el contingut d’aquesta branca serà amb el que treballaran les pipelines de construcció i desplegament per defecte. No obstant això, el sistema permetrà opcionalment desplegar el codi font associat a la branca EVOLUTIUS.
Les pipelines seran les encarregades de generar els TAGS corresponents: tag de Build, tag de Release i tag per entorn.
A continuació es detallen les restriccions aplicades a l’hora de fer el lliurament de codi:
No es poden incloure binaris de llibreries ni d’altres mòduls ni executables (JAR, WAR, EAR, DLL, EXE…) i la mida màxima dels arxius serà de 25MB. A tal efecte, s’ha habilitat un sistema de gestió de Binaris.
No es permet l’ús de versions snapshot, per lo que s’impedirà la pujada del fitxer pom.xml
si aquest les referencia.
No es permet incloure fitxers de configuració de les eines de construcció: settings.xml
(Maven), .npmrc
(Npm) o
nuget.config
(.NET Framework). Aquestes configuracions seran injectades per SIC amb tota la configuració necessària.
L’estructura de projectes i el seu contingut ha de ser compatible amb el sistema establert d’Integració Contínua:
Dins del grup del codi de diàleg, es tindran tant projectes com a conjunts de codi font susceptibles de ser versionats de forma independent a la resta de projectes. Pot tractar-se d’una llibreria, un microservei, un mòdul, un conjunt d’scripts o un programa sense fragments independents.
Cal proporcionar procesos de construcció d’artefactes independents de les màquines i plataformes on s’executen, de forma que siguin aplicables tant en els entorns de desenvolupament com en els entorns del SIC.
Els artefactes es construiran una sola vegada i seran els que es desplegaran als diferents entorns. No es contempla, per tant, condicionar la construcció d’artefactes a l’entorn on es desplegaran (ús profiles maven o similar).
Si el projecte és multimòdul maven, és necessari que el fitxer pom.xml
pare i els submòduls estiguin correctament configurats per a poder fer la construcció a partir d’un goal
en el fitxer pom.xml
pare i no un goal per cada submòdul.
Per tal d’automatitzar la creació de pipelines, tots els projectes hauran de disposar de la carpeta /sic
al primer nivell de carpeta i, dins d’aquesta
carpeta, caldrà crear l’arxiu de configuració aca.yml
que proporcionarà la configuració necessària.
Veure Com construir el fitxer ACA.
Si es tracta d’un component a desplegar en una plataforma de contenidors mitjançant una imatge pròpia que caldrà construir, és necessari preparar el corresponent fitxer Dockerfile, així com els corresponents descriptors (orchestrators). Aquests components seran referenciats des del fitxer ACA indicat al punt anterior.
Si es contempla l’execució de scripts de desplegament/migració de BBDD on-premise, cal preparar el fitxer de plans
i els corresponents scripts a una carpeta independent.
Veure [Aplicacions APEX i PL/SQL, i migracions de BBDD on-premise](/sic30-guies/preparar-aplicacio/#Aplicacions APEX i PL/SQL, i migracions de BBDD on-premise).
Si es contempla l’execució de scripts de desplegament/migració de BBDD en plataforma de contenidors, cal preparar els corresponents scripts a una carpeta per versió. Aquesta versió es correspondrà amb la versió del component indicat al fitxer ACA indicat anteriorment. Veure [Migracions de BBDD en contenidors](/sic30-guies/preparar-aplicacio/#Migracions de BBDD en contenidors).
Respecte a les llibreries requerides pels projectes, en funció del seu tipus, cal tenir en compte les següents premisses:
Es pot validar la existència o no de la llibreria pública accedint al Repositori de llibreries. En el cas de llibreries no públiques o pròpies publicades a repositoris privats, caldrà validar la resolució de les dependències del projecte dins l’entorn SIC.
El desplegament d’aplicacions de certes tecnologies es fonamenta en l’execució de scripts a base de dades, tot i que els criteris apliquen a qualsevol migració de base de dades. En general s’aconsella disposar d’un projecte específic de desplegament/migració de BBDD, tot i que també es pot optar per integrar-lo al desplegament d’un altre artefacte, habitualment el backend de l’aplicació.
sql_scripts
, o a un nivell de carpeta superior, i caldrà indicar:Paràmetre | Tipus | Descripció |
---|---|---|
entorn | Opcional | Entorn per al qual s’ha d’executar o empaquetar (segons la modalitat de desplegament) el fitxer. Per defecte, aplica a tots els entorns. |
failure | Obligatori | Indica la forma en la que s’ha de comportar el sistema en cas d’error: parar o continuar. |
idBBDD | Obligatori | Identificador únic de la connexió amb la bbdd. En cas de pipelines generades per l’autoservei i desplegament automàtic, s’haurà de correspondre amb l’identificador del fitxer d’infraestructures que determina la cadena de connexió podent referenciar-ne diferents. |
file | Obligatori | Fitxer que cal executar o empaquetar (segons la modalitat de desplegament). |
execute | Opcional | Indica, en cas de modalitat de desplegament automàtic o delegat, si a més d’empaquetar el fitxer aquest s’ha d’executar. Útil pel cas de scripts anidats. Per defecte, s’executarà. |
Exemple:
<llista-scripts>
<script entorn="INT" failure="stop" idBBDD="BD_INT" file="script_INT.sql"/>
<script entorn="INT" failure="continue" idBBDD="BD_INT" file="script_INT1.sql" execute="false"/>
<script entorn="INT" failure="continue" idBBDD="BD_INT" file="script_INT2.sql" execute="false"/>
<script entorn="PRE" failure="continue" idBBDD="BD_PRE" file="script_PRE.sql"/>
<script entorn="PRE" failure="continue" idBBDD="BD_PRE" file="script_PRE1.sql" execute="false"/>
<script entorn="PRE" failure="continue" idBBDD="BD_PRE" file="script_PRE2.sql" execute="false"/>
<script entorn="PRO" failure="continue" idBBDD="BD_PRO" file="script_PRO.sql"/>
<script entorn="PRO" failure="continue" idBBDD="BD_PRO" file="script_PRO1.sql" execute="false"/>
<script entorn="PRO" failure="continue" idBBDD="BD_PRO" file="script_PRO2.sql" execute="false"/>
</llista-scripts>
Cal disposar d’un projecte específic de desplegament/migració de BBDD i preparar el directori “scripts” (al primer nivell de carpeta) amb un subdirectori amb la versió associada a cada desplegament. Aquesta versió es correspondrà amb la versió del component indicat al fitxer ACA de configuració, de forma que s’executaran els scripts associats a la versió que es desplega en cada moment en ordre alfabètic.
En realitzar una pujada de codi font, caldrà executar la corresponent pipeline de desplegament associada:
Per a poder efectuar certes tasques caldrà accedir a la plataforma mitjançat el formulari d’autenticació de Jenkins.
Per a més informació: Integració Continua.
Si voleu més informació podeu consultar la secció de Guies.
Si teniu qualsevol dubte o problema podeu revisar les Preguntes Freqüents o utilitzar els canals de Suport.