ContacteIntroducció
Amb l’objectiu de millorar la gestió de les incidències en producció i reduir els temps de resposta, s’ha implementat una actualització en el model de GitFlow utilitzat en els repositoris del SIC+. Aquesta actualització introdueix l’ús de branques hotfix per a la correcció ràpida d’errors crítics detectats en producció. Aquesta pràctica permet als equips de desenvolupament abordar i resoldre problemes urgents sense afectar el flux de treball principal, garantint així una major estabilitat i disponibilitat dels serveis.
Prèviament es permetia l’ús de les branques hotfix per a aplicar correciones d’errors ràpides en producció per a tota mena de repositoris, a excepció dels repositoris de contenidors, degut a que els seus workflows de CI/CD eren incompatibles per la seva definició amb aquesta pràctica.
Amb aquests canvis que s’han implementat, i els canvis que s’han de fer en els workflows dels repositoris existents tal com es detalla a continuació, es permetrà també l’ús d’aquesta eina per a correcció ràpida d’errors en producció en els repositoris de contenidors.
Model de GitFlow detallat amb branques hotfix
Aquest diagrama explica l’estratègia de control de versions (basada en Gitflow):
- master –> conté tot el codi que ha estat desplegat a producció - recull totes les versions “disponibles en live” i mai es treballa directament sobre elles.
- release –> es fusiona des de develop, quan el codi està llest per a ser posat en producció - normalment es crea una versió candidata (RC) en aquest punt.
- Es desaconsella treballar directament en la branca release, ja que els errors detectats durant la validació dels canvis requeriran correccions en la branca feature corresponent i es fusionaran de nou a través de desenvolupament per evitar la pèrdua de canvis posteriors.
- Un cop la versió està llesta, es fusiona amb la branca master i s’etiqueta amb el nom de la versió.
- develop –> és on es duu a terme la major part de l’activitat, tot i que no es treballa directament, sinó que es fusionen els canvis de les branques feature
- feature –> tenen una durada curta, per permetre als desenvolupadors treballar en una característica específica de forma aïllada de la branca de desenvolupament, on poden fer commits directes i push - es fusionen amb la branca de desenvolupament.
- hotfix –> es crea a partir de master quan s’identifica en producció un error que requereix una correcció urgent. La branca hotfix té un cicle de publicació “accelerat” i s’ha de fusionar amb la branca de desenvolupament per no perdre cap canvi. Aquesta branca hotfix podrà usar-se en qualsevol tipologia de repositori.
Per a poder fer ús de les branques hotfix en el CI/CD dels workflows de contenidors, és necessari substituir el workflow “container-ci-on-commit.yaml” existent al repositori pel workflow “container-ci-on-commit.yaml” que es troba en el repositori Container CI on commit with hotfix functionality. S’haurà de fer la configuració o “set-up” del nou workflow, els paràmetres del qual seran pràcticament els mateixos que els del workflow “container-ci-on-commit-develop.yaml”.
CI on commit hotfix
- technology: (opcional) Tecnologia del projecte. Valors possibles:
javajava-mavennodejsdotnetIMPORTANT .Net Framework no està suportatpythonjava-gradlecustom
- docker_build_context: (opcional) Context de construcció de Docker. Per defecte és
"."(l’arrel). Valor per defecte:"." - get_project_name_command: (opcional) Comanda per a obtenir el nom del projecte del fitxer descriptor. El paràmetre serà sempre requerit si la tecnologia és “custom”. Per a altres tecnologies, si s’informa, també serà requerit informar el paràmetre “get_version_command”.
- get_version_command: (opcional) Comanda per obtenir la versió de l’artefacte de l’artefacte del fitxer descriptor. El paràmetre serà sempre requerit si la tecnologia és “custom”. Per a altres tecnologies, si s’informa, també serà requerit informar el paràmetre “get_project_name_command”.
- project_name: (opcional) Nom del projecte, especificar només si no hi ha compilació en el projecte. En el cas de projectes amb tecnologia .NET i que en el repositori de projecte existeixin mes de dos .csproj, aquesta propietat project_name és obligatòria.
- java_version: (opcional) Versió de Java. Definir només si el projecte es basa en tecnologia Java.
- java_distribution: (opcional) Distribució de Java. Definir només si el projecte es basa en tecnologia Java.
- maven_version: (opcional) Versió de Maven. Definir només si el projecte es basa en tecnologia Java.
- node_version: (opcional) Versió de Node. Definir només si el projecte es basa en tecnologia Node.
- dotnet_version: (opcional) Versió de .Net. Definir només si el projecte es basa en tecnologia .Net.
- install_build_command: (opcional) Comanda personalitzada per construir i empaquetar el projecte. El valor per defecte per a nodejs és
"npm ci && npm run build", per a java maven"mvn package -Dmaven.test.skip=true", per a java gradle"gradle clean build", per a dotnet"dotnet restore $PROJECT_PATH && dotnet build $PROJECT_PATH --configuration Release && dotnet publish $PROJECT_PATH --configuration Release --output ./out", i per a python"pip install -r requirements.txt && python setup.py sdist bdist_wheel". Si no es proporciona cap comanda personalitzada, es farà servir la comanda per defecte segons la tecnologia especificada. - python_version: (opcional) Versió de python. Definir només si el projecte es basa en tecnologia python.
- gradle_version: (opcional) Versió de gradle. Definir només si el projecte es basa en tecnologia python.
- sonar_exclusions: (opcional) Exclusió de Sonar. Exemples:
node_modules/**test/**
- sonar_java_binaries_path: (opcional) Es correspon amb el parametro java.binaries de Sonarqube. Informar només quan la tecnologia sigui java o java-maven, el valor per defecte és
target/classes. - sonar_project_base_dir: (opcional) Es correspon amb el parametro projectBaseDir de Sonarqube. Propietat per a moure l’anàlisi a un directori diferent.
Exemple de crida al workflow:
name: Container CI on Commit to release or master
on:
pull_request:
branches:
- release
- master
types: [closed]
jobs:
call-reusable-workflow:
if: github.event.pull_request.merged == true
uses: ctti-arq/reusable-workflows/.github/workflows/container-ci-on-commit-hotfix-reusable.yaml@v4
secrets: inherit
with:
technology: java
java_version: 21
java_distribution: temurin
maven_version: 3.9.5
# install_build_command: "mvn package -Dmaven.test.skip=true"
Per a més informació dels paràmetres del workflow es pot consultar la Documentació de la configuració dels workflows de contenidors
Amb aquest model proposat, les úniques branques en que es treballa directament són les de feature i hotfix; la resta de branques evolucionen a través de fusions.
Es recomanen les pull requests en lloc de les fusions directes per a desenvolupaments complexos, ja que fomenten les revisions al llarg del procés.
La “regla d’or” per a les fusions descendents és que cada canvi introduït en producció es fusioni també en desenvolupament.
Per a aquest model, la nomenclatura que es farà servir per als noms dels artefactes serà la següent:
-
Per a la branca master –> major.minor.fix
Exemple: 1.2.0 -
Per a la branca hotfix/xxxx –> major.minor.fix
Exemple: 1.2.1 -
Per a la branca release –> major.minor.fix-RC
Exemple: 1.2.0-RC -
Per a la branca develop –> major.minor.fix-SNAPSHOT
Exemple: 1.2.0-SNAPSHOT
Referències
Per a més detall sobre les novetats en el model de GitFlow i l’aplicació de branques hotfix, es pot consultar la documentació següent dins d’aquest mateix portal: