Esta guía está ya obsoleta, la nueva guía a seguir es Despliegues y configuración de los entornos con HelmChart
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-infra.
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.
Trabajo con el repositorio gitops-k8s-infra
Lo primero que deberemos hacer para desplegar nuestros proyectos en la infraestructura será hacer un fork a nuestro espacio del proyecto https://gitlab.um.es/sistemas/gitops-k8s-infra/ 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.es/GRUPOTRABAJO/gitops-k8s-infra/
A continuación procederemos a crear nuestro proyecto git en local clonándolo con el comando habitual
$ git clone https://gitlab.um.es/GRUPOTRABAJO/gitops-k8s-infra/
Posteriormente configuraremos un segundo origen para el proyecto (recordemos que hemos hecho un fork y que deberemos hacer referencia al proyecto principal)
$ git remote add upstream https://gitlab.um.es/sistemas/gitops-k8s-infra/
Actualizar fork del grupo
Todos estos pasos se realizan la primera vez que configuramos el repositorio, a partir de aquí tendremos que seguir los siguientes pasos
$ git checkout master
Nos situamos en la rama master del proyecto
$ git pull upstream master --rebase
Actualizamos dicha rama master con la rama del remoto de sistemas, que es donde se almacena la configuración definitiva
$ git push origin master
Mandamos los cambios a nuestro fork en remoto para evitar estar desincronizados y evitar conflictos
A partir de aquí trabajamos como habitualmente
$ git checkout -b jira-XXXX
Realizamos los cambios que debamos realizar.
Habitualmente sólo deberemos alterar el contenido de los ficheros application.properties de cada uno de los entornos, dichos ficheros se encuentran típicamente en la ruta
deployments/DOMINIO/CONTEXTO/desa|test|prod
subir rama Jira a repositorio remoto
$ git push origin jira-XXXX
solicitar merge request contra la rama sistemas/master (es el destino por defecto al solicitar la merge)
poner un Jira a MIDWEB indicando la merge request y el componente Kubernetes

