ContacteIntegració 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, 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:
- Si el desplegament no és capaç de crear la CRQ, el desplegament no continuarà i 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.- 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 despligue contínuo, 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.
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.