Cumplimiento normativo

Histórico de cambios

Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabezeras de la tablas dónde se indican las fechas de entrada en vigor y versión.

1. Normativa

Ciclo de trabajo

En el SAS el ciclo de trabajo está basada en Gitflow, aunque se definen algunos puntos para facilitar la integración con el Jira corporativo.

• No se permitirá por norma general hacer commits en master, develop o ramas support directamente, se deberán de usar las demás ramas dentro del flujo de Gitflow
• Cada feature debe asociarse con una tipología concreta de issue de Jira o, en su defecto, con una solicitud CGES. El nombre de dicha feature debe contener, en función de la metodología seguida por el proyecto, lo siguiente:
  • Proyectos Agile
    • Se crearan dos tipos de ramas de feature, una por cada "Mejora", y otra por cada "Historia de Usuario" de esa mejora.
    • Las ramas de "Historia de Usuario" se crearan y finalizaran sobre la rama de "Mejora" correspondiente.
    • Código Jira de la issue de tipo "Mejora", junto un breve texto descriptivo, en la que se basa la feature.
      • Por ejemplo "feature/{Codigo_Jira_Mejora}{_Descripcion}
    • Código Jira de la issue de tipo "Historia de Usuario", junto un breve texto descriptivo, en la que se basa la feature, con el prefijo de su "Mejora".
      • Por ejemplo "feature/{Codigo_Jira_Mejora}/{Codigo_Jira_HistoriaUsuario}{_Descripcion}
  • Proyectos Cascada
    • Código Jira de la issue de tipo "Mejora", junto un breve texto descriptivo, en la que se basa la feature.
      Por ejemplo "feature/{Codigo_Jira}{_Descripcion}
• En proyectos Agile todas las ramas features serán de mejora o de historia de usuario.
  • No se pueden cerrar historias de usuario hasta que se apruebe su DoD
  • Solo se cerrarán las mejoras cuando vayan a ser incluidas en la siguiente versión del aplicativo.
    • Ejemplo:
      
      
• Cada commit, incluido en una feature, debe incluir en su comentario el código Jira de la issue que corresponda de acuerdo a la metodología seguida por el proyecto (descritas en el punto anterior). En su defecto, se hará uso del número de solicitud CGES que corresponda.
• Cada commit, incluido en una release, debe incluir en su comentario lo siguiente:
  • Proyectos Agile
    • Código Jira de la issue de tipo "Version".
  • Proyectos Cascada
    • Código Jira de la issue de tipo "Version".
• Las ramas de release/hotfix deben de corresponder con la versión del aplicativo.
• Si el proveedor necesita marcar hitos sobre el desarrollo se realizaran tags con el formato (Version)-[RC|SP](Numero correlativo) que debera de etiquetarse en develop. ejemplos: 1.0.0-SP1, 1.0.0-RC1
• Cuando el proveedor marque un tag como RC (release candidate) y quiera crear la release final debera de iniciar una release de gitflow teniendo como origen el tag de la RC.
• Nunca tener  -SNAPSHOT en la rama master, support, release, o hotfix.
• Siempre tener -SNAPSHOT en el resto de ramas, cuando se vayan a subir los cambios al SAS.
• Tags: Solo se permiten 3 tipos de tags
  • Tags de version, formato x.x.x.x
  • Tags de Sprint, formato x.x.x-SPx Estos tags se usaran para marcar los fines de spring del desarrollo exclusivamente 
  • Tags de version candidata a lanzamiento, formato x.x.x-RCx Estos tags se usaran exclusivamente para marcar hitos internos para realizar pruebas en desarrollo, nunca para realizar entregas para Pre o Pro, ya que estas entregas se deberan de realizar mediante el flujo de gitflow
