Integració contínua

Introducció

Jenkins és l’eina implantada al SIC per a la integració contínua en el desenvolupament de software. Es tracta d’un servei en el que, a partir de la definició previa de tasques (jobs), es construeixen les aplicacions, es versionen, es realitzen anàlisis de qualitat, s’executen tests i inclús es despleguen als entorns preproductius i productius. Està basat en el projecte Hudson.
Jenkins proporciona un entorn de treball i desplegament automatitzat estalviant temps i diners durant la vida d’un projecte.

JFrog Artifactory és l’eina implantada al SIC com a administrador central de biblioteques que facilita la col·laboració eficient entre els diferents col·laboradors i equips implicats. Permet crear servidors proxy, recopilar i administrar les dependències externes, ja siguin de tercers o pròpies. És compatible amb llibreries de diferents tecnologies: llibreries Java, paquets NuGet, paquets NPM i docker. Més informació en el següent enllaç Repositori d’artefactes

Beneficis de la integració continua

Un resum dels beneficis de la integració continua seria el següent:

• Millora la qualitat del codi: la integració continua contribueix en minimitzar els problemes en els sistemes per errors de codi. Proveeix un codi més robust millorant la qualitat del programari.
• Detecció d’errors més ràpida i fàcil: al poder realitzar construccions contínuament, de forma periòdica, és més fàcil detectar errors i poder donar-hi solució el més aviat possible.
• Redueix tasques repetitives i manuals: amb processos automàtics es garanteix que els processos es realitzen sempre aplicant els mateixos estàndards.
• Visibilitat de l’evolució del projecte: es pot tenir una visió de l’evolució de la qualitat del codi i un registre de l’evolució i publicació de les versions del codi.
• Millora de la confiança del treball realitzat: al garantir una qualitat del codi i poder realitzar entregues de forma més periòdica, els responsables poden tenir major confiança del treball realitzat i entregat.

Modalitats de desplegament

Es contemplen diverses modalitats de desplegament:

Modalitat automàtica al cloud

Es construeixen els artefactes i es despleguen al cloud. Aquesta modalitat s’aplica a desplegaments al cloud als diferents entorns. En el cas dels entorns preproductius i productius, es requerirà conformitat prèvia on es sol·licitarà informació per a generar automàticament un tiquet Remedy CRQ.

En la informació sol·licitada per a l’obertura de CRQ, entre altres paràmetres, se sol·licitarà inici i fi de la finestra de desplegament. La pipeline, una vegada aprovat el desplegament, es quedarà en espera fins a l’arribada de l’inici de la finestra de desplegament, moment en el qual es reprendrà de manera automàtica, no serà precisa cap mena d’intervenció manual per part dels desenvolupadors. Si l’inici i fi de la finestra de desplegament es deixa en blanc, s’assumeix que el desplegament és immediat i continuarà automàticament una vegada rebi l’aprovació des de Remedy.

La sortida de logs per consola indicarà si el desplegament ha acabat bé o s’han produït incidències, proporcionant tota la informació necessària per a identificar-ne el problema. Tota la informació de desplegament serà configurada per l’equip de SIC en col·laboració amb el proveïdor d’infraestructures (Suport Cloud/CPD) sense que sigui requerida cap acció específica per part del proveïdor d’aplicacions.

Modalitat delegada

Es construeixen els artefactes, es lliuren a través del servei de gestió de binaris i es delega als CPD el desplegament automàtic als servidors web, servidors d’aplicacions i servidors de bases de dades dels artefactes mitjançant un sistema de llibreries compartides. Aquesta modalitat és l’evolució de l’antiga modalitat automàtica aportant les següents millores:

• Abans del desplegament, es fa una còpia de l’artefacte desplegat (backup)
• Un cop finalitzat el desplegament, és duu a terme un reinici de totes les instàncies afectades, amb esborrat de caché i temporals (segons pertoqui)
• Es comprova si l’aplicació queda en estat activa per a identificar possibles problemes al desplegament
• En cas d’error, es realitza marxa enrere automàtica

Aquesta modalitat s’aplica a desplegaments on-premise als entorns d’integració o preproductius, si i només si, el proveïdor d’infraestructures (CPD) dona cobertura a les tecnologies requerides. En el cas dels entorns preproductius, es requerirà conformitat prèvia on es sol·licitarà informació per a generar automàticament un tiquet Remedy CRQ.

