[DRAFT] Orquestrador de Releases

Introducció

L’Orquestrador de releases és el mecanisme centralitzat del SIC+ que permet coordinar el desplegament complet d’una release de tots els components definits d’aplicació, permetent desplegar múltiples components de forma coordinada i executar automàticament les proves de validació corresponents a través del Marc d’Automatització de Testing (MAT).

A diferència del desplegament unitari per component —en el qual cada repositori gestiona el seu propi workflow de CI/CD de forma independent—, l’orquestrador permet al release manager definir, quines versions de cada component es volen desplegar conjuntament, en quin ordre, i quins tests s’han d’executar per validar la release abans de pujar a producció.

L’orquestrador és responsable de:

• Coordinar el desplegament de múltiples components d’una aplicació des del repositori application-metadata.
• Garantir que tots els components definits han estat prèviament desplegats amb les versions correctes a l’entorn.
• Invocar el MAT per a l’execució automatitzada de proves funcionals, de regressió, de rendiment i d’API.
• Integrar-se amb ITSM Remedy per a la gestió del canvi corporatiu, incloent l’obertura, aprovació i tancament automàtic de tickets CRQ.

Nota: L’equip del SIC únicament és responsable de la integració amb el MAT, no del seu desenvolupament ni dels dubtes d’ús per part dels lots de manteniment d’aplicacions. Per a qualsevol dubte sobre el desenvolupament de tests de Selenium, JMeter o Postman, cal consultar la Documentació Marc d’Automatització de Testing (MAT) publicada per l’equip de Qualitat del CTTI.

Definició de l’orquestrador i disseny

Visió general

L’orquestrador actua com a punt central de control per a les releases d’aplicació. El release manager és el responsable de crear i mantenir els fitxers de configuració necessaris al repositori application-metadata, des d’on es llancen els desplegaments orquestrats.

Components principals

L’orquestrador es recolza en dos fitxers de configuració principals ubicats al repositori application-metadata:

Flux de desplegament orquestrat

El desplegament orquestrat segueix els passos següents:

1. El release manager edita el fitxer application.yaml definint la versió, els components, les dependències i els tests. Aquest pas és opcional, ja que aquest fitxer patirà pocs canvis un cop definit durant l’aprovisionament del repositori.

2. El release manager crea un pla a plans/active/ amb la nomenclatura release-plan-<version>.yaml (exemple: release-plan-1.0.1-RC.yaml), on “version” és correspon amb la versió de la release de l’aplicació. Aquesta és una versió lògica que no té perquè coincidir amb les versions dels diferents components que formen part de la release.

3. El release manager executa el workflow orquestrat sota demanda, passant tots els paràmetres necessaris que no estiguin ja definits als fitxers application.yaml o release-plan.yaml.

4. Es valida l’estructura del fitxer application.yaml mitjançant un procés de validació d’esquema (schema validation).

5. Es valida l’estructura del fitxer release-plan.yaml mitjançant un procés de validació d’esquema (schema validation).

6. Es processa el fitxer release-plan.yaml per emmagatzemar en variables d’entorn la informació de cada component inclòs al pla.

7. Es processa el fitxer application.yaml per enriquir la informació de cada component. També s’emmagatzema la informació necessària per a la integració amb ITSM i el MAT.

8. PRE-CHECKS: Es comproven i validen les condicions prèvies al desplegament. Si algun d’aquests punts falla o no es compleix, el desplegament orquestrat es cancel·la:

   1. Valida que la versió i l’entorn de la release són correctes.

   2. Els components del release-plan existeixen a application.yaml.

   3. No existeixen dependències circulars; es genera l’arbre de dependències i l’arbre invers per al rollback.

   4. Valida l’existència dels fitxers d’estat implicats en el pla i enriqueix la informació de cada component amb la versió actual desplegada.

   5. Les versions objectiu existeixen com a tags de repositori i són vàlides.

9. Es crea un únic ticket CRQ per a tot el desplegament orquestrat i es transiciona a l’estat “In Progress”.

