...
Advertencia |
---|
Para dar de alta un proyecto en gitlab y que esté incluido en el sistema de despliegue hay que poner un jira a la aplicación dj-at-mncs |
Advertencia |
---|
Si tienes que migrar desde GitLab.UM a GitLab.COM aplica la guía Migración a gitlab.com |
Repositorio remoto vs repositorio local
...
y obtendremos una copia en local del repositorio remoto
Podremos descargar localmente sólo la rama que necesitamos usando el modificador
-b NOMBRERAMA
...
O visto cómo quedaría usando el GIT BASH
Podemos ver que a la derecha del todo entre paréntesis nos marca la rama en la que estamos trabajando
A continuación tenemos que crear nuestra rama de trabajo, podrá tener el nombre que queramos pero normalmente usaremos la notación jira-XXX
siendo XXX el identificador de jira asociado a la tarea que estamos realizando. (Si queremos que nuestras Merge Request lancen los pipelines de desarrollo, las ramas deberán cumplir el formato anterior).
...
Eso no quita para que nuestro proyecto en remoto siga teniendo actualizaciones, así que avanzaríamos en paralelo sin molestarnos
Como podemos ver aquí nada de nuestro trabajo está en los repositorios remotos aún, por lo que si algo le sucede a nuestro equipo o por un descuido borramos los datos, podremos perder todo nuestro trabajo
...
Bloque de código |
---|
$ git push origin jira-XXX |
Advertencia |
---|
Es importante que la rama sobre la que vayamos a hacer push sea la que estamos trabajando |
Los repositorios quedarían así, con una bifurcación en el código en el punto que creamos la rama
...
Bloque de código |
---|
$ git merge desarrollo |
Es importante decir que este merge se realizará en local, para producir cambios en las ramas principales (master, preproduccion y desarrollo) se hará uso de las merge request de gitlab
...
Y el repositorio quedaría así
Por último recomendamos hacer también merge desde desarrollo porque al empezar la siguiente tarea sacaremos la rama nueva jira-XXX desde esta rama y así estará actualizada antes de aceptar la merge request en el servidor
...
En ocasiones al hacer el merge de una rama con otra aparecen conflictos (al estilo de SVN o de cualquier otro sistema de control de versiones) y nos vemos obligados a resolverlos para poder integrarlo
Si ejecutamos el comando
...
Bloque de código |
---|
$ git add . $ git commit -m "Resuelto el conflicto de merges" |
Conflictos con uno mismo
En ocasiones GIT detecta 2 commits hacia el mismo fichero y a la hora de hacer un push de la rama nos puede dar problemas
...
Bloque de código |
---|
~/portalfundeweb (jira-XXX|REBASE 2/2) $ git rebase --continue .m2/settings.xml: needs merge You must edit all merge conflicts and then mark them as resolved using git add ~/portalfundeweb (jira-XXX|REBASE 2/2) $ git add . ~/git-pipeline/portalfundeweb (jira-XXX|REBASE 2/2) $ git rebase --continue Applying: arreglamos el problema con el settings ~/git-pipeline/portalfundeweb (jira-XXX) $ git push origin jira-IDI-132 Counting objects: 8, done. Delta compression using up to 4 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (8/8), 1.02 KiB | 0 bytes/s, done. Total 8 (delta 4), reused 0 (delta 0) remote: remote: To create a merge request for jira-IDI-132, visit: remote: https://gitlab.um.es/mncs/portalfundeweb/merge_requests/new?merge_request%5Bsource_branch%5D=jira-XXX remote: To https://gitlab.um.es/mncs/portalfundeweb.git aee3109..f09c0f7 jira-XXX -> jira-IDI-XXX |
Uso del fichero .gitignore
Hasta ahora habíamos indicado que se podían preparar los ficheros para el commit con un comando de la forma
Bloque de código |
---|
$ git add . |
Lo cual deja preparado para hacer commit a todos los archivos alcanzables desde el directorio actual y subdirectorios.
Si sólo queremos mandar un fichero al commit deberíamos usar
Bloque de código |
---|
$ git add FICHERO |
Sin embargo ésta es una labor algo tediosa y propensa a equivocaciones y olvidos cuando tenemos muchos ficheros que queremos preparar y otros que no (el resultado de compilaciones, ficheros de log, etc…).
Para facilitarnos esto crearemos en la raíz del proyecto el fichero .gitignore
Bloque de código |
---|
$ vim .gitignore |
Y le añadiremos contenido
Bloque de código |
---|
.m2/repository/
web/target/
ear/target/
*.log
*_.java |
Donde las 3 primeras líneas ordenan a git que ignore los cambios en estos directorios y sucesivos, después tenemos *.log
que hace que se ignoren todos los ficheros *.log encuentren donde se encuentren en el proyecto, también podremos añadir reglas más complejas usando el modificador !
, por ejemplo podríamos tener
Bloque de código |
---|
*.log
!application.log |
Que haría que git ignorase todos los archivos .log
salvo el que se llame application.log
...
Hacemos login en la aplicación
Realizando una solictud de merge
Buscamos la opción para generar una merge requestreques
Nos preguntará qué 2 ramas queremos unir, en nuestro caso elegiremos la rama que acabamos de terminar y desarrollo
Por último rellenamos los datos de la merge request, podemos incluir más información para que a la hora de aceptar el merge y revisar el código se pueda usar de guía
Es buena idea marcar la casilla “Delete source branch when request is accepted” esto borrará la rama del repositorio cuando el merge se haga
Finalmente el repositorio quedará así
Rechazando una solicitud de merge
y evitará que se acumulen ramas que no se van a usar más. Siempre la conservamos en local y podremos volver a subirla si fuera necesario.
Finalmente el repositorio quedará así
Rechazar una merge
El primer paso es editar la merge
Añadimos el estado WIP y el motivo. Esto evitará que pueda hacerse merge de esta rama
Cuando el trabajo esté listo quitamos el prefijo WIP para que se pueda realizar el merge
Mientras no se quite el estado WIP la rama quedará así
Configurando ramas
El usuario administrador tendrá que ir al apartado Settings y desplegar la opción de Protected branches
...
En los desplegables seleccionaremos en Allowed to merge quien queremos que haga merge Mantainers o Developers + Mantainers y después en allowed to push dejaremos None
Info |
---|
Mantainer es un usuario con más responsabilidad que developer, se puede usar para que no todos los usuarios del grupo puedan hacer merge será típicamente un revisor de código. |
Configurando el pipeline
Primero creamos el directorio .m2 con el fichero settings.xml con la configuración maven de nuestro proyecto, típicamente:
Bloque de código |
---|
<?xml version="1.0" encoding="UTF-8"?> <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <localRepository>.m2/repository</localRepository> <offline>false</offline> <profiles> <profile> <id>FundeWeb-profile</id> <repositories> <repository> <id>archiva.atica.umu.es</id> <name>ATICA - UMU Repository</name> <url>https://archiva.um.es/archiva/repository/FundeWeb/</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>plugins.archiva.atica.umu.es</id> <name>ATICA - UMU Plugins Repository</name> <url>https://archiva.um.es/archiva/repository/FundeWeb/</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> |
...
</snapshots> </pluginRepository> </pluginRepositories> </profile> </profiles> <activeProfiles> <activeProfile>FundeWeb-profile</activeProfile> </ |
...
activeProfiles> <pluginGroups> <pluginGroup>com.oracle.weblogic</pluginGroup> </ |
...
pluginGroups> |
...
|
...
</settings> |
Generar el fichero .gitlab-ci.yml con el contenido
Bloque de código |
---|
variables:
PROJECT_NAME: NombreProyecto
SVN_BASE: https://svn.um.es/svn/NOMBREPROYECTO/
APP_CONTEXT: nombreproyecto
include:
- project: 'mncs/mncs-pipelines'
file: '.gitlab-ci-template.yml' |
o si estamos en gitlab.com
Bloque de código |
---|
...
variables:
PROJECT_NAME: NombreProyecto
SVN_BASE: https://svn.um.es/svn/NOMBREPROYECTO/
APP_CONTEXT: nombreproyecto
include:
- project: ' |
...
umugit/atica/desarrollo/common/mncs-pipelines' file: '.gitlab-ci-template.yml' |
Variables para el despliegue
Tendremos un usuario SVN por grupo de trabajo, además si usamos aplicaciones Fundeweb 2.1 tendremos que usar un perfil de compilación JDK8 todas estas cosas las especificaremos con variables dentro de GitLAB Dentro de la sección de grupo de GitLAB y por parte de un Owner del grupo
Le daremos al botón “Expand” y creamos las variables
SVN_USERNAME
SVN_PASSWORD
JDK_VERSION (opcional)
SUFIJO_DESPLIEGUE (opcional, con valor fm si se despliega en servidores fm)
PRESERVE_LIB (opcional, con valor true si queremos que se copien las librerías del package a los servidores, false por defecto). Para aplicaciones de servicios tiene que especificarse con valor true.
ORIGEN_BIRTUM (opcional, con valor por defecto informes_birtum/informes/${APP_CONTEXT}), es la ruta relativa de la raíz de git de donde tiene que sacar los informes BIRT
DESTINO_BIRTUM (opcional debe especificarse junto con el anterior, con valor por defecto informes_birtum), es la ruta relativa al SVN donde se copian los ficheros
LISTA_SECRETS (opcional) para no almacenar secretos en claro en el código, ni el repositorio, es una lista de nombres de secrets separado por espacios. Los secrets se inyectarán en el fichero de filtros según el entorno. Tendrán que especificarse variables nuevas en gitlab nombresecret_DESA, nombresecret_TEST, nombresecret_PROD siendo nombresecret el literal dado de alta en la variable LISTA_SECRETS
MODULO_FILTRO (opcional, valor por defecto web) el módulo al que se tienen que aplicar los secrets en los filtros
MAVEN_CUSTOM_PROFILE (opcional) si nuestra aplicación tiene perfiles personalizados de MAVEN que hay que activar
...
- OLD_FUNDEWEB (opcional) si nuestra aplicación es Fundeweb 1, se lo podemos indicar para ayudar a sonarqube a detectar las rutas. El valor debe ser true
Info |
---|
Las variables que se marquen como protegidas sólo serán accesibles desde ramas protegidas, por lo tanto el perfil de compilación no deberíamos tenerlo así. |
Advertencia |
---|
También se pueden crear variables a nivel de proyecto, si tenemos aplicaciones Fundeweb 2.0 y 2.1 en nuestro grupo lo recomendado es crear la variable de perfil de compilación a este nivel y no a nivel de grupo |
Gestión de releases
Etiquetas
Bloque de código |
---|
# etiqueta simple
git tag mi_etiqueta
# Etiqueta anotada
git tag -a v1.0 -m 'Version 1.0'
git tag
git push origin --tags |
Changelog
Por cada cambio que se quiera registrar hay que crear un fichero en la rama en la ruta changelogs/unreleased/XXX.yml con el contenido
Bloque de código |
---|
---
title: Mi título de changelog
merge_request: //opcional//
author: Pablo González de la Peña
type: added|fixed|changed|deprecated|removed|security|performance|other |
https://gitlab.um.es/help/user/project/releases/index#release-description
...
Vamos a CI/CD → Pipelines
A continuación elegimos la rama en la que queremos que se ejecute y lo ejecutamos
Esto ejecutará el ciclo de vida completo, aunque si no hay cambios en el código de la rama (que es lo normal), finalmente no subirá nada nuevo al servidor y sólo se hará el redeploy.
...
Vamos a Repository → Branches
redeploy_desarrollo, redeploy_preproduccion o redeploy_produccion, en la rama de origen podemos poner la del entorno que queremos redesplegar.
En el nombre de la rama ponemos...
Lo primero que tenemos que hacer es poner la variable AUTO_DEPLOY a false a nivel de proyecto según el siguiente pantallazo Settings → CI / CD , Expandir la zona de Variables y ponerle el valor false en minúsculas y sin espacios.
Esto hará que NINGÚN redespliegue se realice en producción hasta que se ejecute un pipeline de la rama master con la variable REDEPLOY a true.
Puede ser una ejecución programada como aquí
Advertencia |
---|
Ojo, que el formato de programación es el de la herramienta GNU cron, hay que tener cuidado con la sintaxis para no tener ejecuciones no deseadas |
O una ejecución normal o con la rama redeploy_produccion como se comenta en el apartado de redespliegues