En la informació sol·licitada per a l’obertura de CRQ, entre altres paràmetres, se sol·licitarà inici i fi de la finestra de desplegament. La pipeline, una vegada aprovat el desplegament, es quedarà en espera fins a l’arribada de l’inici de la finestra de desplegament, moment en el qual es reprendrà de manera automàtica, no serà precisa cap mena d’intervenció manual per part dels desenvolupadors. Si l’inici i fi de la finestra de desplegament es deixa en blanc, s’assumeix que el desplegament és immediat i continuarà automàticament una vegada rebi l’aprovació des de Remedy.

La sortida de logs per consola indicarà si el desplegament ha acabat bé o s’han produït incidències, proporcionant tota la informació necessària per a identificar-ne el problema i un codi d’error que indicarà qui és el responsable de revisar la incidència:

En aquest cas, el proveïdor d’aplicacions ha de fer la sol·licitud d’integració al proveïdor d’infraestructures (Cpd) remetent tota la informació que sigui requerida per a habilitar aquesta modalitat de desplegament sobre les seves infraestructures. Un cop finalitzat aquest tràmit, ja podrà fer ús d’aquesta modalitat per a dur a terme les corresponents validacions.

Modalitat semiautomàtica

Es construeixen els artefactes, es lliuren a través del servei de gestió de binaris i es genera un tiquet Remedy en mode “Draft” (que cal acabar d’emplenar segons l’operativa establerta per gestio de canvis) per a que CPD/LdT dugui a terme el procés de desplegament. Aquesta modalitat requerirà conformitat prèvia i les accions prèvies davant una possible marxa enrere aniran a càrrec de CPD/LdT. Aquesta modalitat s’aplica a desplegaments on-premise als entorns preproductius i productius, tot i que està previst que, a futur, acabi sent substituïda per la modalitat delegada.

La sortida de logs per consola indicarà si el procés ha acabat bé o s’han produït incidències, proporcionant tota la informació necessària per a identificar-ne el problema.

Integració amb la gestió de canvis

S’ha evolucionat la integració amb el sistema de gestió de canvis i la seva eina principal, Remedy, de tal forma que, cada desplegament, portarà associada una CRQ en Remedy que controlarà l’aprovació del desplegament. El desplegament no s’efectuarà si aquesta aprovació no es realitza dins del termini i en la forma escaient. Aquesta nova funcionalitat no aplica als desplegaments de modalitat Semiautomàtica, que continuaran generant el tiquet CRQ en mode Draft per a ser completat i evolucionat pels desenvolupadors des de la interfície de Remedy.

Aplicacions amb aprovació automàtica

L’aprovació de les CRQs que controlen els desplegaments es realitzarà de manera automatitzada des de fluxos de Remedy. En cas que l’aplicació compti amb aprovacions automàtiques, no serà necessària cap mena d’intervenció manual des del costat de Remedy, la pipeline rebrà aquesta aprovació i continuarà la seva execució. En entorns no productius l’aprovació serà sempre automàtica. Per als entorns productius l’aprovació també serà automàtica per defecte tret que s’acordi el contrari i es modifiqui per part de Preparar el Servei.

Aplicacions amb aprovació manual

Per a determinades aplicacions, els desplegaments en producció tindran un doble control: d’una banda, des del lot d’aplicacions es llançarà el desplegament i s’informarà de la finestra en la qual s’ha d’executar aquest desplegament; d’altra banda, els responsables de les aplicacions hauran d’aprovar la CRQ en Remedy quan aquesta es creï per a autoritzar el desplegament en la finestra que s’indicarà en la mateixa CRQ. Una vegada que la pipeline compta amb totes les aprovacions, el desplegament s’iniciarà en la data i hora que s’informi en el desplegament.

Qualsevol modificació en la modalitat d’aprovació de CRQs que tingui l’aplicació, ha de tramitar-se amb l’equip de Preparar el Servei mitjançant els seus canals habituals.

Independentment que l’aplicació disposi d’aprovació automàtica de la CRQ o sigui manual, si resulta aprovada el desplegament s’executarà automàticament en la data i hora de l’inici de la finestra de desplegament, no es precisarà cap mena d’intervenció addicional.

Informació del desplegament en SIC 3.0