• Deben de existir todos los tags correspondientes a todas las versiones del aplicativo.
• Ramas: solo se permiten 3 tipos de ramas
  • Rama master (Obligatoria)
  • Rama develop (Obligatoria)
  • Ramas support/*
• Ramas Support:
  • Deben de seguir la siguiente nomenclatura: X.Z.Y (Y podria ser opcional)
  • La nomenclatura de releases y hotfix no variara aunque esta parta de una rama support
  • Siempre deben de partir del ultimo tag de la version concreta especificada
  • Se considera como si fuera una rama paralela a develop por lo que se deben de aplicar features, releases,y hotfix sobre ella como si fuera la rama develop
• No aplicar fast-forward en "merges" (git config --global gitflow.feature.finish.no-ff TRUE)

Entregas

Prerequisitos:

• Se debe estar en la red corporativa.
• Se debe de tener acceso al repositorio del SAS.
• El usuario que se use para la entrega tiene que tener los permisos correspondientes en el repositorio.

El flujo para realizar las entregas en el repositorio del SAS es el siguiente:

1. El usuario realizara una copia local del repositorio de desarrollo con la opcion --mirror
   • git clone --mirror {url del repositorio de desarrollo}
   • Si ya se tenia anteriormente creada, para actualizarla se usara:
     • git remote update
2. Se añadira el repositorio del sas al repositorio local.
   • git remote add sas http://git.sas.junta-andalucia.es/...
3. Se subiran las siguientes ramas:
   • git push sas {rama}
     • master
     • develop
     • support/*
   • Solo se subiran las ramas descritas anteriormente.
4. Se subiran todos los tags
   • git push --tags sas

Se adjunta un script que permite realizar todos estos pasos automaticamente, indicando el repositorio de origen y el de destino, o desde un repositorio local existente solo indicando el destino.

• Linux

Criterios a Valorar en una Entrega de Versión

Cuando se realice la entrega de una nueva versión en GIT, los criterios que deberá cumplir la entrega por parte del proveedor deberán ser:

1. Uso de GIT FLOW y especificaciones indicadas en la normativa vigente.
   • Fusiones de ramas FEATURE en la rama DEVELOP.
   • Fusión de la rama RELEASE en la rama MASTER, creación del TAG correspondiente y fusión en la rama DEVELOP.
2. La rama MASTER estará como máximo al mismo nivel que la rama DEVELOP, nunca la rama MASTER podrá estar por encima de la rama DEVELOP. En todo caso la rama DEVELOP sí que podrá estar por encima de la rama MASTER, dado su carácter de rama de trabajo. Esto podrá observarse en el gráfico del proyecto en GIT.
3. Cuando se realice una entrega de una nueva versión, deberá existir el TAG (desde la rama MASTER) correspondiente a dicha versión.

Configuración en el equipo

Git for Windows: https://git-scm.com/download/win

Git for Windows ya incluye todos los comandos necesarios para trabajar con el workflow de GitFlow desde la versión 2.5.3.

Establecer la opción feature.finish.no-ff a true, lo que permitirá que gitflow cree un commit nuevo cada vez que se realice un merge independientemente de si se puede o no aplicar fast-forward. Esto facilita la revisión del histórico, y agiliza tareas de mantenimiento que requieran excluir features completas.

Para activar el parámetro no-ff basta con ejecutar el siguiente comando por consola y se aplicaría a todos los proyectos:

git config --global gitflow.feature.finish.no-ff TRUE

Si se trabaja con proxys será necesario realizar configuración adicional creando las variables de entorno "HTTP_PROXY" y "HTTPS_PROXY", también se podrán excluir direcciones con la variable global NO_PROXY

2. Git

Git fue creado pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente, es decir Git nos proporciona las herramientas para desarrollar un trabajo en equipo de manera inteligente y rápida.

Algunas de las características más importantes de Git son:

• Rapidez en la gestión de ramas.
• Gestión distribuida.
• Gestión eficiente de proyectos grandes.
• Realmacenamiento periódico en paquetes.

2.1 Ordenes básicas

Iniciar un repositorio vacío en la carpeta actual.

Añadir un archivo especifico.

Añadir todos los archivos del directorio act

Confirmar los cambios realizados. El "mensaje" generalmente se usa para asociar al commit una breve descripción de los cambios realizados.

Revertir el commit identificado por un hash.

Subir una rama(branch) al servidor remoto.

Mostrar el estado actual de la rama(branch).

3. SVN vs GIT

La principal diferencia con Subversion es que éste es un Sistema Centralizado mientras que GIT es un sistema Distribuido:

Subversion = Sistema centralizado

En estos sistemas hay un servidor que mantiene el repositorio y en el que cada programador mantiene en local únicamente aquellos archivos con los que está trabajando en un momento dado. Se necesita conectarse al servidor para poder enviar los cambios realizados. Es un sistema donde todo el código del proyecto esta en el servidor únicamente.

GIT = Sistema distribuido

En este tipo de sistemas cada uno de los integrantes del equipo mantiene una copia local del repositorio completo. Al disponer de un repositorio local, se pueden hacer commit (enviar cambios al sistema de control de versiones) en local, sin necesidad de estar conectado a Internet o cualquier otra red. En el momento que lo quieras compartir con los demás integrantes del equipo se realiza el registro a nivel de servidor.

Migracion SVN --> GIT

La migración de los repositorios actuales que se encuentran en el SVN se realizara de forma progresiva e individualizada por producto a lo largo del tiempo.

Diferencias

En el día a día, el desarrollador trabaja sobre la copia de trabajo en un ciclo de editar ficheros, actualizar la copia con las modificaciones realizadas por otros desarrolladores, y enviar sus modificaciones al repositorio.

En subversion, esto se realiza con los comandos:

El flujo de información y los comandos asociados en svn se pueden representar como:

Los comandos equivalentes en git son:

y su representación gráfica es:

Como vemos, en el ordenador local existen tres elementos: los ficheros con los que se está trabajando, una "staging area" y un repositorio local, mientras que en svn sólo existen dos, los ficheros con los que se está trabajando, y la "working copy".

Por otra parte, en git lo normal es que existan varios repositorios remotos, y habitualmente uno de ellos es el repositorio compartido en el que se consolidan los cambios realizados por un grupo de desarrolladores. Por lo tanto, para enviar unas modificaciones realizadas localmente al repositorio compartido, en git hay que realizar más pasos que en svn: llevar la modificación a la "staging area" (con un comando add, mv o rm), desde allí al repositorio local (con un comando commit), y desde el repositorio local al repositorio remoto. (con un comando push). Por comodidad, los dos primeros pasos se pueden ejecutar con un sólo comando "commit -a".

Para actualizar la copia local con los cambios realizados en el repositorio remoto, en svn se ejecuta el comando "update". En git, primero hay que actualizar el repositorio local con un comando "fetch", y después actualizar la staging area y los ficheros de trabajo con el comando "merge". Por comodidad, los dos pasos se pueden ejecutar con un único comando "pull".

Añadir, eliminar y cambiar de nombre ficheros

En ocasiones, se deben añadir ficheros para que queden bajo el sistema de control de versiones, o bien eliminar ficheros que ya no son necesarios. Esto se realiza de una manera muy similar en ambos casos.

En svn:

En git:

Deshacer los cambios realizados

Para deshacer las modificaciones realizadas en un fichero, basta con ejecutar el comando revert:

En git, el equivalente a "svn revert fichero" es:

Crear un repositorio

En git, para crear un repositorio basta con ejecutar el comando "git init" en el directorio en donde va a estar la copia de trabajo:

Esto crea e inicializa el subdirectorio ".git". A continuación, se pueden comenzar a ejecutar comandos "git add", "git commit -a", etc.¿

Establecer la identificación de usuario

En git, cada commit se guarda junto con el nombre y el email del usuario que lo realizó. Para establecer un valor de estos parámetros para todos los repositorios, se utilizan los comandos:

Para comprobar el valor asignado, se utilizan los mismos comandos sin especificar un nuevo valor. Ejemplo:

Para cada repositorio, se puede configurar un valor distinto para estos parámetros, utilizando los comandos sin el modificador "¿global" Crear una copia local de un repositorio remoto En svn, se obtiene una copia de un repositorio en el área de trabajo mediante un "checkout":

En git, se realiza una copia del repositorio con el comando "git clone":

4. GitFlow

Gitflow es uno de los muchos workflows que existen para trabajar con GIT. En el SAS se debe de usar este workflow por parte de los proveedores.

Cómo funciona

Gitflow utiliza un repositorio central como centro de comunicación para los diferentes desarrolladores. Su punto fuerte es la estructura de ramas (branches) que posee para controlar la evolución del proyecto.

Gitflow se caracteriza por el uso de cuatro tipos de ramas diferentes:

• Historical Branches
• Feature Branches
• Release Branches
• Maintenance Branches

CheatSheet: https://danielkummer.github.io/git-flow-cheatsheet/index.es_ES.html

Historical Branches

En lugar de trabajar todo desde la rama master, aquí se utilizan dos ramas para registrar el historial de proyecto:

• Master se registran los diferentes lanzamientos a nivel de producto,
• Develop se utiliza como rama de integración de los diferentes evolutivos a desarrollar.

Es recomendable etiquetar todos los commits en la rama master con un número de versión.

En resumen en la rama master no se desarrolla, solamente se registran los diferentes lanzamientos. Todas las integraciones se realizan desde la rama de Develop.

El resto de ramas trabajan alrededor de estas dos.

Feature Branches

Cada nueva funcionalidad debe residir en su propia rama, de esta forma en caso de existir problemas es muy rápido volver a versiones anteriores.

Las ramas de nuevas funcionalidades, features, siempre se crean a partir de la rama de develop. Una vez finalizado el desarrollo sobre la feature, se fusiona con la rama de develop , nunca con la rama master.

Release Branches

Una vez el evolutivo se ha finalizado y se acerca la fecha de lanzamiento se crea una rama para éste, release. Las ramas releases son utilizadas para marcar o etiquetar lanzamientos de producto, (evolutivos) y poder tener identificados de forma rápida los cambios de las diferentes releases.

A la rama release no se le pueden añadir nuevos evolutivos de ningún tipo, solamente la documentación asociada al lanzamiento de la release o errores puntuales.

Una vez se finalizan la rama release se tiene que fusionar tanto la rama master como la rama develop. Estas dos, siempre que realicemos una publicación, tienen que estar sincronizadas con el mismo contenido.

Maintenance Branches

La rama maintenance se utiliza cuando se detectan errores críticos de la aplicación.

La forma de trabajar sería crear una rama proveniente de la master, solventar el correctivo y fusionar con la rama master.

Maintenance es la única rama que interactúa directamente con la rama master, todas las demás siempre se trabaja desde la rama de desarrollo.

Una vez se ha solventado el correctivo se tiene también que fusionar con la rama develop, para que el correctivo se mantenga en los diferentes evolutivos.

 5. Procedimiento de trabajo en GIT con GIT FLOW

A continuación se describe el procedimiento de subida a GIT haciendo uso de GIT FLOW tal y como está indicado en la presente normativa. Para ello, el procedimiento será el siguiente:

1. En el entorno de desarrollo local del proveedor, deberá estar clonado el repositorio GIT remoto del SAS con la misma estructura de ramas obligatoria (DEVELOP y MASTER). Siendo la rama de trabajo siempre, la rama DEVELOP.
2. Se deberá iniciar GIT FLOW. Esta sentencia solo es necesario ejecutarla una vez en el repositorio local, mientras no se elimine y se cree un nuevo repositorio local.

git flow init

1. Para cada una de las funcionales a desarrollar, se deberá crear una rama FEATURE desde la rama DEVELOP con GIT FLOW. Esta rama FEATURE deberá seguir la nomenclatura especificada en la normativa vigente (Normativa)

git flow feature start "MYFEATURE"

1. Cuando se finalice el trabajo con la rama FEATURE que corresponda, se procederá a finalizar la rama con GIT FLOW. La finalización de dicha rama con GIT FLOW, realizará automáticamente lo siguiente:
   • Fusionar la rama FEATURE en cuestión con la rama DEVELOP.
   • Borrar la rama FEATURE en cuestión.
   • Cambiar a rama DEVELOP como rama de trabajo actual.

git flow feature finish "MYFEATURE"

1. Una vez la rama DEVELOP esté actualizada con todas las FEATURES que corresponda a la versión que se va a entregar, se deberá crear con GIT FLOW una rama RELEASE siguiendo lo especificado en la normativa vigente (Normativa).

git flow release start "RELEASE"

1. La finalización con GIT FLOW de la rama RELEASE, realizará automáticamente lo siguiente:
   • Fusionar la rama RELEASE con la rama MASTER.
   • Crea el TAG de la versión que corresponda desde la rama MASTER.
   • Fusionar la rama RELEASE con la rama DEVELOP.
   • Borrar la rama RELEASE en cuestión.

git flow release finish "RELEASE"

1. Por último, es muy importante no olvidar subir todas las rmas (incluidos los TAG) al repositorio GIT remoto del SAS.

6. Gitlab

Como interfaz gráfica de Git, en la que apoyarse para gestionar los repositorios, disponemos de Gitlab en su versión Community Edition.

Desde el SAS se aplica una política de seguridad sobre los repositorios de GIT, con el objetivo de mantener su privacidad y que únicamente los miembros del equipo de proyecto tengan acceso al código fuente.

Los permisos sobre GIT tienen la siguiente configuración:

• Usuarios Master (administradores): Administradores. Tienen permiso de lectura , escritura en el repositorio y acceso total a todas las ramas.
• Usuarios Developer (RW): Tienen permiso de lectura , escritura en el repositorio y restricción rama master.
• Usuarios Guest (R): Tienen únicamente permisos de lectura en el repositorio.

Los permisos más usados serán los de Master y Guest, ya que el repositorio ubicado en el SAS no será usado directamente por los desarrolladores.

La solicitud de permisos se realizara por petición CGES a la OCA, de la misma manera que se realiza actualmente para el SVN

Integración Git - Jira

La plataforma Gitlab nos proporciona una integración sencilla para poder enlazar incidencias (Jira) y nuestro repositorio (Gitlab).

Referencia a nivel de comentarios

Gitlab puede detectar automáticamente enlaces a issues de JIRA. Para ello, sólo tendremos que añadir en los commits, los identificadores de las issues JIRA que deseemos.

De esta forma podremos acceder rápidamente a la issue para ver el detalle.

Ejemplo de comentario: "CHKI-1 Solventado el problema".

Mas información

https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow

http://nvie.com/posts/a-successful-git-branching-model/

https://about.gitlab.com/2014/09/29/gitlab-flow/

7. Recomendaciones

Para un correcto uso de GIT recomendamos:

• Realizar los commits necesarios siempre en el intervalo de los diferentes evolutivos.
• Comentar correctamente los diferentes commits indicando a alto nivel las modificaciones realizadas.
• Nunca trabajar en la rama master, se recomienda utilizar ramas para diferentes evolutivos
• Almacenar sólo el código y no otro tipo de documentos o entregables.
• Desarrollar siguiendo los estándares de codificación (code clean).
• Ejecutar pruebas unitarias antes de realizar los commits.
• Usar un flujo de trabajo, por ejemplo gitflow