10. Per a cada desplegament unitari orquestrat, seguint l’arbre de dependències per nivells (cada nivell s’executa en paral·lel):

    • S’executen en paral·lel els workflows de CD unitaris del nivell corresponent de l’arbre de dependències, amb espera activa i passant els paràmetres necessaris.

    • Si el workflow retorna un error de desplegament d’un component, s’avorten els desplegaments pendents i s’executa el rollback definit:

      • Rollback: per a cada component del release-plan.yaml, es comprova si el camp target_version coincideix amb la versió registrada a la informació temporal de canvis d’estat de la release. Si coincideix, es fa un desplegament a la versió current del fitxer d’estat del component. Si no coincideix, s’omet el component, ja que s’assumeix que no ha estat desplegat. Es té en compte també el valor de auto_rollback: si és false, no s’executa cap acció per a aquell component.

    • Si el workflow finalitza correctament i es valida el desplegament, s’actualitza el fitxer temporal de canvis d’estat de la release amb la nova versió desplegada.

11. Un cop completats els desplegaments de tots els components del release-plan, s’executen els tests definits: functional, regression, performance i/o api. La informació per als tests del MAT ha estat processada prèviament.

12. Es tanca el ticket CRQ amb l’estat final del desplegament.

13. Es mou el pla de release de active/ a completed/ o a failed/ segons el resultat del desplegament.

14. S’itera pels fitxers d’estat de cada component inclòs al release-plan.yaml i s’actualitza la secció current amb la nova versió desplegada; s’afegeix al principi de l’historial el registre de la versió anterior, mantenint únicament les dues últimes entrades de l’historial de versions.

15. Es crea un tag al repositori central amb la versió de la release desplegada a l’entorn corresponent.

Tipologies suportades

L’orquestrador suporta el desplegament de totes les tipologies de components del SIC+ excepte CloudOps, Libraries i Tests.

Requisits

Per tal que un component pugui participar en un desplegament orquestrat, cal que es compleixin els requisits següents:

• Desplegament previ del component de forma unitària: Cada component a desplegar per l’orquestrador haurà d’haver estat desplegat de forma unitària almenys una vegada, per tal de generar el fitxer d’estat del component al repositori central de metadades de l’aplicació. Això garanteix que el workflow de desplegament del component està correctament configurat i validat.

• Artefacte corresponent a la versió existent: S’ha d’haver executat el flux complet de CI fins a generar l’artefacte, emmagatzemar-lo a JFrog Artifactory i crear el tag de repositori corresponent en el mateix procés.

• Fitxer release-plan.yaml: El release manager s’encarregarà de crear i informar el fitxer release-plan.yaml a la carpeta plans/active a partir del template disponible a la carpeta plans del repositori application-metadata. És responsabilitat del release manager assegurar-se que tots els camps del fitxer i els inputs de cada component estiguin correctament informats abans de llançar el desplegament orquestrat. En aquest fitxer també es defineixen els tests que es volen executar en el desplegament orquestrat.

• Fitxer application.yaml: El release manager s’encarregarà de mantenir actualitzat el fitxer application.yaml, on es defineixen les dependències entre components de l’aplicació. Addicionalment, aquest fitxer permet configurar de forma genèrica, aplicable a tots els components del desplegament orquestrat, els camps següents:

  • auto_rollback: indica si s’ha de realitzar un rollback automàtic en cas de fallada durant el desplegament. Aquest paràmetre pot ser sobreescrit pel auto_rollback de component al fitxer release-plan.yaml.
  • Marc d’Automatització de Testing (MAT):
    • env_to_test: entorn sobre el qual s’executaran les proves de validació post-desplegament.
    • jira_project_key: clau del projecte de Jira associat, utilitzada per a la traçabilitat del desplegament.
    • jira_issue_key: identificador de la issue de Jira vinculada al desplegament en curs. Aquest paràmetre pot ser sobreescrit pel jira_issue_key de cada test al fitxer release-plan.yaml.

També s’informen en aquest fitxer els paràmetres d’ITSM: configuració necessària per a la integració amb el sistema de gestió de canvis corporatiu, permetent l’obertura i tancament automàtic de tickets associats al desplegament.

