Merge branch 'esuarez/lib-789' into 'master'

Update code versioning practices

See merge request !9

docs/development-rules/sections/code-versioning.md

@@ -35,7 +35,6 @@ Condiciones en los commits:
 
 * Cada commit debe ser funcional. Es decir, al hacer checkout a un commit específico la aplicación debe funcionar sin errores de código.
 * Dejar al final, o incluso en una rama aparte optimizaciones y otros ajustes que se encuentren necesarios durante el desarrollo de la tarea.
-* Cuando se genera la documentación en el mismo repositorio, por ejemplo con *APIDoc*, se debe generar en una rama aparte, cuyo *PR* irá a la rama principal de la tarea.
 * Deben ser escritos de tal forma que complementen la frase: *If applied, this commit will*…
 * Cuando un mensaje sea muy grande, debe dividirse en varias líneas y la primera debe ser el “asunto” del commit, debe separarse por una línea en blanco del resto del commit, y el resto del commit puede ser una descripción o una lista de puntos para explicar más detalles.
 
@@ -48,14 +47,15 @@ Condiciones en los commits:
 * Al crear un *PR*, se debe seleccionar la rama que se trabajó el destino dependerá del tipo de desarrollo que se esté realizando (*feature*, *release* o *hotfix*). Recuerde que el orden de estas ramas está invertido en GitLab (para los *MR*)
 * En caso de haber conflictos, el desarrollador que crea el *PR* debe resolverlos.
 * Siempre se deben asignar revisores al *PR*.
-* Al crear un PR/MR en la sección *Associated issues* de la plantilla debe enlazar la tarea correspondiente usando las palabras mágicas (nunca a través del título). Puede ver las instrucciones para [GitLab](https://linear.app/docs/gitlab#use-a-magic-word) y para [GitHub](https://linear.app/docs/github#link-through-pull-requests)
+* Al crear un PR/MR en la sección *Associated issues* de la plantilla se debe enlazar la tarea correspondiente usando las palabras mágicas (nunca a través del título). Puede ver las instrucciones para [GitLab](https://linear.app/docs/gitlab#use-a-magic-word) y para [GitHub](https://linear.app/docs/github#magic-words)
 
 #### Consideraciones
-En caso de haber más de 2 revisores en el *PR*, se debe tener en cuenta:
-
-* En casi todos los repositorios es suficiente con que uno lo apruebe. Pero la cantidad de aprobaciones necesarias es determinada por la sensibilidad de la tarea.
-* Si un revisor solicita cambios, esa misma persona debe aprobar después.
-* Más de un revisor puede solicitar cambios. Luego, se deberá tener la aprobación de todos los que hayan solicitado cambios.
+* En caso de haber más de 2 revisores en el *PR*, se debe tener en cuenta:
+  * En casi todos los repositorios es suficiente con que uno lo apruebe. Pero la cantidad de aprobaciones necesarias es determinada por la sensibilidad de la tarea.
+  * Si un revisor solicita cambios, esa misma persona debe aprobar después.
+  * Más de un revisor puede solicitar cambios. Luego, se deberá tener la aprobación de todos los que hayan solicitado cambios.
+* En el GitLab interno no se tiene plantilla para los MR, se debe copiar de alguno de los repositorios de GitHub
+* Para aprobar en el GitLab interno e debe reaccionar con pulgar arriba y se debe avisar con comentario en la tarea porque ese GitLab no envía correos
 
 ### Revisores
 
@@ -91,6 +91,7 @@ A continuación se presenta una guía del flujo de una rama tipo *feature*. AquÃ
 #### Rama *Release*
 
 A continuación se presenta una guía del flujo de una rama tipo *release*. Aquí se consideran tanto los pasos y recomendaciones para el encargado de hacer el lanzamiento, como para los revisores.
+> **Nota temporal importante**: El flujo presentado a continuación se ve modificado mientras se termina el cambio de modelo de las aplicaciones para funcionar con ambiente productivo en la nube. Ver los diagramas de [la rama temporal feature/aws-pipelines](#temporal-rama-featureaws-pipelines) para más información
 
 ![Manejo de ramas tipo "release"](/resources/diagrams/git-flow/branches-release.drawio.png)
 
@@ -102,6 +103,79 @@ A continuación se presenta una guía del flujo de una rama tipo *hotfix*. Aquí
 
 ![Manejo de ramas tipo "hotfix"](/resources/diagrams/git-flow/branches-hotfix.drawio.png)
 
+#### [Temporal] Rama feature/aws-pipelines
+
+Esta es una rama tempotal creada durante la migración de los ambientes de producción a la nube. Hasta que se estabilicen todas las plataformas en este nuevo modelo, se manejará esta rama como espejo de master, ya que los commits en esta rama son los que disparan los pipelines de despliegue en la nube.
+
+Una vez tengamos (Humboldt) el control sobre los piplenes, considero (Erika) que lo mejor es dispararlos con la creación de tags en la rama master.
+
+Por el momento este es el panorama de los despliegues.
+
+##### Si hay conflictos
+
+```mermaid
+---
+config:
+    theme: default
+    gitGraph:
+        mainBranchOrder: 1
+        rotateCommitLabel: true
+---
+gitGraph
+commit
+branch develop order:3
+checkout develop
+commit
+branch release/1.11.0 order:2
+checkout release/1.11.0
+commit
+checkout main
+branch feature/aws-pipelines order:0
+checkout feature/aws-pipelines
+commit
+checkout release/1.11.0
+merge main id:"conflictos-con-main"
+merge feature/aws-pipelines id:"conflictos-con-pipelines"
+checkout main
+merge release/1.11.0
+checkout feature/aws-pipelines
+merge release/1.11.0 tag:"dispara-deploy"
+checkout release/1.11.0
+merge develop id:"conflictos-con-develop"
+checkout develop
+merge release/1.11.0
+```
+##### Si no hay conflictos
+
+```mermaid
+---
+config:
+    theme: default
+    gitGraph:
+        mainBranchOrder: 1
+        rotateCommitLabel: true
+---
+gitGraph
+commit
+branch develop order:3
+checkout develop
+commit
+branch release/1.11.0 order:2
+checkout release/1.11.0
+commit
+checkout main
+branch feature/aws-pipelines order:0
+checkout feature/aws-pipelines
+commit
+checkout main
+merge release/1.11.0
+checkout feature/aws-pipelines
+merge release/1.11.0 tag:"dispara-deploy"
+checkout release/1.11.0
+checkout develop
+merge release/1.11.0
+```
+
 ### Lanzamientos y etiquetas (Releases, tags)
 
 Al crear un lanzamiento, se debe tener en cuenta lo siguiente: