Tabla de contenidos |
---|
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 |
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.
...
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).
Trabajar y completar la tarea.
Comprobar que no exista nada nuevo en desarrollo a incorporar en la rama de trabajo a través de la operación rebase.
Solucionar los conflictos de código surgidos en el punto anterior y actualizar los cambios en la rama de trabajo.
Generar una Merge Request a la rama de desarrollo
El equipo realiza una revisión del código y envía mensajes al desarrollador en el caso de que surja algún comentario.
Si hay algo que corregir, volver al punto 2.
Si está todo correcto, la persona con el rol de Merger aceptará los cambios y los integrará en la rama de desarrollo
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:
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.
...