• Noms de component a release-plan.yaml: Els noms dels components definits al release-plan.yaml han de coincidir amb el nom d’aquell component al application.yaml.

• Noms de tests a release-plan.yaml: Els noms dels tests definits al release-plan.yaml han de coincidir amb el nom d’aquell test al application.yaml.

Nota: Un error en la configuració del release-plan.yaml o application.yaml pot provocar que l’orquestrador falli en els seus processos de validació. Es recomana revisar els fitxers amb detall abans d’iniciar el procés i assegurar-se de no definir dependències circulars.

Estructura del repositori application-metadata

El repositori application-metadata segueix una estructura de directoris estandarditzada que organitza els fitxers de configuració, els plans de release i els fitxers d’estat de cada component per entorn:

application-metadata/
├── application.yaml                        ← metadades globals de l'aplicació
├── environments/
│   ├── pre/
│   │   ├── <nom_repositori_component_1>.yaml
│   │   ├── <nom_repositori_component_N>.yaml
│   │   └── ...
│   └── pro/
│       ├── <nom_repositori_component_1>.yaml
│       ├── <nom_repositori_component_N>.yaml
│       └── ...
└── plans/                                  ← release plans (un per desplegament)
    ├── release-plan-template.yaml
    ├── active/                             ← pla en curs (màxim un per entorn)
    │   └── release-plan-1.0.1-RC.yaml
    ├── completed/                          ← plans finalitzats (historial)
    │   ├── release-plan-1.0.0.yaml
    │   ├── release-plan-1.0.0-RC.yaml
    │   └── ...
    └── failed/                             ← plans que han fallat o s'han avortat
        └── release-plan-0.0.9-RC.yaml

Fitxers protegits

Al repositori application-metadata, hi ha dos conjunts de fitxers protegits que únicament poden ser modificats per l’equip del SIC i que no han de ser alterats pels equips de desenvolupament:

Carpeta .github/

Conté la definició del workflow de l’orquestrador i la configuració de manteniment del repositori. Cap d’aquests fitxers ha de ser modificat pels equips d’aplicació:

Carpeta environments/

Conté els fitxers d’estat de desplegament de cada component per entorn. Aquests fitxers són gestionats automàticament pel workflow de l’orquestrador i reflecteixen l’última versió desplegada de cada component a cada entorn. No han de ser modificats manualment.

L’estructura de la carpeta segueix el patró:

environments/
  status-file-template.yaml
  pre/
    <app_code>.<comp_code>-<acronim>-<tipologia>.yaml   # p.ex. 8888.00-orchtest-infra.yaml
    <app_code>.<comp_code>-<acronim>-<tipologia>.yaml   # p.ex. 8888.00-orchtest-container_test-backend.yaml
  pro/
    <app_code>.<comp_code>-<acronim>-<tipologia>.yaml
    ...

Cada fitxer d’entorn registra la versió desplegada del component corresponent i un historial que manté les dues últimes versions desplegades, i és consultat per l’orquestrador per validar l’estat actual dels desplegaments abans d’iniciar una nova release.

Configuració del repositori de metadades d’aplicació

Fitxer application.yaml

El fitxer application.yaml és el fitxer de configuració global de l’aplicació. El release manager és el responsable de mantenir-lo actualitzat. Defineix les dependències entre components i la configuració genèrica aplicable a tots els desplegaments orquestrats.

Els camps configurables són:

• auto_rollback: Indica si s’ha de realitzar un rollback automàtic en cas de fallada durant el desplegament.
• env_to_test: Entorn sobre el qual s’executaran les proves de validació post-desplegament. Valors possibles: Desenvolupament, Preproduccio, Produccio.
• jira_project_key: Clau del projecte de Jira associat, utilitzada per a la traçabilitat del desplegament.
• jira_issue_key: Identificador de la issue de Jira vinculada al desplegament en curs.
• Paràmetres ITSM: Configuració necessària per a la integració amb el sistema de gestió de canvis corporatiu, permetent l’obertura i tancament automàtic de tickets associats al desplegament.

Fitxer release-plan.yaml

