La configuración de nuestros proyectos normalmente se basará en propiedades indicadas en el fichero application.properties de nuestro backend, no obstante cuando despleguemos nuestro proyecto en los diferentes entornos, esa configuración se ignorará ya que la configuración a aplicar en el cluster kubernetes está ubicada en el repostiorio git gestionado por sistemas gitops-k8s-infraMNCS helm-charts.
Para poder gestionar la configuración en los diferentes entornos deberemos hacer una copia del los repositorios de configuración e ir haciendo merge request a sistemas para que la acepten y la apliquen. A continuación describimos los pasos a seguir para poder gestionar esta configuración.
...
Lo primero que deberemos hacer para desplegar nuestros proyectos en la infraestructura será hacer un fork a nuestro espacio del proyecto https://gitlab.um.escom/umugit/atica/desarrollo/mncs/helm-charts si no lo hemos hecho ya, para ello tendremos que poner un Jira a MNCS indicando el espacio donde deberá hacerse el fork (típicamente el nombre de nuestro grupo de trabajo).
...
Una vez realizado esto contaremos con un proyecto git en nuestro espacio de trabajo que se localizará con una URL de la siguiente forma https://gitlab.um.escom/umugit/atica/desarrollo/GRUPOTRABAJO/helm-charts/
A continuación procederemos a crear nuestro proyecto git en local clonándolo con el comando habitual
$ git clone https://gitlab.um.escom/umugit/atica/desarrollo/GRUPOTRABAJO/helm-charts/
...
$ git remote add upstream https://gitlab.um.escom/umugit/atica/desarrollo/mncs/helm-charts/
Actualizar fork del grupo
...
Mandamos los cambios a nuestro fork en remoto para evitar estar desincronizados y evitar conflictos. Si os falla puede que no tengáis permisos, pedidle a vuestro responsable el rol Maintainer en vuestro fork.
A partir de aquí trabajamos como habitualmente
...
solicitar merge request contra la rama mncs/master (es el destino por defecto al solicitar la merge)
poner un Jira a MNCS indicando la merge request y el componente HelmChart DJ-AT-MNCS (incluyendo la ruta de la MR en gitlab).
Por último es muy importante decir que tendrá que cambiarse la imagen del proyecto con el que estemos trabajando si queremos que la infraestructura coja los cambios que acabamos de introducir.