Diferencias

Muestra las diferencias entre dos versiones de la página.

--- ada:howto:sicoferp:factory:new-migracion-sicoferp:repository [2024/04/17 12:40]
192.168.177.32
+++ ada:howto:sicoferp:factory:new-migracion-sicoferp:repository [2024/08/08 20:46] (actual)
192.168.177.58
@@ Línea 40: / Línea 40: @@
   * **master**: Esta rama será la utilizada para almacenar el código fuente estable. Es similar a la rama tags del anterior modelo svn utilizado en la compañía para las aplicaciones powerbuilder.
-  * **develop**: En esta rama se realizarán las validaciones de parte del equipo de QA. Es similar a la rama trunk del anterior modelo svn utilizado en la compañía.
+  * **develop**: En esta rama se acumulan las validaciones de parte del equipo de QA para posteriormente liberar una versión. Es similar a la rama pre del anterior modelo svn utilizado en la compañía.
-  * **feature**: En esta rama se realizará la migración de las funcionalidades. Es similar a la rama branches del anterior modelo svn utilizado en la compañía.
+  * **feature**: En esta rama se realizará la migración de las funcionalidades. Es similar a la rama branches del anterior modelo svn utilizado en la compañía. Sin embargo tambien será utilizada para validar la solucion antes de integrarla a develop.
   * **release**: Esta rama será la utilizada para las liberaciones en el ambiente de producción. Es similar a la rama tags del anterior modelo svn utilizado en la compañía, pero su duración es corta ya que una vez se integren los cambios a master y develop será eliminada.
   * **hotfix**: Rama utilizada para solución de errores en producción es similar al branches del modelo anterior svn utilizado en la compañía pero su duración es corta ya que una vez se integren los cambios a master y develop será eliminada.
@@ Línea 56: / Línea 56: @@
   * **Mantenedores**: Responsables de gestionar la rama master, asegurando su estabilidad y calidad. Revisan las solicitudes de extracción de la rama release antes de fusionarlas en master. Este rol puede ser asumido por el líder técnico del módulo o caracteristica que se va a integrar.
-  * **Desarrolladores**: Trabajan en características y correcciones de errores, creando ramas de develop y fusionándolas de nuevo después de su finalización. Deben seguir los estándares de codificación y garantizar la calidad de su código. Este rol es el estadnar asignado a los desarrolladores que relaizarán la migración.
+  * **Desarrolladores**: Trabajan en características y correcciones de errores, creando ramas de develop y fusionándolas de nuevo después de su finalización. Deben seguir los estándares de codificación y garantizar la calidad de su código. Este rol es asignado a los desarrolladores que realizarán la migración.
   * **Testers**: Prueban los cambios de código en las ramas feature y release antes de fusionarlos en develop o master. Deben identificar y reportar cualquier error o problema encontrado durante las pruebas. Este rol es asumido por el equipo de QA.
+===== Procesos =====
+El flujo de trabajo Gitflow implica procesos específicos para gestionar los cambios de código:
+==== Consideraciones previas ====
+  * Antes de iniciar el flujo la rama develop debe estar sincornizada con la rama master.
+  * Todo nombre de repositorio debe estar escrito en minusculas y solo se permitirá el caracter '-' para separar nombres.
+==== Creación de una Rama Feature: ====
+  * a. Un desarrollador crea una nueva rama desde develop utilizando un nombre descriptivo, como feature/nueva-característica.
+  * b. El trabajo en la característica se realiza en esta rama. Los desarrolladores deben seguir los estándares de codificación y realizar pruebas unitarias de su código a medida que trabajan.
+==== Finalización de una Rama Feature: ====
+  * a. Una vez que la característica está completa, el desarrollador ejecuta pruebas para asegurarse de que funciona como se espera. Esto incluye tanto pruebas unitarias como pruebas de integración.
+  * b. Envía los cambios al repositorio remoto.
+  * c. Crea una solicitud de extracción para fusionar la rama feature en develop. La solicitud de extracción debe incluir una descripción clara de los cambios realizados y cualquier documentación o resultado de prueba relevante.
+==== Revisión y Fusión de una Rama Feature: ====
+  * a. Otros desarrolladores revisan la solicitud de extracción, asegurando la calidad del código y el cumplimiento de los estándares. Deben dejar comentarios y sugerencias según sea necesario.
+  * b. Si no se encuentran problemas, la solicitud de extracción se fusiona en develop.
+  * c. La rama feature se elimina una vez fusionada.
+==== Creación de una Rama Release: ====
+  * a. Una vez que un conjunto de características está listo para su lanzamiento, se crea una rama release desde develop. Esta rama debe etiquetarse con un número de versión, como v1.0.0.
+  * b. La rama release se actualiza con cualquier cambio o corrección de errores adicional que sea necesario para la versión.
+==== Prueba y Finalización del Release: ====
+  * a. La rama release se prueba a fondo para garantizar la estabilidad y la funcionalidad del release. Esto incluye pruebas manuales, pruebas automatizadas y pruebas de rendimiento.
+  * b. Se realizan las correcciones de errores necesarias y se fusionan en la rama release.
+  *
+==== Fusión de la Rama Release: ====
+  * a. Una vez finalizado el release, se fusiona en master. Esto solo debe hacerse después de que se complete toda la prueba
+===== Plantilla CI =====
+<code yaml>
+# This file is a template, and might need editing before it works on your project.
+# To contribute improvements to CI/CD templates, please follow the Development guide at:
+# https://docs.gitlab.com/ee/development/cicd/templates.html
+# This specific template is located at:
+# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Getting-Started.gitlab-ci.yml
+# This is a sample GitLab CI/CD configuration file that should run without any modifications.
+# It demonstrates a basic 3 stage CI/CD pipeline. Instead of real tests or scripts,
+# it uses echo commands to simulate the pipeline execution.
+#
+# A pipeline is composed of independent jobs that run scripts, grouped into stages.
+# Stages run in sequential order, but jobs within stages run in parallel.
+#
+# For more information, see: https://docs.gitlab.com/ee/ci/yaml/index.html#stages
+image: maven:3.9.6-amazoncorretto-21  # Ajustar la etiqueta de la imagen si es necesario
+variables:
+  MAVEN_CONFIG: 'settings.xml'
+stages:          # List of stages for jobs, and their order of execution
+  - build
+  - test
+  - deploy
+build-job:       # This job runs in the build stage, which runs first.
+  stage: build
+  script:
+    - echo "Compiling the code..."
+    - mvn clean package -Dsettings.security=none # Ajustar el comando para Gradle
+    - echo "Compile complete."
+unit-test-job:   # This job runs in the test stage.
+  stage: test    # Etapa opcional para pruebas unitarias
+  script:
+    - echo "Running unit tests..."
+    - mvn test
+    - echo "Test Complete"
+deploy-job:      # This job runs in the deploy stage.
+  stage: deploy  # Etapa opcional para implementación (reemplazar con su estrategia de implementación)
+  script:
+    - echo "Deploying application..."
+    - scp target/*.jar gestion@10.1.140.21:/opt/ada/deploy/cicd  # Reemplazar con sus detalles de implementación
+    - echo "Application successfully deployed."
+</code>
+[[ada:howto:sicoferp:factory:new-migracion-sicoferp:front:flujogit|Flujo Git]]
@@ Línea 64: / Línea 146: @@
-[[ada:howto:sicoferp:factory|←Volver atrás]]
+[[ada:howto:sicoferp:factory:new-migracion-sicoferp|←Volver atrás]]

Wiki

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página