Integració amb Remedy

Integració amb la gestió de canvis

Fins ara, tots els desplegaments realitzats de manera automàtica, ja fos cloud pública o privada o en modalitat delegada, comportaven la creació d’un tiquet CRQ en Remedy. El tiquet creat tenia una sèrie de característiques associades:

• S’utilitzada per a auditar els desplegaments realitzats, tant en entorns preproductius com en entorns productius.
• No precisaven de cap mena d’intervenció funcional, la seva aprovació era automàtica.
• No bloquejaven l’execució del desplegament, qualsevol inconvenient amb la creació del tiquet no implicava la cancel·lació del desplegament.
• El desplegament es produïa de manera immediata, tan aviat s’autoritzava des de la pipeline l’execució del desplegament, aquest es produïa.

D’ara endavant, si l’aplicació o component no està en producció i figura a nivell de Remedy en estat ‘deployed’, no s’obrirà CRQ en Remedy. En el cas que sí que sigui ja productiva l’aplicació, la integració amb la gestió de canvis de Remedy serà més acoblada i, perquè l’execució del desplegament continuï, haurà d’avaluar si la CRQ ha estat aprovada o no abans de continuar. Això significa que s’introdueixen els següents canvis:

• L’obertura de CRQ només es realitzarà sobre aquells components d’aplicació que figurin amb l’estat ‘deployed’ en Remedy. Aplicacions o components en fase de projecte o altres estats no precisaran de CRQ. Tampoc obriran CRQ els desplegaments en els entorns de rèplica de producció ni de preproducció.
• En aquestes aplicacions en estat ‘deployed’, si el desplegament no és capaç de crear CRQ, no continuarà, s’avortarà.
• Qui invoqui o aprovi el desplegament a nivell de SIC, haurà de comptar amb els permisos de “Change Coordinator” per a poder crear CRQs de l’aplicació per a la qual s’estigui desplegant. L’usuari GICAR del aprobador del desplegament figurarà amb aquest rol en la CRQ creada.
• Haurà d’informar-se en el moment d’aprovar el desplegament en el costat de SIC, entre altres coses, de la finestra en la qual ha de produir-se el desplegament i que podrà ser en qualsevol moment en els 30 dies següents a l’aprovació del desplegament en el costat SIC.
• En el costat Remedy, la CRQ creada podrà disposar d’una aprovació automàtica, i en aquest cas s’aprova i es retorna el control al SIC, o bé podrà requerir una aprovació manual, i en aquest cas algun responsable funcional ha d’aprovar l’execució de la CRQ en la finestra informada.
• Els entorns no productius sempre comptaran amb aprovacions automàtiques.
• Si una aplicació requereix o no una aprovació manual, és una cosa que es determinarà entre els responsables de l’aplicació i l’equip de preparar el servei.
• Si la finestra de desplegament no s’informa, s’assumeix un desplegament immediat.
• Si l’aprovació de la CRQ en el costat de Remedy no ocorre abans de l’inici de la finestra de desplegament, s’avortarà l’execució.
• El desplegament s’executarà automàticament en la data i hora informada en la finestra de desplegament, no es precisarà cap mena d’intervenció addicional perquè s’executi.

Novetats en pipelines SIC 3.0

A partir d’ara, en els pipelines de SIC 3.0, ocorreran els següents canvis:

1.- En el moment d’aprovar el desplegament, a més de tots els camps que s’informaven anteriorment, ara cal informar inici i fi de la finestra de desplegament.

2.- També apareix el nou camp “ITSM TIER 2” que es correspon amb el mateix camp en la CRQ. Aquest camp s’utilitzarà per a especificar CODI-MARXA ENRERE quan es tracti d’un desplegament d’una versió anterior per a fer una marxa enrere d’una cosa errònia.

3.- En la pipeline auxiliar de desplegament, apareixeran una nova fase en la qual espera una crida des de Remedy amb el resultat d’aprovació o rebuig de la CRQ.