El fitxer release-plan.yaml defineix els components i les versions concretes que es volen desplegar en una release. Es crea per al release manager a partir del template disponible a la carpeta plans del repositori application-metadata.

També permet definir els tests del MAT que s’han d’executar en el desplegament orquestrat.

És responsabilitat del release manager assegurar-se que tots els camps del fitxer i els inputs de cada component estiguin correctament informats abans de llançar el desplegament orquestrat.

Exemples de configuració

Exemple de application.yaml

A continuació es mostra un exemple real del fitxer application.yaml per a l’aplicació orchtest (codi 8888, component 00):

application:
  name: 'orchtest'
  auto_rollback: 'false'
  parameters:
    global:
      env_to_test: 'Preproduccio'
      jira_project_key: ''
      jira_issue_key: 'test'
    functional:
      url_app: 'https://ctti.ghe.com/ctti-lab/0005.00-orchtest-functional-tests'
    regression:
      url_app: 'https://ctti.ghe.com/ctti-lab/0005.00-orchtest-regression-tests'
    api:
      app_name: '<orchtestapp>'
  components:
    - name: 'infrastructure'
      repository: 'https://ctti.ghe.com/ctti-lab/8888.00-orchtest-infra'
      depends_on: []
    - name: 'container_test'
      repository: 'https://ctti.ghe.com/ctti-lab/8888.00-orchtest-container_test-backend'
      depends_on: [infrastructure]
    - name: 'function_test'
      repository: 'https://ctti.ghe.com/ctti-lab/8888.00-orchtest-function_test-backend'
      depends_on: []
  itsm:
    class: 'Normal'
    type_affectation: 'TALL DE SERVEI'
    affectation: 'Cambio por modificación de funcionalidad'
    impact: '4-Minor/Localized'
    tier3: 'VULNERABILITAT'
    priority: '4-Low'
  tests:
    - name: 'FunctionalTests'
      type: 'functional'
      url: 'https://ctti.ghe.com/ctti-lab/8888.00-orchtest-functional-tests'
      branch: 'master'
    - name: 'RegressionTests'
      type: 'regression'
      url: 'https://ctti.ghe.com/ctti-lab/8888.00-orchtest-regression-tests'
      branch: 'master'
    - name: 'PerformanceTests'
      type: 'performance'
      url: 'https://ctti.ghe.com/ctti-lab/8888.00-orchtest-performance-tests'
      branch: 'master'
    - name: 'ApiTests'
      type: 'api'
      url: 'https://ctti.ghe.com/ctti-lab/8888.00-orchtest-api-tests'
      branch: 'master'

Exemple de release-plan.yaml (template)

release-plan:
  version: '<release_version>'
  environment: '<environment>'
  elements:
    - name: '<element_1>'
      target_version: '<target_version>'
      auto_rollback: '<auto_rollback>'
      delay: '<delay_in_seconds>'
      inputs:
        <input_1>: '<value_1>'
        <input_2>: '<value_2>'
        <input_n>: '<value_n>'
    - name: '<element_2>'
      target_version: '<target_version>'
      auto_rollback: '<auto_rollback>'
      delay: '<delay_in_seconds>'
      inputs:
        <input_1>: '<value_1>'
        <input_2>: '<value_2>'
        <input_n>: '<value_n>'
    - name: '<element_N>'
      target_version: '<target_version>'
      auto_rollback: '<auto_rollback>'
      delay: '<delay_in_seconds>'
      inputs:
        <input_1>: '<value_1>'
        <input_2>: '<value_2>'
        <input_n>: '<value_n>'
  tests:
    - name: 'FunctionalTests'
      jira_issue_key: '<jira_issue_key>'
    - name: 'RegressionTests'
      jira_issue_key: '<jira_issue_key>'
    - name: 'PerformanceTests'
      jira_issue_key: '<jira_issue_key>'
    - name: 'ApiTests'
      jira_issue_key: '<jira_issue_key>'

En el cas que algun test o element estigui comentat o no vingui informat, s’ometrà l’execució d’aquell tipus de prova o no es comprovarà el desplegament d’aquell component a l’entorn de preproducció.