En SIC 3.0, quan es llança un desplegament mitjançant l’execució de la pipeline, se succeeixen les fases habituals de compilació i anàlisi de qualitat. Quan arriba al moment de desplegar, la pipeline es deté i sol·licita al Release Manager del proveïdor la informació necessària per al registre de la CRQ relacionada amb el desplegament i l’entorn en el qual estem desplegant:

Per a continuar, en el formulari s’hauran d’informar les següents propietats del canvi:

• Impact: Impacte del canvi
• Urgency: Urgència del canvi
• Service: Servei afectat pel canvi
• Data d’inici: Data d’inici del desplegament en format dd-MM-YYYY HH:mm Deixar en blanc si es desitja desplegament immediat. S’informarà de la data i hora en què es desitja que es realitzi el desplegament. La finestra de desplegament no podrà ser més enllà dels 30 dies següents a la data actual. La pipeline es detindrà en espera d’aquesta data i es reprendrà automàticament quan arribi. Si es desitja que el desplegament s’executi immediatament, es pot deixar aquest valor en blanc.
• Data de fi: Data de fi del desplegament en format dd-MM-YYYY. Deixar en blanc si es desitja desplegament immediat. S’informarà de la data i hora en què es preveu finalitzarà el desplegament. Si es desitja que el desplegament s’executi immediatament, es pot deixar aquest valor en blanc.
• Affectation: Text lliure amb la descripció del canvi i a què afecta aquest canvi
• Operational Categorization: Categoria operacional o tipus de desplegament

La pipeline traslladarà els valors aquí informats a les seves corresponents propietats de CRQ de Remedy. L’usuari que punxi a continuar serà l’utilitzat per a informar el “Change Coordinator” a nivell de Remedy i haurà de comptar amb els permisos adequats per a poder obrir CRQs en aquest servei, en cas contrari, l’obertura de CRQ fallarà i la pipeline avortarà en aquest punt.

Si arribant l’hora assenyalada per al desplegament no s’hagués rebut aprovació, la CRQ es rebutjarà automàticament i s’avortarà la pipeline.

MOLT IMPORTANT: una vegada rebuda l’aprovació del canvi des de Remedy, la pipeline se suspendrà i quedarà en espera fins a la data i hora que s’hagi informat com a data d’inici. Quan arribi a aquesta data i hora, la pipeline es reprendrà automàticament i el desplegament es realitzarà.

Informació del desplegament en SIC +

En SIC+, quan es llança un desplegament mitjançant l’execució de la pipeline, se succeeixen les fases habituals de compilació i anàlisi de qualitat. Quan arriba al moment de desplegar, la pipeline es deté i sol·licita al Release Manager del proveïdor la informació necessària per al registre de la CRQ relacionada amb el desplegament i l’entorn en el qual estem desplegant:

Per a continuar, en el formulari s’hauran d’informar les següents propietats del canvi:

• Artifact version: Versió de l’artefacte a desplegar
• Environment: Entorn en el qual s’executarà el workflow
• ITSM Change Coordinator: Usuari GICAR (DNI) del Release Manager que sol·licitarà el canvi. Haurà de comptar amb permisos en Remedy per a obrir canvis al servei indicat.
• Deployment start date: Data d’inici del desplegament en format dd-MM-YYYY HH:mm Deixar en blanc si es desitja desplegament immediat. S’informarà de la data i hora en què es desitja que es realitzi el desplegament. La finestra de desplegament no podrà ser més enllà dels 30 dies següents a la data actual. La pipeline es detindrà en espera d’aquesta data i es reprendrà automàticament quan arribi. Si es desitja que el desplegament s’executi immediatament, es pot deixar aquest valor en blanc.
• Deployment end date: Data de fi del desplegament en format dd-MM-YYYY. Deixar en blanc si es desitja desplegament immediat. S’informarà de la data i hora en què es preveu finalitzarà el desplegament. Si es desitja que el desplegament s’executi immediatament, es pot deixar aquest valor en blanc.

Si arribant l’hora assenyalada per al desplegament no s’hagués rebut aprovació, la CRQ es rebutjarà automàticament i s’avortarà la pipeline.

