Historial de página

...

Repositorio remoto vs repositorio local

...

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

...

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

...

$ git push origin jira-XXX

Los repositorios quedarían así, con una bifurcación en el código en el punto que creamos la rama

...

$ 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

Image RemovedImage Added

Si ejecutamos el comando

...

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

Configurando ramas

Rechazar una merge

El primer paso es editar la merge

Image Added

Añadimos el estado WIP y el motivo. Esto evitará que pueda hacerse merge de esta rama

Image Added

Cuando el trabajo esté listo quitamos el prefijo WIP para que se pueda realizar el merge

Image Added

Mientras no se quite el estado WIP la rama quedará así

Image Added

Configurando ramas

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

Aquí crearemos las ramas que necesitamos desarrollo y preproduccion.

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

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>

...

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

...

'

o si estamos en gitlab.com

variables:
  PROJECT_NAME: NombreProyecto
  SVN_BASE: https://svn.um.es/svn/NOMBREPROYECTO/
  APP_CONTEXT: nombreproyecto

 
include:
  - project: 'mncsumugit/atica/desarrollo/common/mncs-pipelines'
    file: '.gitlab-ci-template.yml'

...

• 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

Gestión de releases

Etiquetas

...

Puede ser una ejecución programada como aquí

O una ejecución normal o con la rama redeploy_produccion como se comenta en el apartado de redespliegues