Exemple real d’un aplicatiu (codi 8888, component 00, acrònim “orchtest”)

release-plan:
  version: '1.0.2-RC'
  environment: 'pre'
  elements:
    - name: 'infrastructure'
      target_version: '1.0.2-RC'
      auto_rollback: 'true'
      delay: '30'
      inputs:
        infra_version_plan: '1.0.2-RC'
        environment: 'pre'
    - name: 'container_test'
      target_version: '1.0.2-RC'
      auto_rollback: 'false'
      delay: '60'
      inputs:
        artifact_version: '1.0.2-RC'
        environment: 'pre'
        registry_name: 'registry_name_pre'
        resource_group: 'resource_group_pre'
        itsm_tier2: 'CODI'
    - name: 'function_test'
      target_version: '1.0.0-RC'
      delay: '60'
      inputs:
        artifact_version: '1.0.0-RC'
        environment: 'pre'
        function_names: 'container_app_pre'
        storage_name: '<storage_name_pre>'
        itsm_tier2: 'CODI'
  tests:
    - name: 'FunctionalTests'
      jira_issue_key: 'test1'
    - name: 'RegressionTests'
      jira_issue_key: 'test2'
    # - name: 'PerformanceTests'
    #   jira_issue_key: '<jira_issue_key>'
    # - name: 'ApiTests'
    #   jira_issue_key: '<jira_issue_key>'

Esquema de validació del application.yaml

El fitxer application.yaml és validat automàticament per l’action de l’orquestrador contra el següent esquema:

Esquema de validació del release-plan.yaml

El fitxer release-plan.yaml és validat automàticament per l’action de l’orquestrador contra el següent esquema:

Validació de components

A més de l’esquema estàtic anterior, l’orquestrador aplica una validació dinàmica dels elements definits al release-plan.yaml contrastant-los amb els components declarats al application.yaml. Concretament:

• Cada name d’un element del release-plan.yaml ha d’existir com a component al application.yaml.
• De la mateixa manera, cada name d’un test del release-plan.yaml ha d’existir com a test al application.yaml.

A més, per a cada element del release-plan.yaml, l’orquestrador obté dinàmicament els inputs requerits pel workflow de desplegament del component corresponent i verifica que tots estiguin informats abans d’iniciar el desplegament. Si algun input obligatori no és present, el procés de validació falla i el desplegament no s’inicia.

Aquesta validació garanteix la coherència entre el pla de release i la configuració global de l’aplicació, i evita desplegaments amb components o tests no reconeguts o amb inputs incomplets.

Integració amb el MAT

Marc d’Automatització de Testing (MAT)

El MAT és un framework especialitzat en l’automatització de proves, dissenyat per integrar-se amb els fluxos de desplegament del SIC+. El seu objectiu és garantir la qualitat del programari mitjançant l’execució automatitzada de proves en entorns preproductius.

El SIC+ s’integra amb el MAT per a l’execució de 4 tipologies de proves:

Els repositoris de proves funcionals i de regressió compten amb tres branques principals (develop, release i master) i un conjunt de workflows de CI/CD seguint el GitFlow del SIC+. Els repositoris de rendiment i API únicament compten amb la branca master.

Steps del MAT Orchestrator CD

S’ha eliminat la integració del MAT als workflows unitaris de cada component. Únicament es podrà integrar amb el MAT a través de l’orquestrador. Per habilitar-lo, la variable d’organització ORGANIZATION_MAT (gestionada per l’equip del SIC+) haurà de ser true (valor per defecte i que únicament variarà en cas d’algun problema general amb la integració amb el MAT), i el fitxer release-plan.yaml haurà de tenir definit almenys un test. Els passos relacionats amb el MAT al workflow orquestrador són els següents:

Integració amb ITSM Remedy

L’orquestrador de releases s’integra amb el sistema de gestió de canvis corporatiu ITSM Remedy per garantir la traçabilitat i control de tots els desplegaments a entorns productius i preproductius.

Flux d’integració

El flux d’integració amb ITSM és el següent:

