En el mundo del desarrollo de software, la gestión eficaz del código fuente es crucial para el éxito de cualquier proyecto. Un repositorio de código fuente centralizado proporciona un lugar seguro para almacenar, organizar y colaborar en el desarrollo del código. Gitlab, una plataforma de gestión de repositorios Git líder, ofrece una amplia gama de funciones para facilitar la colaboración y el control de versiones del código.

En esta sección, se presenta la definición de un repositorio de código fuente para la empresa ADA, utilizando Gitlab y el flujo de trabajo Gitflow.

Gitlab se ha convertido en la plataforma de gestión de repositorios Git preferida por muchas empresas debido a su conjunto completo de funciones, escalabilidad y facilidad de uso. Ofrece una interfaz web intuitiva, herramientas integradas para la gestión de tareas, seguimiento de errores y CI/CD (Integración Continua y Entrega Continua).

El flujo de trabajo Gitflow es un modelo de ramificación ampliamente utilizado para organizar el desarrollo de software en Git. Proporciona una estructura clara para crear, fusionar y eliminar ramas, asegurando que los cambios de código estén bien definidos y sean rastreables.

La implementación de un repositorio de código fuente en Gitlab con el flujo de trabajo Gitflow para la empresa ADA ofrece numerosos beneficios:

• Gestión Centralizada del Código: Un único repositorio centralizado almacena todo el código fuente del proyecto, facilitando el acceso y la colaboración entre los desarrolladores.
• Control de Versiones Eficaz: Gitlab proporciona un historial completo de todos los cambios realizados en el código, permitiendo a los desarrolladores retroceder a versiones anteriores si es necesario.
• Flujo de Trabajo Estructurado: El flujo de trabajo Gitflow guía a los desarrolladores en el proceso de desarrollo, asegurando que los cambios se realicen de manera organizada y eficiente.
• Mejora de la Colaboración: Gitlab facilita la colaboración entre desarrolladores, permitiendo la revisión y aprobación del código antes de su fusión en la rama principal.
• Mayor Visibilidad y Transparencia: El repositorio centralizado proporciona una visión clara del estado del proyecto y el progreso del desarrollo a todos los interesados.
• Integración con CI/CD: Gitlab se integra perfectamente con herramientas de CI/CD, permitiendo la automatización de pruebas, implementación y despliegue del código.

El flujo de trabajo Gitflow es un modelo de ramificación que ayuda a los equipos a gestionar el desarrollo y la colaboración de código de manera eficaz. Proporciona un enfoque estructurado para crear, fusionar y eliminar ramas, asegurando que los cambios de código estén bien definidos y sean rastreables.

A continuación se describen los elementos que hacen parte de ese flujo y como se utilizará en la compañía siguiendo el estandar recomendado. Según el siguiente gráfico:

El flujo de trabajo Gitflow utiliza varias ramas para organizar y gestionar el desarrollo del código:

• master: La rama principal que representa la versión estable y lanzada del código. Esta rama solo debe actualizarse con cambios de código probados y aprobados.
• develop: La rama donde se lleva a cabo el desarrollo activo. Las características se ramifican desde aquí y eventualmente se fusionan de nuevo en esta rama una vez que se completan y se prueban a fondo.
• feature: Ramas creadas desde develop para trabajar en características específicas o correcciones de errores. Estas ramas deben tener nombres descriptivos que indiquen claramente el propósito del trabajo que se está realizando.
• release: Una rama creada desde develop para preparar una nueva versión. Esta rama se utiliza para probar y finalizar la versión antes de fusionarla en master.
• hotfix: Una rama creada directamente desde master para abordar errores o problemas críticos en el código lanzado. Estas ramas deben crearse y fusionarse lo antes posible para minimizar el impacto del problema en los usuarios.

La empresa por varios años ha utilizado un repositorio svn para la gestión del código fuente de los desarrollos. Teniendo presente ese enfoque, el personal actual y el flujo de los procesos actuales de implementación de cambios, mejoras o nuevos desarrollos se hace esta definición de ramas en la nueva migración.

• 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 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. 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.

El flujo de trabajo Gitflow define roles y responsabilidades para los miembros del equipo:

• 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.
• 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.
• 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.

Al igual que las ramas del repositorio anterior, la empresa por varios años ha utilizado una estructura simple de gestion de ramas la cual es branches para desarrolladores, trunk para qa y tags para liberaciones en produccion. Teniendo presente ese enfoque, el personal actual y el flujo de los procesos actuales de implementación de cambios, mejoras o nuevos desarrollos se hace esta definición de roles en la nueva migración.

• 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 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.

# 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

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..."
    - echo "Compile complete."

unit-test-job:   # This job runs in the test stage.
  stage: test    # It only starts when the job in the build stage completes successfully.
  script:
    - echo "Running unit tests... This will take about 60 seconds."
    - sleep 60
    - echo "Code coverage is 90%"

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.
  stage: deploy  # It only runs when *both* jobs in the test stage complete successfully.
  script:
    - echo "Deploying application..."
    - echo "Application successfully deployed."

La adopción de Gitlab como plataforma de gestión de repositorios Git y el flujo de trabajo Gitflow para la empresa ADA proporcionará una base sólida para el desarrollo de software eficiente, colaborativo y escalable. Esta combinación permitirá a ADA gestionar su código fuente de manera efectiva, mejorar la colaboración entre equipos y acelerar el desarrollo de productos.

←Volver atrás