MOLT IMPORTANT: una vegada rebuda l’aprovació del canvi des de Remedy, la pipeline se suspendrà i quedarà en espera fins a la data i hora que s’hagi informat com a data d’inici. Quan arribi a aquesta data i hora, la pipeline es reprendrà automàticament i el desplegament es realitzarà.

Funcionament

Accés als serveis

Podrà accedir a Jenkins mitjançant el següent enllaç: https://cicd.sic.intranet.gencat.cat
Per a poder accedir via VPN cal assegurar que es disposa de connectivitat pel port 443/TCP i, en cas de no disposar de connectivitat, caldrà obrir una petició demanant l’obertura de Tallafocs dels seus entorns.

Haurà d’autenticar-se amb de les seves credencials d’accés GICAR. Els Release Manager, responsables de lot i tècnics de CPD disposaran d’accés al servei. Si no disposa d’accés, haurà de sol·licitar-ho al seu responsable.

Podrà accedir a JFrog Artifactory mitjançant el següent enllaç: https://jfrog.com/artifactory/

Relació de tasques i detalls de les execucions

Una vegada fet el login s’accedeix a la llista de jobs en execució i la relació de jobs disponibles per l’usuari amb la informació més rellevant: nom, estat del darrer muntatge (Status) i el nivell de salut general del projecte (Weather) basat en l’estabilitat, cobertura i tests realitzats. Aquest nivell de salut es pot definir per a cada projecte i es basa en el número de construccions que han anat bé o malament, així com en el percentatge de proves i indicadors d’anàlisi.

De cadascuna de les tasques, es pot consultar la configuració, historial, estadístiques, resultats i situació mitjançant l’enllaç habilitat. A més, es mostrarà una gràfica amb les darreres execucions i el resultat de cadascuna de les seves etapes. Per tal de disposar de la informació detallada de passes realitzades i logs generats haurà de dirigir-se a l’opció “Console Output”. Al final d’aquest log es mostrarà el resultat general de l’execució: SUCCES, FAILED o ABORTED, que serà notificat per correu electrònic als responsables assignats.

Execució de tasques

Les tasques s’executaran a demanda quan l’usuari iniciï el desplegament mitjançant l’opció BuildWithParameters.

Etapes de desplegament

Els jobs multi-etapa realitzen multitud d’accions organitzades en STAGES. En cas de produir-se incidències a qualsevol de les seves etapes el job es cancel·larà i es notificarà per correu electrònic.

A continuació s’explica breument cadascuna de les etapes previstes per al desplegament de components i aplicacions:

• Init: inicialitzacions internes.

• Checkout: descàrrega del codi font del projecte a l’espai de treball.

• Setup JFrog Artifactory: Obté el token d’accés a Artifactory i realitza la configuració per a ser utilitzada en la resta de la pipeline..

• Prepare Builder: construcció de la possible imatge Docker pròpia de Build que serà utilitzada, en la següent etapa, per a la compilació i construcció d’artefactes.

• Build: compilació i construcció d’artefactes en funció de la tecnologia i les eines emprades.

• MultiStepBuild: compilació i construcció d’artefactes que usen múltiples tecnologies.

• Build Tag: generació del tag de Build al repositori de codi. Aquest tag marca que es tracta d’una versió construïble. Per exemple: 1.0.0-B001.

• Static Code Analysis: enviament del codi font del projecte a l’eina d’anàlisi estàtic de codi de l’Oficina de Qualitat i comprovació de les corresponents Quality Gates.

• Security Test: etapa prevista per a l’execució de tests de seguretat.

• Unit Test: etapa prevista per a l’execució de tests unitaris.

• Release Tag: generació del tag de Release Candidate al repositori de codi. Aquest tag marca que es tracta d’una versió desplegable. Per exemple: 1.0.0.

• Artifact Archive: etapa prevista per a l’arxivament dels artefactes generats.

• Artifact permissions & Vulnerability Scan: Realitza una anàlisi Xray sobre l’artefacte generat i bolca el resultat en el log de la pipeline. Addicionalment pot ser consultat en la web de Artifactory.

• Bake Validations: per als desplegaments al cloud, validació prèvia de la imatge Docker de l’aplicació (DockerFile).

• Image Bake: per als desplegaments al cloud, construcció de la imatge Docker de l’aplicació (DockerFile).

• Image Validations: Realitza una anàlisi Xray sobre l’artefacte generat i bolca el resultat en el log de la pipeline. Addicionalment pot ser consultat en la web de Artifactory.