1. Obtenció de paràmetres ITSM: L’ordre de prioritat per a l’obtenció dels paràmetres és el següent:
   • Inputs: Inputs informats a través del formulari d’execució del workflow.
   • Fitxer application.yaml: paràmetres ITSM definits al fitxer application.yaml
2. ITSM PRE: En iniciar el desplegament, es crea automàticament un ticket CRQ a Remedy indicant el començament del desplegament, amb la informació de l’aplicació, entorn, versió i responsable del canvi.
3. ITSM APPROVE AND WAIT: Si s’ha habilitat enable_itsm_approve: true, el workflow espera que la CRQ sigui aprovada a Remedy (automàticament o manualment) i que hagi transcorregut el temps de finestra de canvi configurat (scheduled_start_date / scheduled_end_date).
4. ITSM PROGRESS: Un cop aprovada la CRQ, l’estat del ticket es canvia a “en progrés” i s’inicia el desplegament.
5. ITSM POST: En finalitzar el desplegament, s’actualitza el ticket CRQ amb el resultat (exit o error).
6. ITSM CANCEL: Si el workflow es cancel·la en qualsevol moment, el ticket CRQ es tanca automàticament amb estat “cancel·lat” (únicament si havia estat creat prèviament).

Paràmetres de configuració ITSM

Els paràmetres ITSM es poden informar a través del formulari d’execució del workflow de CD o es configuren al fitxer application.yaml del repositori application-metadata i s’apliquen a tots els desplegaments orquestrats de l’aplicació:

Nota: Fins i tot si enable_itsm_approve és false, la CRQ es crea a Remedy. En cas d’error en la creació del ticket, el desplegament continua i l’error es registra als logs del workflow.

Workflows Unitaris

Es pot consultar el flux a la imatge següent:

Quan un component és desplegat a través de l’orquestrador de releases, el workflow de CD del component s’executa en un mode orquestrat que difereix del mode unitari estàndard en tres aspectes clau: la gestió d’ITSM, l’actualització dels fitxers d’estat de component i la integració amb el MAT.

ITSM en mode orquestrat

Quan l’orquestrador invoca el workflow de CD d’un component, no s’executen els steps d’ITSM del workflow unitari. La raó és que l’obertura, el seguiment i el tancament del ticket CRQ es gestionen de forma centralitzada des del workflow orquestrador, garantint un únic ticket per a tot el desplegament de la release. Això evita la creació de múltiples tickets per a desplegaments que formen part d’una mateixa release.

Fitxers d’estat de component en mode orquestrat

Els fitxers d’estat de component ubicats a la carpeta environments/ del repositori application-metadata no s’actualitzen des del workflow unitari quan el desplegament és invocat per l’orquestrador. L’actualització d’aquests fitxers la gestiona de forma centralitzada el workflow orquestrador un cop completat el desplegament de cada component, garantint la consistència de l’estat global de la release.

MAT en mode orquestrat

La integració amb el Marc d’Automatització de Testing (MAT) s’ha eliminat dels workflows unitaris. L’execució de proves automatitzades únicament és possible a través de l’orquestrador de releases, que gestiona la invocació del MAT un cop s’han desplegat tots els components de la release.

Nota: Si es necessita executar proves del MAT per a un component concret, cal fer-ho a través d’un desplegament orquestrat, fins i tot si la release conté un únic component.

Resum de comportament

Gestió del rollback

L’orquestrador de releases ofereix un mecanisme de rollback automàtic que permet revertir el desplegament d’un component a la versió anterior en cas de fallada.

Configuració

El comportament del rollback es controla mitjançant el paràmetre auto_rollback, que es pot configurar a dos nivells amb la següent ordre de prioritat:

1. Nivell de component (release-plan.yaml): el valor definit per a un element concret al release-plan.yaml té prioritat sobre la configuració global.
2. Nivell d’aplicació (application.yaml): valor per defecte aplicable a tots els components del desplegament orquestrat, si no s’especifica a nivell de component.

Comportament

