singulars/funcionalitats/wp-react.md

@@ -216,7 +216,7 @@ Per a la transpilació automatitzada i el desplegament dels diferents paquets di
 
 Els runners de gitlab disposaran de configuració variable en funció de l'entorn per al que s'estigui executant el procés: _staging_ o _productiu_. Per a aquesta configuració variable es defineixen, dins el sistema de CI/CD de Gitlab, els mateixos entorns, _staging_ i _production_, i es fa ús de [les variables d'entorn](https://docs.gitlab.com/ee/ci/variables/) vinculades a un o altre. Aquestes variables d'entorn s'encarregan de modificar el comportament de la _pipeline_ per ajustar-lo als requeriments variables entre entorns. En panell de configuració de variables d'entorn d'un repositori gitlab el podem trobar a [settings > CI/CD > Variables](https://git.coopdevs.org/coopdevs/som-connexio/oficina-virtual/somoffice/-/settings/ci_cd). 
 
-Per últim, s'utilita un sistema de reconeixement de patrons sobre el text del _tag_ per apuntar a un o altre entorn. Els _tags_ del projecte segueixen el patró `v?[0-9]+[.][0-9]+([.][0-9]+)?([-a-z])*`. **Els _tags_ sense sufix s'entenen com a marcas de versió productives, els _tags_ amb el sufix `-staging` s'entenen com a marques de versions per a l'entorn de proves**. La creació de nous _tags_ dispararà l'activació de la _pipeline_ vinculada a un o altre entorn.
+Per últim, s'utilita un sistema de reconeixement de patrons sobre _tags_ i branques per apuntar a un o altre entorn. Els _tags_ del projecte segueixen el patró `v?[0-9]+[.][0-9]+([.][0-9]+)?([-a-z])*`, basat en l'estàndad [semver](https://semver.org/). Els _tags_ que s'ajustin a aquest patró s'identifiquen com a marques de versionat i habiliten la _pipeline_ de l'entorn productiu; les branques que s'ajustin al patró `testing/*` s'identifiquen com versions de codi en fase de validació i habiliten la _pipeline_ de l'entorn de _staging_. La creació de nous _tags_, o la publicació de nous commits a una branca `testing/*`, dispararà l'activació de la _pipeline_ vinculada a un o altre entorn.
 
 La nova pipeline estarà estructurada en una cadena de _jobs_ que segueix el següent fluxe: `test > build > package > upload > release > deploy`. L'últim _job_ de la _pipeline_ és el de desplegament. Aprofitant el sistema de _runners_, s'ha definit una rutina que permet automatizar el desplegament del codi des de Gitlab. Aquest requereix que el procés d'execució conegui la URL on fer la petició i les credencials d'un usuari al sistema de WordPress. Amb aquesta informació accessible a través de les variables d'entorn, **el procés es capaç de connectar-se a WordPress a través d'una connexio HTTP i desplegar l'última versió de codi transpilat**.