• Per a entorns no productius (Integració):

  • Deploy Confirmation: si el desplegament a l’entorn no productiu requereix conformitat prèvia, l’usuari haurà d’aprovar manualment l’inici del desplegament a l’entorn un cop verificades les etapes anteriors.
  • Prev-Deploy: execució de possibles tasques prèvies al desplegament de l’aplicació a l’entorn no productiu.
  • Deploy: desplegament de l’aplicació segons la modalitat de desplegament aplicable a l’entorn no productiu.
  • Post-Deploy: execució de possibles tasques posteriors al desplegament de l’aplicació a l’entorn no productiu.
  • Smoke Test: etapa prevista per a la verificació ràpida a l’entorn no productiu per tal d’assegurar que l’aplicació funciona correctament i no té defectes evidents.
  • Environment Tag: generació del tag d’entorn al repositori de codi. Tag que marca que es tracta d’una versió desplegada a l’entorn corresponent. Per exemple: 1.0.0-integration.

• Per a l’entorn de Staging (Preproducció):

  • Deploy Confirmation: si el desplegament a l’entorn de Preproducció requereix conformitat prèvia o bé és necessari introduir informació per a la generació del tiquet Remedy CRQ, l’usuari haurà d’aprovar manualment l’inici del desplegament a l’entorn un cop verificades les etapes anteriors.
  • ITSM Register: generació automàtica d’un tiquet Remedy CRQ per a la traçabilitat dels desplegaments automàtics a l’entorn de Preproducció.
  • Wait for approval: L’execució es deté fins a rebre aprovació des de Remedy.
  • Wait until deployment date: L’execució es deté fins a l’inici de la finestra de desplegament.
  • Prev-Deploy: execució de possibles tasques prèvies al desplegament de l’aplicació a l’entorn de Preproducció.
  • Deploy: desplegament de l’aplicació segons la modalitat de desplegament aplicable a l’entorn de Preproducció.
  • Post-Deploy: execució de possibles tasques posteriors al desplegament de l’aplicació a l’entorn de Preproducció.
  • Smoke Test: etapa prevista per a la verificació ràpida a l’entorn de Preproducció per tal d’assegurar que l’aplicació funciona correctament i no té defectes evidents.
  • Stress Test: etapa prevista per a les proves de resistència a l’entorn de Preproducció per tal de verificar l’estabilitat i fiabilitat de l’aplicació.
  • Acceptance Test: etapa prevista per a les proves d’acceptació a l’entorn de Preproducció per tal de verificar que el sistema compleix les especificacions de negoci i és acceptable per al lliurament.
  • Exploratory Test: etapa prevista per a les proves exploratòries a l’entorn de Preproducció per tal de verificar els resultats obtinguts pels diferents casos de prova que es defineixin.
  • Environment Tag: generació del tag d’entorn al repositori de codi segons es tracta d’una versió desplegada a l’entorn corresponent. Per exemple: 1.0.0-preproduction.
  • ITSM Close: tancament automàtic del tiquet Remedy CRQ generat per a la traçabilitat dels desplegaments automàtics a l’entorn de Preproducció.

• Per a l’entorn de Production (Producció):

  • Deploy Confirmation: si el desplegament a l’entorn de Producció requereix conformitat prèvia o bé és necessari introduir informació per a la generació del tiquet Remedy CRQ, l’usuari haurà d’aprovar manualment l’inici del desplegament a l’entorn un cop verificades les etapes anteriors.
  • ITSM Register: generació automàtica d’un tiquet Remedy CRQ per a la traçabilitat dels desplegaments automàtics a l’entorn de Producció.
  • Wait for approval: L’execució es deté fins a rebre aprovació des de Remedy.
  • Wait until deployment date: L’execució es deté fins a l’inici de la finestra de desplegament.
  • Prev-Deploy: execució de possibles tasques prèvies al desplegament de l’aplicació a l’entorn de Producció.
  • Deploy: desplegament de l’aplicació segons la modalitat de desplegament aplicable a l’entorn de Producció.
  • Post-Deploy: execució de possibles tasques posteriors al desplegament de l’aplicació a l’entorn de Producció.
  • Smoke Test: etapa prevista per a la verificació ràpida a l’entorn de Producció per tal d’assegurar que l’aplicació funciona correctament i no té defectes evidents.
  • Probe Test: etapa prevista per a la verificació de sondes a l’entorn de Producció per tal d’assegurar que l’aplicació funciona correctament.
  • Environment Tag: generació del tag d’entorn al repositori de codi. Tag que marca que es tracta d’una versió desplegada a l’entorn corresponent. Per exemple: 1.0.0-production.
  • Registry Label: generació d’etiqueta “production” a la imatge del registre corporatiu d’imaatges. Etiqueta que marca que es tracta d’una versió desplegada amb èxit a producció.
  • ITSM Close: tancament automàtic del tiquet Remedy CRQ generat per a la traçabilitat dels desplegaments automàtics a l’entorn de Producció.