Quan auto_rollback és true per a un component i el seu desplegament falla, l’orquestrador executa automàticament el workflow de desplegament del component amb la versió prèviament desplegada, que consta al fitxer d’estat corresponent a la carpeta environments/.

El rollback no s’executa en els casos següents:

• auto_rollback és false per al component afectat.
• No existeix una versió prèviament desplegada al fitxer d’estat del component (primer desplegament).

Nota: El rollback únicament reverteix el component que ha fallat i els components que sí han arribat a desplegar-se correctament amb auto_rollback a true abans de detectar la fallada del component que paralitza el desplegament de la release, no els components que no han arribat a desplegar-se. Si algun component té auto_rollback a false i ha estat desplegat, caldrà fer el rollback de forma manual.

Exemple end-to-end

A continuació es descriu un exemple complet del procés de release per a l’aplicació myapp (codi 9999, component 99) amb tres components (Infra, Frontend i Backend) i execució de proves funcionals i de regressió.

1. Compliment dels prerequisits

   Abans d’iniciar el procés de desplegament orquestrat, cal verificar que es compleixen una sèrie de condicions prèvies necessàries per al correcte funcionament de l’orquestrador:

   • El repositori application-metadata (9999.99-myapp-application-metadata) existeix i té l’estructura de directoris correcta, incloent les carpetes environments/pre, environments/pro i plans/active.
   • El fitxer application.yaml del repositori application-metadata està correctament configurat amb el nom de l’aplicació, les dependències entre components, la configuració ITSM i, si escau, els tests del MAT.
   • Cada component de la release (Infra, Frontend i Backend) ha estat desplegat individualment almenys una vegada, de manera que existeixen els fitxers d’estat corresponents a la carpeta environments/ del repositori application-metadata.
   • Si s’ha d’executar la integració amb el MAT, els repositoris de proves estan configurats i la variable d’organització ORGANIZATION_MAT té el valor true.

   Objectiu: Garantir que totes les condicions prèvies necessàries per al desplegament orquestrat estan satisfetes.

   Actors:

   • Release manager amb Rol Maintain al repositori application-metadata.
   • Usuari amb Rol Write o Maintain de cada repositori de component.

   Execució de Workflows: No s’executa cap workflow en aquest pas.

   Resultat de l’operació:

   • Repositori application-metadata existent i correctament estructurat.
   • Fitxer application.yaml configurat amb les dependències entre components i els paràmetres ITSM.
   • Fitxers d’estat de component existents a la carpeta environments/ per a tots els components de la release (Infra, Frontend i Backend).

2. Execució completa del CI de cada component per generar els artefactes desplegables

   Cadascun dels components ha de completar el seu procés de CI per generar els artefactes que després desplegarà l’orquestrador, seguint el flux GitFlow habitual del SIC+. Com a resultat existeixen els tags de Release Candidate als repositoris:

   Component	Repositori	Tag existent
   Infra	9999.99-myapp-infra	1.0.32-RC
   Frontend	9999.99-myapp-example-frontend	2.2.15-RC
   Backend	9999.99-myapp-example-backend	1.10.0-RC

   Objectiu: Garantir que tots els components de la release han passat el seu propi procés de CI i estan disponibles a JFrog Artifactory amb les versions correctes.

   Actors:

   • Usuari amb Rol Write o Maintain de cada repositori de component.

   Execució de Workflows: Automàtic (flux GitFlow unitari de cada component).

   Resultat de l’operació:

   • Tags RC disponibles als repositoris dels components.
   • Artefactes generats per als components de la release i validats.

3. Configuració dels fitxers de la release

   El release manager prepara els fitxers de configuració necessaris per al desplegament orquestrat:

   • Revisa i actualitza el fitxer application.yaml del repositori application-metadata amb les dependències entre components i la configuració ITSM.
   • Crea el fitxer release-plan.yaml a la carpeta plans del repositori application-metadata a partir del template, indicant les versions de cada component i els tests a executar.

   Objectiu: Tenir tots els fitxers de configuració de la release correctament informats abans d’iniciar el desplegament orquestrat.

   Actors:

   • Release manager amb Rol Maintain al repositori application-metadata.

   Execució de Workflows: No s’executa cap workflow en aquest pas.

   Resultat de l’operació:

   • Fitxer release-plan.yaml creat i disponible a la carpeta plans/active.
   • Fitxer application.yaml actualitzat amb les dependències i paràmetres ITSM.

