Git, commits y branches

Repositorio de código (AgroSmart-Web)

Hasta el momento, el proyecto ha usado una versión menos estricta de Gitflow. Gitflow usa varios tipos de branches en un repositorio:

• La rama principal de desarrollo, generalmente develop pero en este proyecto es master por motivos de compatibilidad.
• La rama de despliegue o release, generalmente master pero en este proyecto deploy.
• "Feature Branches", donde se desarrollan nuevas funcionalidades. Se sugiere que el nombre comience con feature/???. Deben nacer de master (develop en Gitflow original). Cuando la funcionalidad esté completa, se abre un Pull Request contra master, se verifica que los tests pasen y se hace merge. Cuando el merge esté completo, se puede eliminar la rama de origin, como lo sugiere GitHub en cada PR cerrado.
• "Bugfix Branches", donde se resuelven bugs. Se tratan igual que las Feature Branches, pero el nombre debería ser bugfix/XYZ, donde XYZ es el número del Issue que describe el bug. Cuando el merge esté completo, se debe resolver manualmente el Issue. Alternativamente, se puede usar la funcionalidad de GitHub que cierra Issues automáticamente: si el mensaje de un commit o la descripción de un PR incluyen alguna de las palabras "close", "fix" o "resolve" seguidas del número de un Issue (por ejemplo, "Closes #121"), cuando se cierre el PR que incluye ese commit el Issue será resuelto automáticamente.

Repositorio raíz (AgroSmart-Top)

https://github.com/IS-AgroSmart/AgroSmart-Top incluye el código fuente, que está alojado en https://github.com/IS-AgroSmart/AgroSmart-Web, como un submódulo de Git. De esta forma, los cambios en el código fuente se pueden realizar de forma independiente. Cuando se desea integrar estos cambios en la aplicación, se actualiza el submódulo en el repositorio raíz, lo cual actualiza la versión del código fuente que se usa.

El uso de submódulos es similar a usar un paquete de Python, por ejemplo. La versión usada por la aplicación (AgroSmart-Top) se mantiene fija aunque se hagan nuevos commit al master de AgroSmart-Web. Cuando se necesiten las nuevas funcionalidades, se actualiza la versión de AgroSmart-Web a la que se hace referencia en AgroSmart-Top.

Para actualizar la versión de AgroSmart-Web usada en AgroSmart-Top, se hace git add app; git commit -m "Update submodule app" en ~/AgroSmart. Esto crea un nuevo commit que actualiza la versión del código a la que se hace referencia en la aplicación.

En la figura de arriba, los commits con mensaje "Updated submodule app" únicamente contienen una actualización del submódulo app, que apunta a https://github.com/IS-AgroSmart/AgroSmart-Web (por ejemplo, ver https://github.com/IS-AgroSmart/AgroSmart-Top/commit/149bf387342b85360fc6f3d990018e7e76a3ecde).

Los commits con mensaje "Merge branch 'master' into deploy" pertenecen a la rama deploy, e integran todos los cambios en la rama de despliegue, que es la rama activa en el servidor.

deploy vs. master

https://github.com/IS-AgroSmart/AgroSmart-Top tiene dos ramas principales: master y deploy. El contenido es el mismo, excepto:

• Los cambios en docker-compose.yml que son necesarios para agregar certificados HTTPS al servidor, y redirigir todo el tráfico a endpoints HTTPS
• Una modificación en la configuración de Prometheus (prometheus/prometheus.yml) para que acceda a las métricas de Traefik en el puerto 443 en vez del puerto 80

Esta es la comparación entre ambas ramas: sólo hay dos archivos diferentes (ver la pestaña "Files changed").

Para integrar los cambios de master en deploy, hay que hacer un merge de master a deploy. Nótese que este merge va en la dirección contraria a la mayoría de merges, que integran los cambios de una rama a master. Por lo tanto, los comandos necesarios son:

git checkout deploy
git merge master

La mayoría de merges no darán problemas. Si se han cambiado líneas de docker-compose.yml o prometheus/prometheus.yml y Git no consigue determinar los cambios necesarios para el merge, habrá un conflicto que deberá resolverse manualmente. Debe verificarse que el archivo docker-compose.yml en el commit resultante cumpla las siguientes condiciones:

• Los contenedores de Traefik, Geoserver, Vue, Django, NodeODM y Grafana deben incluir el label traefik.http.routers.???.entrypoints=websecure
• Los contenedores de Traefik, Geoserver, Vue, Django, NodeODM y Grafana deben incluir el label traefik.http.routers.???.rule=Host(`flysensorec.com`) && ??? (esto es, deben verificar que el host sea flysensorec.com, antes de las rutas propiamente dichas)
• El contenedor de Traefik debe incluir los flags de certificatesresolvers en el campo command:
• El contenedor de Traefik debe incluir los flags para crear el entrypoint websecure en el puerto 443, y para redirigir el entrypoint web a websecure.
• El contenedor de Traefik debe exponer el puerto 443 (línea - "443:443" en ports:)
• El contenedor de Traefik debe incluir un volumen - "./letsencrypt:/letsencrypt" en volumes: (esto expone la carpeta /letsencrypt del container al host y permite que la información del certificado SSL persista).

Además, el archivo prometheus/prometheus.yml en el commit resultante debe incluir las líneas scheme: https y targets: ['container-traefik'] en el job con job_name: 'traefik'.