Versionat

La versió dels projectes ha de ser sempre incremental, és a dir, qualsevol nova actualització de codi lliurat al SIC ha d’anar acompanyat d’un increment de la versió. Per tant, no es permetrà que el projecte desplegui una versió igual o inferior a una versió prèviament desplegada. En cas contrari, es podria induir a error o confusió en els futurs desplegaments de preproducció i producció. Per exemple, no se sabria quina versió d’integració està desplegada a l’entorn de preproducció.

Artefactes generats i gestió de possibles marxes enrere

Com a resultat de la construcció es generarà un conjunt d’artefactes, bàsicament components estàtics i dinàmics. Els artefactes no queden emmagatzemats a l’espai de treball pel que la marxa enrere passaria per recuperar la versió anterior del codi del projecte per a que es tornin a construir i desplegar els artefactes anteriors. Pel que fa als entorns de preproducció i producció, la marxa enrere es delegarà als procediments de desplegament realitzats per CPD.

Anàlisi Xray d’artefactes

Cada vegada que es crea una nova llibreria o una nova imatge Docker, en carregar-la en Artifactory s’executarà automàticament una anàlisi de vulnerabilitats de l’artefacte. El resultat de l’anàlisi es bolcarà en el log de la pipeline i es podrà consultar també en la web de JFrog Artifactory.

També s’integra amb els principals IDE del mercat per a poder revisar les vulnerabilitats de les dependències en temps de codificació. En aquest enllaç disposen d’una guia per a integrar-lo amb Visual Studio Code i enllaç a la documentació oficial JFrog per a la resta de IDEs més utilitzats.

Autoservei de pipelines

L’Autoservei de pipelines permet als usuaris la generació de pipelines per a l’automatització de la construcció i el desplegament de les aplicacions a partir de la configuració d’una sèrie de fitxers en format YML. D’aquesta manera, els proveïdors d’aplicacions disposen d’autonomia per a configurar el seu comportament. Per a més informació: Autoservei de pipelines

Matriu de tecnologies de construcció

Les tecnologies de construcció d’aplicacions serveixen per gestionar el cicle de vida d’una aplicació o algunes de les seves fases. Aquesta normativa del SIC no invalida l’Estàndard pel full de ruta del programari, ans al contrari, l’estén per a acabar de concretar els requeriments propis del SIC.

Microsoft

Maven/JDK

Ant/JDK

Node/npm

L’única eina que va lligada en certa manera amb la versió de Node és npm. La resta d’eines de cicle de vida, tals com ng de Angular (framework de frontend recomanat per Arquitectura CTTI i el CS Canigó), bower, gulp i grunt, s’han de definir com a dependències a l’aplicació (fitxer package.json) i instal·lar-los a la construcció de l’aplicació via npm install.

Node/pnpm

Com a alternativa a Npm, per a Node 20 s’ofereix també la possibilitat d’utilitzar pnpm, informació aquí, un gestor de paquets més lleuger.

Hugo (Webs estàtiques)

Matriu de desplegament en servidors (IAAS)

Si es volen fer servir les tasques de desplegaments automatitzats des de SIC, caldrà escollir la modalitat de desplegament DELEGADA per a que l’aplicació es desplegui sobre un dels següents proveïdors d’infraestructures i tipus de servidor:

Les tasques d’execució de desplegament automatitzat fan un redesplegament de l’aplicació i no pas un desplegament. Per tant, cal que l’aplicació ja es trobi desplegada prèviament. La petició per a fer aquest primer desplegament de l’aplicació va a càrrec dels proveïdors de l’aplicació.

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.