| ... | ... | @@ -10,8 +10,8 @@ El objetivo de esta entrada es condensar en un solo documento, el flujo de traba |
|
|
|
* [¿Y en GitHub?](#y-en-github)
|
|
|
|
* [Dos gotas de agua](#dos-gotas-de-agua)
|
|
|
|
* [Versionado semántico de los roles](#versionado-sem%C3%A1ntico-de-los-roles)
|
|
|
|
* [Algunos trucos y recomendaciones](#algunos-trucos-y-recomendaciones)
|
|
|
|
* [Pasando en limpio](#pasando-en-limpio)
|
|
|
|
* [Algunos trucos y recomendaciones](#algunos-trucos-y-recomendaciones)
|
|
|
|
* [Fuentes y lecturas recomendadas](#fuentes-y-lecturas-recomendadas)
|
|
|
|
|
|
|
|
|
| ... | ... | @@ -100,9 +100,10 @@ Por tratarse de un proyecto que sigue las [buenas prácticas Ansible](https://do |
|
|
|
|
|
|
|
Varios de los roles utilizados, son precisamente de terceras partes, pero muchos otros son desarrollos propios. [Ansible brinda una plataforma](https://galaxy.ansible.com) para facilitar la publicación e intercambio de *roles*, que se integra con GitHub como repositorio de código.
|
|
|
|
|
|
|
|
Dado que nuestro objetivo es compartir todo lo posible, los desarrollos de *roles* propios, se encuentran versionados en [repositorios independietes de GitHub](https://github.com/UdelaRInterior) en lugar de el mismo que `config`; de modo que sea posible publicarlos en nuestro espacio en la [galaxia](https://galaxy.ansible.com/udelarinterior).
|
|
|
|
Dado que nuestro objetivo es compartir todo lo posible, los desarrollos de *roles* propios, se encuentran alojados en [repositorios independientes de GitHub](https://github.com/UdelaRInterior) en lugar de el mismo que `config`; de modo que sea posible publicarlos en nuestro espacio en la [galaxia](https://galaxy.ansible.com/udelarinterior). Al mismo tiempo mantenemos muchos *forks* de *roles*/repositorios de terceros, para contribuir en su desarrollo.
|
|
|
|
|
|
|
|
Los *roles* públicos se convertirán en dependencias de los proyectos de quienes los utilicen. Por ello será necesario sumar al flujo de ramas independientes, un [versionado correcto](versionado-de-roles) mediante el uso de *tags* Git, cuando los features/mejoras lleguen a *master*.
|
|
|
|
|
|
|
|
Al mismo tiempo mantenemos muchos *forks* de roles/repositorios de terceros, para contribuir en su desarrollo.
|
|
|
|
|
|
|
|
#### Dos gotas de agua
|
|
|
|
|
| ... | ... | @@ -114,14 +115,6 @@ En GitHub también tenemos a *issues*, *pull requests* (idénticos a los *merge |
|
|
|
|
|
|
|
Así como hay desventajas, también ventajas. En GitHub contamos con características muy útiles al momento de realizar revisiones y fusiones. En las solicitudes de fusión (*pull requests*), es posible asignar a un miembro específicamente para la revisión y otro para la fusión. Aquí las revisiones son un [feature completo](https://github.com/features/code-review/), con una dinámica más rica y guiada al momento de mantener discusiones sobre el código.
|
|
|
|
|
|
|
|
## Versionado semántico de los roles
|
|
|
|
|
|
|
|
El proyecto config es de administración de sistemas y de integración contínua, por lo cual no tiene mucho sentido gestionar un versionado. La rama master debe ser estable, reflejando lo mejor posible la realidad de nuestra infraestructura.
|
|
|
|
|
|
|
|
Los roles, al contrario, son unidades de código reutilzables y trabajadas en comunidad más allá de nuestro equipo. Por eso, y en en conformidad con los mecanismos y prácticas para los roles de la [Ansible Galaxy](https://galaxy.ansible.com), conviene que [gestionemos un versionamiento](home#protocolos-y-estándares-que-seguimos).
|
|
|
|
|
|
|
|
Semánticamente seguimos, valga la redundancia, las norma de Versionado Semántico o [SemVer](https://semver.org/lang/es/). Instrumentalmente y sintáxicamente seguimos [lo que propone git-scm](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Etiquetado) y que utiliza la Ansible Galaxy.
|
|
|
|
|
|
|
|
# Pasando en limpio
|
|
|
|
|
|
|
|
Expuestos ya los fundamentos, lo que importa que te lleves de aquí y mantengas siempre presente es:
|
| ... | ... | @@ -134,12 +127,12 @@ Expuestos ya los fundamentos, lo que importa que te lleves de aquí y mantengas |
|
|
|
|
|
|
|
# Algunos trucos y recomendaciones
|
|
|
|
|
|
|
|
* Al momento de abrir una incidencia, es importante pensar bien el título, sobretodo en GitLab en el cual éste será retomado en la rama y en la merge request
|
|
|
|
* Conviene siempre establecer múltiples enlaces cruzados, entre todas las acciones y referencias que están relacionadas. GitLab y GitHub establecen varios vínculos automáticamente, pero no todo, y en particular conviene enriquecer los vínculos entre el proyecto `config` en nuestro Gitlab y sur roles en GitHub (que no se harán automáticamente)
|
|
|
|
* existen muchas manera de generar fácilmente dichos enlaces, por ejemplo con *#<num_issue>* para las incidencias y *!<num_MR>* para las solicitudes de fusión en GitLab, o *#<num>* en GitHub, haciendo referencia a la numeración compartida de las *issues* y las *Pull Request* en GitHub. La mención de un tag de versión también genera un enlace automático
|
|
|
|
* Al momento de abrir una incidencia, es importante pensar bien el título, sobretodo en GitLab en el cual éste será retomado en la rama y en la m*erge request*
|
|
|
|
* Conviene siempre establecer múltiples enlaces cruzados, entre todas las acciones y referencias que están relacionadas. GitLab y GitHub establecen varios vínculos automáticamente, pero no todo, y en particular conviene enriquecer los vínculos entre el proyecto `config` en nuestro Gitlab y sus roles en GitHub (que no se harán automáticamente)
|
|
|
|
* Existen muchas manera de generar fácilmente dichos enlaces, por ejemplo con *#<num_issue>* para las incidencias y *!<num_MR>* para las solicitudes de fusión en GitLab, o *#<num>* en GitHub, haciendo referencia a la numeración compartida de las *issues* y las *Pull Request* en GitHub. La mención de un *tag* de versión también genera un enlace automático
|
|
|
|
* Estos enlaces pueden incluso fácilmente convertirse en comandos implícitos, por ejemplo con *Close #<num_issue>* o *Fix #<num_issue>* para provocar el cierre de la incidencia, MR o PR
|
|
|
|
* Dichos atajos funcionan incluso en los mensajes de commit, vinculando así commits con issues/PR/MR y versiones, y disparando eventuales modificaciones de estado
|
|
|
|
* Cuando realizamos un merge de una rama con otra, git abre un editor con una línea que explicita qué rama se fusiona en cual. Es importante *agregar* ahí una descripción de la operación de fusión que estamos realizando, porque sólo esa línea en el historial del grafo del repo git puede no quedar claro. Tomamos la convención de dejar tal cual la línea porpuesta por git, agregando abajo, en lista eventualmente, toda la información pertinente
|
|
|
|
* Dichos atajos funcionan incluso en los mensajes de *commit*, vinculando así *commits* con *issues/PR/MR* y versiones, y disparando eventuales modificaciones de estado
|
|
|
|
* Cuando realizamos un *merge* de una rama con otra, Git abre un editor con una línea que explicita qué rama se fusiona en cual. Es importante agregar ahí una descripción de la operación de fusión que estamos realizando, porque sólo esa línea en el historial del grafo del repo Git puede no quedar claro. Tomamos la convención de dejar tal cual la línea porpuesta por Git, agregando abajo, en lista eventualmente, toda la información pertinente
|
|
|
|
|
|
|
|
> #### Fuentes: (y lecturas recomendadas)
|
|
|
|
>* [Feature Branch Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow)
|
| ... | ... | |
| ... | ... | |
