Herramientas de usuario
ada:howto:sicoferp:factory:new-migracion-sicoferp:repository
Diferencias
Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anterior Revisión previa Próxima revisión | Revisión previa | ||
|
ada:howto:sicoferp:factory:new-migracion-sicoferp:repository [2024/04/17 12:53] 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. | * **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. | * **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. | * **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. | * **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. | * **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 | ||
| Línea 76: | Línea 108: | ||
| # | # | ||
| # For more information, see: https://docs.gitlab.com/ee/ci/yaml/index.html#stages | # 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 | stages: # List of stages for jobs, and their order of execution | ||
| - build | - build | ||
| Línea 85: | Línea 119: | ||
| stage: build | stage: build | ||
| script: | script: | ||
| - | - echo "Compiling the code..." | + | - echo "Compiling the code..." |
| + | - mvn clean package -Dsettings.security=none # Ajustar el comando para Gradle | ||
| - echo "Compile complete." | - echo "Compile complete." | ||
| unit-test-job: # This job runs in the test stage. | unit-test-job: # This job runs in the test stage. | ||
| - | stage: test # It only starts when the job in the build stage completes successfully. | + | stage: test # Etapa opcional para pruebas unitarias |
| script: | script: | ||
| - | - echo "Running unit tests... This will take about 60 seconds." | + | - echo "Running unit tests..." |
| - | - sleep 60 | + | - mvn test |
| - | - echo "Code coverage is 90%" | + | - echo "Test Complete" |
| - | + | ||
| - | lint-test-job: # This job also runs in the test stage. | + | |
| - | stage: test # It can run at the same time as unit-test-job (in parallel). | + | |
| - | script: | + | |
| - | - echo "Linting code... This will take about 10 seconds." | + | |
| - | - sleep 10 | + | |
| - | - echo "No lint issues found." | + | |
| deploy-job: # This job runs in the deploy stage. | deploy-job: # This job runs in the deploy stage. | ||
| - | stage: deploy # It only runs when *both* jobs in the test stage complete successfully. | + | stage: deploy # Etapa opcional para implementación (reemplazar con su estrategia de implementación) |
| script: | script: | ||
| - echo "Deploying application..." | - 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." | - echo "Application successfully deployed." | ||
| </code> | </code> | ||
| + | |||
| + | [[ada:howto:sicoferp:factory:new-migracion-sicoferp:front:flujogit|Flujo Git]] | ||
| Línea 115: | Línea 146: | ||
| - | [[ada:howto:sicoferp:factory|←Volver atrás]] | + | [[ada:howto:sicoferp:factory:new-migracion-sicoferp|←Volver atrás]] |
ada/howto/sicoferp/factory/new-migracion-sicoferp/repository.1713358410.txt.gz · Última modificación: 2024/04/17 12:53 por 192.168.177.32
Herramientas de la página
