Historial de página

Repositorio remoto vs repositorio local

La mayoría de las operaciones en Git sólo necesitan archivos y recursos locales para funcionar. Por lo general no se necesita información de ningún servidor así la mayoría de las operaciones son prácticamente instantáneas.

...

1. Crear una rama propia de la tarea que estemos atendiendo desde desarrollo respetando la nomenclatura definida (usualmente jira-XXX aunque se incorporarán más prefijos para artefactos que no sean código pero sí se incluyan en el proyecto).

2. Trabajar y completar la tarea.

3. Comprobar que no exista nada nuevo en desarrollo a incorporar en la rama de trabajo a través de la operación rebase.

4. Solucionar los conflictos de código surgidos en el punto anterior y actualizar los cambios en la rama de trabajo.

5. Generar una Merge Request a la rama de desarrollo

6. El equipo realiza una revisión del código y envía mensajes al desarrollador en el caso de que surja algún comentario.

7. Si hay algo que corregir, volver al punto 2.

8. Si está todo correcto, la persona con el rol de Merger aceptará los cambios y los integrará en la rama de desarrollo

9. Se harán merges request y sus correspondientes merges desde desarrollo a preproducción y de preproducción a master con los cambios que queramos ir incorporando.

Trabajando con GIT

Vamos a explicar unos comandos básicos que deberán cubrir la mayoría de las tareas de los programadores, para ello utilizaremos la interfaz de comandos, que se puede descargar para windows aquí https://gitforwindows.org

...

A la hora de ponernos a trabajar en un proyecto que use GIT, lo primero que deberemos hacer será obtener el código del repositorio remoto que tendrá un aspecto parecido a éste:

Image RemovedImage Added

Para ello introducimos localizamos la url de nuestro proyecto en https://gitlab.um.es y utilizamos el comando clone

...

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

$ git merge jira-XXX

Configurando el proyecto GIT

Cuando tengamos creado el repositorio GIT deberemos ir al directorio especial .git y abrir el fichero config el contenido típico deberá ser éste

...

[core]
        repositoryformatversion = 0
        filemode = false
        bare = false
        logallrefupdates = true
        symlinks = false
        ignorecase = true
        autocrlf = false
[remote "origin"]
        url = https://gitlab.um.es/mncs/portalfundeweb.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "desarrollo"]
        remote = origin
        merge = refs/heads/desarrollo

Resolución de conflictos

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

...

$ 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

...

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

...

Que haría que git ignorase todos los archivos .log salvo el que se llame application.log

Usando GITLab

Hasta ahora hemos visto cómo trabajar con GIT de manera independiente, ahora tenemos que llevar nuestro código al proyecto principal integrándolo con la rama de desarrollo.

...

Finalmente el repositorio quedará así

Rechazando una solicitud de merge

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.

Configurando el pipeline

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

...

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 grupo

...

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

# 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

...

https://gitlab.um.es/help/user/project/releases/index#release-description

Utilidades

Aquí explicamos algunas mecanismos que hemos desarrollado y que os pueden ayudar en vuestras tareas ordinarias de desarrollo

Redeploys manuales

Si por alguna razón queremos hacer un redeploy de un entorno pero no tenemos ningún cambio tenemos 2 opciones

...

Ojo, porque si ya lo hemos hecho antes, es decir la rama ya existe la tendréis que borrar o seguir los pasos del punto anterior pero usando la rama redeploy_XXX en lugar de la XXX

Pasos a producción programados

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.

...