4. Llançament del desplegament orquestrat

   El release manager executa el workflow d’orquestrador manualment des de la pestanya Actions del repositori application-metadata.

   

   Objectiu: Iniciar el procés de desplegament orquestrat indicant el fitxer de release plan, la versió, l’entorn i els paràmetres d’ITSM.

   Actors:

   • Release manager amb Rol Maintain al repositori application-metadata.

   Execució de Workflows: Sota demanda per part del release manager.

   • El release manager accedeix a la pestanya Actions, selecciona el workflow Orchestrator CD i prem Run Workflow, els paràmetres obligatoris per a l’execució són:
     • release_plan_file: Nom del fitxer release-plan.yaml a executar.
     • release_version: Versió del fitxer release-plan.yaml a executar.
     • environment: Entorn de desplegament (pre o pro).
     • itsm_id_change_coordinator: ID del coordinador de canvis a ITSM.

   Resultat de l’operació:

   • Workflow d’orquestrador iniciat.

5. Validació i desplegament dels components

   L’orquestrador executa automàticament la validació dels fitxers de configuració i el desplegament seqüencial dels components en l’ordre definit al release-plan.yaml.

   Objectiu: Validar la configuració, crear la CRQ a ITSM i desplegar els components Infra, Frontend i Backend en l’ordre definit.

   Actors:

   • Procés automàtic de l’orquestrador.

   Execució de Workflows: Automàtic.

   • Validació: L’orquestrador llegeix el release-plan.yaml i el application.yaml, i comprova l’existència dels tags de versió als repositoris dels components.
   • ITSM PRE: Es crea automàticament un ticket CRQ a Remedy. Si enable_itsm_approve és true, el workflow espera l’aprovació de la CRQ abans de continuar.
   • Desplegament: Es despleguen els components en l’ordre definit: primer Infra, després Frontend i Backend (depenent d’Infra).

   Resultat de l’operació:

   • Configuració validada sense errors.
   • Ticket CRQ creat a ITSM Remedy i en estat “en progrés”.
   • Components Infra (1.0.32), Frontend (2.2.15) i Backend (1.10.0) desplegats a preproducció.

6. Execució de les proves del MAT

   Un cop desplegats tots els components, l’orquestrador invoca automàticament el MAT per executar les proves de validació definides al release-plan.yaml.

   Objectiu: Validar el correcte funcionament de l’aplicació a preproducció mitjançant l’execució automatitzada de proves MAT.

   Actors:

   • Procés automàtic de l’orquestrador i el MAT.

   Execució de Workflows: Automàtic.

   • MAT Functional Tests: Execució de les proves funcionals amb Selenium contra l’entorn de preproducció.
   • MAT Regression Tests: Execució de les proves de regressió amb Selenium.

   Resultat de l’operació:

   • Proves funcionals i de regressió executades.
   • Resultats de les proves disponibles al GITHUB_STEP_SUMMARY del workflow.

7. Tancament ITSM i notificació

   En finalitzar el desplegament i les proves, l’orquestrador tanca automàticament el ticket CRQ i notifica als responsables de l’aplicació.

   Objectiu: Registrar el resultat del desplegament a ITSM Remedy i notificar als afectats.

   Actors:

   • Procés automàtic de l’orquestrador.

   Execució de Workflows: Automàtic.

   • ITSM POST: S’actualitza el ticket CRQ amb el resultat del desplegament (èxit o error) i es tanca.
   • Notificació: S’envia un correu electrònic als responsables de l’aplicació amb el resum de la release.

   Resultat de l’operació:

   • Ticket CRQ tancat a ITSM Remedy amb el resultat del desplegament.
   • Correu de notificació enviat als responsables.
   • Resum complet del desplegament disponible al GITHUB_STEP_SUMMARY de GitHub Actions amb l’estat de cada component i de cada test executat.