Historial de página

...

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

Image Modified

Si ejecutamos el comando

...

Hacemos login en la aplicación

Realizando una solictud de merge

Image Modified

Buscamos nuestro proyecto

Image Modified

Buscamos la opción para generar una merge requestImage Removedreques

Image Added

Nos preguntará qué 2 ramas queremos unir, en nuestro caso elegiremos la rama que acabamos de terminar y desarrolloImage Removed

Image Added

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íaImage Removed

Image Added

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íImage Removed

...

Image Added

Configurando ramas

El usuario administrador tendrá que ir al apartado Settings y desplegar la opción de Protected branches

...

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.

Image RemovedImage Added

Configurando el pipeline

Primero creamos el directorio .m2 con el fichero settings.xml con la configuración maven de nuestro proyecto, típicamente:

<?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

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'

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 grupoImage RemovedImage Added

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

Image RemovedImage Added

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í.

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

Image Added

Etiquetas

# 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

---
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 → PipelinesImage Removed

Image Added

A continuación elegimos la rama en la que queremos que se ejecute y lo ejecutamosImage Removed

Image Added

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

Image Added

Image RemovedEn el nombre de la rama ponemos redeploy_desarrollo, redeploy_preproduccion o redeploy_produccion, en la rama de origen podemos poner la del entorno que queremos redesplegar.

...

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.

Image RemovedImage Added

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í

Image RemovedImage Added

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

...