3.- L’aprovació ha de realitzar-se en el costat de Remedy i serà automàtica en entorns preproductius i en la majoria d’aplicacions en els seus entorns productius. Solament algunes aplicacions requeriran aprovació manual.

4.- L’establiment d’una aprovació manual és una cosa que es realitzarà entre el proveïdor de l’aplicació i els responsables funcionals d’aquesta, no es determinarà en SIC en cap cas.

5.- Quan es rep la resposta de Remedy, s’avalua l’aprovació o rebuig. Si es rebutja, en aquest moment s’avorta la pipeline.

6.- Si la CRQ resulta aprovada, hi haurà una nova espera fins a l’arribada de l’inici de la finestra de desplegament.

7.- En aprovacions automàtiques, la fase d’aprovació trigarà alguns minuts en el que s’alinea SIC i Remedy i es rep la resposta.

Novetats en workflows SIC+

En SIC+, a l’hora de llançar els workflow de desplegament continu, s’observaran les següents novetats:

1.- En llançar el workflow s’haurà d’informar l’inici i fi de la finestra de desplegament. Deixar-la en blanc significa que es realitzarà de manera immediata.

2.- Apareix una nova etapa en el flux en la qual es quedarà a l’espera de rebre l’aprovació o rebuig des de Remedy.

3.- Aquesta nova etapa es queda en espera i es reprendrà quan es rebi resposta de Remedy i, si el canvi s’aprova, quan arribi la finestra de desplegament.

4.- Si la resposta des de Remedy és que el canvi resulta rebutjat, el workflow s’avorta sense executar el desplegament.

Comportament ITSM: workflow unitari vs. orquestrat

El comportament de la integració amb ITSM Remedy difereix en funció de si el desplegament es realitza de forma unitària (des del propi repositori del component) o de forma orquestrada (a través de l’Orquestrador de Releases):

Aspecte	Workflow unitari	Workflow orquestrat
Obertura de CRQ	✅ S’executa per a cada component	❌ No s’executa al workflow unitari (gestió centralitzada per l’orquestrador)
Tancament de CRQ	✅ S’executa per a cada component	❌ No s’executa al workflow unitari (gestió centralitzada per l’orquestrador)
Nombre de CRQs generades	Una per component desplegat	Una única CRQ per a tot el desplegament orquestrat

Quan un component és desplegat a través de l’orquestrador, no s’executen els steps d’ITSM del workflow unitari. 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.

Obtenció dels paràmetres ITSM

L’ordre de prioritat per a l’obtenció dels paràmetres ITSM varia en funció del mode d’execució:

Workflow unitari (no orquestrat):

1. Inputs informats a través del formulari d’execució del workflow.
2. Fitxer itsm-inputs.json del repositori del component.
3. Fitxer application.yaml del repositori application-metadata.
4. Informació recuperada de APIs de serveis externs (Remedy i gicar)

Workflow orquestrat:

1. Inputs informats a través del formulari d’execució del workflow de l’orquestrador.
2. Fitxer application.yaml del repositori <cod_app>.<cod_comp>-<acronim>-application-metadata.
3. Informació recuperada de APIs de serveis externs (Remedy i gicar)

Els paràmetres ITSM i on es poden informar en funció del mode d’execució:

