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

Image Removed

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.

git push origin "nombre rama"

Mostrar el estado actual de la rama(branch).

git status

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:

Image Removed

Los comandos equivalentes en git son:

y su representación gráfica es:

Image Removed

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:

$ svn add fichero1
$ svn delete fichero2
$ svn move fichero3 fichero4

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:

$ mkdir git_repo
$ cd git_repo
$ git init
Initialized empty Git repository in /home/usuario/git_repo/.git/

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":

svn checkout svn+ssh://usuario@servidor:/ruta/al/repositorio

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

$ git clone ssh://usuario@servidor/ruta/al/repositorio

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.

Image Removed

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.

Image Removed

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.

Image Removed

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.

Image Removed

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.

Image Removed

1. Introducción

El objeto de esta normativa, es la definición de las pautas necesarias a seguir para la entrega de código fuente y la correcta ejecución de los procesos de integración continua. Basándose en las mejores prácticas actualmente aplicadas en la industria, se definen pautas de obligado cumplimiento con el objeto de garantizar la homogeneidad, trazabilidad y correcto funcionamiento de todos los procesos previos a la liberación del software en entornos previos y productos.

La normativa se ha organizado en pautas que describen las reglas de verificación necesarias a cumplir en la entrega de código fuente.

Para más detalles sobre el modo de articular todas las pautas a continuación expuestas puede consultar la guía de ayuda a las entregas en la STIC.

1.1 Alcance

Esta normativa afecta a aquellos desarrollos corporativos que estén bajo el marco de gestión centralizada de la Dirección General de Sistemas de Información y Comunicaciones del SAS.

2. Listado de pautas