Paràmetre (formulari)	Obligatori	Formulari	itsm-inputs.json	application.yaml	Descripció
scheduled_start_date	No	✅	❌	❌	Data d’inici de la finestra de desplegament. Format: dd-MM-yyyy HH:mm.
scheduled_end_date	No	✅	❌	❌	Data de fi de la finestra de desplegament. Format: dd-MM-yyyy HH:mm.
itsm_tier2	No	✅	❌	❌	CODI (desplegament convencional) / CODI-MARXA ENRERE (rollback).
enable_itsm_approve	No	✅	❌	❌	Habilita l’aprovació prèvia de la CRQ. Per defecte: true.
itsm_class / ITSM_CLASS / itsm.class	Sí	✅	✅	✅	Normal / Emergency.
itsm_type_affectation / ITSM_TYPE_AFFECTATION / itsm.type_affectation	Sí	✅	✅	✅	DEGRADACIO / SENSE TALL DE SERVEI / TALL DE SERVEI.
itsm_affectation / ITSM_AFFECTATION / itsm.affectation	Sí	✅	✅	✅	Descripció de l’afectació.
itsm_impact / ITSM_IMPACT / itsm.impact	Sí	✅	✅	✅	4-Minor/Localized / 3-Moderate/Limited / 2-Significant/Large / 1-Extensive/Widespread.
itsm_tier3 / ITSM_TIER3 / itsm.tier3	Sí	✅	✅	✅	ADAPTATIU / CORRECTIU / EVOLUTIU / PREVENTIU / VERSIO / VULNERABILITAT.
itsm_priority / ITSM_PRIORITY / itsm.priority	Sí	✅	✅	✅	4-Low / 3-Medium / 2-High / 1-Critical.

Notes:

• La columna de formulari s’aplica tant a desplegaments unitaris com orquestrats (en el cas orquestrat, a través del formulari del workflow de l’orquestrador).
• El fitxer itsm-inputs.json només s’aplique en desplegaments unitaris (no orquestrats). En mode orquestrat, els paràmetres s’obtenen del formulari o del application.yaml del repositori application-metadata.
• Fins i tot si enable_itsm_approve és false, la CRQ es crea a Remedy. En cas d’error en la creació del ticket en un desplegament orquestrat, el desplegament continua i l’error es registra als logs del workflow.

Marxa enrere

Si hi ha algun inconvenient amb el desplegament de l’aplicació, és possible que es requereixi una marxa enrere d’aquest desplegament.

Aquests desplegaments de marxa enrere també hauran de generar una CRQ en Átom, però aquesta CRQ ha de tenir un tractament especial. Per a aquest cas, s’ha afegit al formulari un nou camp Categoria operacional - Tier 2 que podrà prendre els valors “CODI” per als desplegaments convencionals i “CODI-MARXA ENRERE” per als desplegaments de marxa enrere.

Aquesta nova categoria operacional de tier 2 tindrà un tractament especial a nivell de Átom, per tant és important que s’utilitzi solament en desplegaments de marxa enrere.

Com es desplegarà

Totes les novetats anteriorment indicades, tant en SIC 3.0 com en SIC+, s’aniran desplegant de manera gradual i avisant convenientment en cada fase amb la finalitat d’estar previnguts.

1.- En una primera fase, s’actualitzaran les versions de pipelines de SIC 3.0 i workflows de SIC+ a noves versions que ja suporten aquest model d’integració amb Remedy. Aquest primer desplegament no suposarà canvis ni intervenció per part dels desenvolupadors, la integració estarà latent i s’activarà posteriorment mitjançant una “feature flag”.

2.- En una segona fase, de manera progressiva, s’activarà aquest nou model d’integració. A partir d’aquest moment, es visualitzarà el nou formulari per a informar de la data d’inici del desplegament. Simplement deixant en blanc els camps de data i hora d’inici i fi de desplegament, es mantindrà el mateix comportament que ha existit fins ara: el tiquet CRQ es crearà i aprovarà automàticament i el desplegament es realitzarà de manera immediata. No obstant això, si alguna aplicació requereix demorar el desplegament fins a una determinada data i hora, ja podrà fer ús d’aquests camps per a fer-ho.

3.- En la fase final, ja els desenvolupadors i responsables de les aplicacions podran coordinar-se per a configurar les aprovacions manuals allà on es requereixin i estendre els desplegaments automàtics o delegats a entorns que fins ara no es podien fer automàticament per no disposar d’aquesta mena d’aprovacions des de Remedy.

Canales de suport

Si voleu més informació podeu consultar la secció de Serveis.
Si teniu qualsevol dubte o problema podeu revisar les Preguntes Freqüents o utilitzar els canals de Suport.