Propuesta Ejecutiva - Plataforma de

Control de Versiones
Centro Financiero ADME
Eduardo Calderon - 1070372

 
  

Punto de partida 
 
● ADME es una entidad financiera, con miles de clientes y con proyección a crecimiento
● Poseen proyectos cascada, y tienen iniciativas de equipos ágiles
● Utilizan SVN actualmente. Preferirían conservarlo, pero están abiertos al cambio

Valoraciones principales 
●
Funcionalidad
● Costos
● Soporte de la plataforma
● Seguridad
● Curva de aprendizaje

Alternativas a comparar 
● Git 
● SVN 
● Mercurial 

VCS = Version Control System 

 
  

SVN 
Sistema de control de versiones centralizado, es decir, opera bajo el
modelo de tener un repositorio central, de donde desarrolladores
toman archivos, hacen actualizaciones y envían cambios.. Gratis y
open source, opera bajo la licencia apache.

Caracteristicas: 
 
● Modelo de repositorio cliente servidor
● Directorios versionados.
● Operaciones de copiar, pegar y mover también versionadas.
● Commits atómicos.
● Symbolic links versionados..
● Branching independiente del tamaño de los archivos.
● Otros features , como seguimiento de merges, autorización en base a rutas, bloqueo
de archivos, operaciones de servidor, etc.

Pros

● Tiene el beneficio de herramientas visuales como TortoiseSVN

● Soporte para carpetas vacías
● Buen soporte en windows en comparación a otros
● Fácil de configurar y administrar

Contras 

 
● Posee bugs en el nombramiento de archivos y carpetas
● Pocos comandos para manejo de repositorio
● Baja velocidad en comparación a otros
● Modelo de branching tedioso
● Requiere conexión con el main server en todo momento
● Poco amigable para proyectos open source

 
  

Git 
Control de versiones descentralizado creado en el 2005. Como no hay un
servidor centralizado, los conceptos originales de Git era hacerlo rápido,
distribuido, y que desafiaba las convenciones y prácticas utilizadas en CVS.
Fue desarrollado principalmente para desarrollar el kernel de Linux.

Caracteristicas 

● Open source
● Gran soporte para desarrollo no lineal.
● Modelo de repositorios distribuidos.
● Compatible con protocolos HTTP, SSH, FTP, etc.
● Eficiente en el manejo de proyectos pequeños y grandes
● Autenticación criptográfica

Pros 
● Rendimiento rápido y eficiente
● Multiplataforma
● Los cambios de codigo son facilmente seguidos.
● Fácilmente mantenible y robusto
● Excelente CLI
● Gran set de herramientas visuales

Contras 

● Varias maneras de hacer lo mismo, y puede resultar confuso

● Lista muy extensiva de comandos
● Curva de aprendizaje elevada

 
  

Mercurial  
Es un sistema de control de versiones distribuidos gratis. Fue originalmente
creado para competir contra Git en la gestión del kernel de Linux. Es uno de los
sistemas de control de versiones más utilizados en la industria

Características 

● Alto rendimiento y escalabilidad

● Capacidades de merging y branching avanzadas.
● 100% distribuido
● Maneja archivos de texto y binarios de manera robusta.
● Posee y se integra con interfaces web.

Pros 

 
● Rápido y poderoso
● Facil de aprender
● Ligero y portable.
● Conceptualmente simple

Contras 

● Todos sus adicionales deben ser escritos en python.

● Checkouts parciales no aprobados
● Puede ser problemático cuando se usa con extensiones.
 

 
  

Análisis de puntos claves 

Dados los puntos de alto valor presentes en ADME, es conveniente dividirlos en

categorías: propio del del VCS o del VCP.

Propios del Version Control System: 

● Funcionalidad
● Curva de aprendizaje
● Popularidad en el mercado
● Seguridad

Propios de Version Control Services o Plataformas  

● Costos
● Soporte
● Seguridad

   

 
  

Funcionalidad 
GIT > Mercurial > SVN

Git es el líder indiscutible en esta categoría, en gran parte gracias a la intención de su creación:
el kernel de linux. Git posee la mayor cantidad de comandos (164) y formas de realizar
operaciones entre estos 3 VCS. Su extensiva documentación y soporte de la comunidad ha
llevado a distintos flujos de trabajo y mejores prácticas. Mercurial y SVN le siguen y, como
veremos en mas detalle próximamente, no es de sorprendernos, ya que también sus curvas de
aprendizaje son mas sencillas.

Curva de aprendizaje 
SVN > Mercurial > Git

SVN tiene un repositorio central, lo que hace que sea más fácil para los gerentes tener un
enfoque más descendente para el control, la seguridad, los permisos, etc. La lista de comandos
es menor con respecto a las 2 otras opciones. Como fue detallado anteriormente, SVN nace
para mejorar los fallos de CVS, que ya de por sí era simple comparado con las otras
alternativas. Entre mercurial y Git, el factor que coloca a Git por debajo es la cantidad de
opciones que se tienen con cada comando, mientras que el approach de Mercurial es el
elemental de una terminal: cada comando realiza 1 sola función, y la realiza de manera
efectiva.

Seguridad 
SVN > Git > Mercurial

La principal razón por la que SVN es superior en este aspecto es por su aspecto fundamental:
es un sistema de control de versiones centralizado: Los permisos, protocolos de seguridad,
accesos, reglas, parte de un mismo punto. Es más sencillo y efectivo. Otra gran característica
de SVN en relación a seguridad e integridad es la modalidad de atomic commits: los cambios
sólo se efectúan sólo cuando un proceso completo tiene éxito, similar a los procesos bancarios.

 
  

Popularidad en el mercado 
Git > SVN > Mercurial

El crecimiento de Git dentro de la industria y dentro de la comunidad de desarrolladores es

indiscutible

 
  

Costos 
Ya que las 3 herramientas de version control son gratis y open source, los costos están
relacionadas a las plataformas utilizadas con las que se asocia.
Analizamos 3 plataformas de VC, ambas con soporte para las 3 VCS. ​En el caso de SVN y
mercurial es a través de mirrors​.

Github

 
Bitbucket

 
  

Gitlab 

Para el nivel y la categoría de un centro financiero como lo es ADME, deben considerarse las
opciones enterprise/premium. La decisión de costo beneficio es independiente del sistema de
control de versiones, por lo que esta recomendación será dada junto con el veredicto final.

 
  

Soporte 
En términos de documentación y comunidad: 

GIT > SVN > Mercurial

Al ser Git el VCS de más uso, es el que más apoyo de la comunidad y diferentes
documentaciones / foros / cursos tiene. En ese mismo orden, SVN y Mercurial son los
siguientes.

En términos de plataforma: 
GIT > el resto , por su soporte nativo en los mayores ofertantes.

 
  

Veredicto final 

La recomendación es transicionar a ​ Git u​ tilizando A

​ zure DevOps  

Razones: 

● VCS líder en la industria, con mayor soporte de comunidad, ofertas de

herramientas/plataformas más robusta, y adaptada a necesidades actuales acerca
del desarrollo de soluciones tecnológicas.
● VCS con mas funcionalidades y versatilidad al momento de gestionar software
● En el caso de Azure DevOps, es respaldado por todas las medidas de seguridad de
Microsoft, y posee integraciones con Active Directory y su suite de aplicaciones
enterprise, el cual es líder en el sector financiero.
● Entrega de nuevas funcionalidades y actualizaciones/patches cada 3 semanas

Algunos compañías que utilizan Azure DevOps:

 
 
 
 
 
 
 

 
  

Estrategia de ramas propuestas: Release Flow de 

Microsoft 
 
 
 
La siguiente estrategia de ramas es la base que Microsoft utiliza para la recomendación de
estrategias a sus consumidores y es la que utilizan en su monorepositorio de proyectos.

Consiste en los siguientes puntos principales:

● Utilizar ramas para nuevos features que partan de la rama principal
● Unir las ramas features a la rama principal a través de pull requests
● Mantener la rama principal estable y desplegable en todo momento
● Al momento de tener una versión de la rama principal lista para ser desplegada, llamada
release, se crea una rama release, que no vuelve a ser unida a master jamás.

Esta estrategia va acompañada de políticas de seguridad, para mantener la estructura limpia y

cumplible. Por ejemplo, se aplica una regla para no permitir la unión directa a master, también
para no permitir la unión de release branches a master. Podemos también exigir compilaciones
limpias de las ramas de features antes de ser unidas a la rama principal.

En caso de hacer correcciones a una rama de release, podemos traer esos cambios a master,
pero a través de cherry-picking con git.

 
  

Versionamiento semántico 
 
Qué es? E
​ s una estrategia diseñada para gestionar las distintas versiones que puede tener
un software.

Qué  problema  intenta  resolver?  ​El llamado “infierno de dependencias” o dependency

hell. Citando la página oficial de la descripción del versionamiento semántico: “​Si las
especificaciones de dependencia son demasiado estrictas, corres el riesgo de bloquear la
versión (la imposibilidad de actualizar un paquete sin tener que lanzar nuevas versiones de
cada paquete dependiente). Si las dependencias se especifican con demasiada soltura,
inevitablemente serás mordido por la promiscuidad de la versión (suponiendo compatibilidad
con más versiones futuras de lo razonable). El infierno de dependencia es donde estás cuando
el bloqueo de versión y / o la promiscuidad de la versión te impiden avanzar de manera fácil y
segura en tu proyecto”​ . 

En qué consiste? S
​ eguir un modelo de 3 números: MAYOR.MENOR.PATCH

1. Versiones ​mayores​ se hacen cuando se aplica un cambio incompatible al software.

2. Versiones m​ enores​ se da cuando se agrega una funcionalidad que es backwards
compatible
3. Versiones ​patch​ se da cuando se hacen arreglos de bugs que son compatibles.

Los reglamentos mas importantes del versionamiento semántico son:

1. Software utilizando versionamiento semántico DEBE declarar un API público. Puede ser en
código o en documentación,pero debe ser exhaustivo y comprensivo.
2. Las versiones deben tener el formato MAYOR.MENOR.PATCH , utilizando números naturales,
sin saltarse números. Ejemplo -> ​1.9.0 -> 1.10.0 -> 1.11.0
3. Una vez lanzada una versión, el contenido de esta NO PUEDE cambiar. Cualquier cambio
adicional debe ser lanzado en una siguiente versión.
4. Todo código que esté en una versión MAYOR 0 no debe considerarse estable, y puede
cambiar en cualquier momento.

 
  

5. Versiones 1.0.0 define el api público. La forma en la que las versiones siguientes cambias
es en base a este API.
6. Las versiones PATCH Z (x.y.Z | x > 0) DEBEN ser incrementadas solo si se introduces bug
fixes que son compatibles con versiones anteriores.
7. Versiones MENORES Y (x.Y.z | x > 0) DEBEN ser incrementadas solo si se introducen nuevas
funcionalidades al API público compatibles con versiones anteriores.
8. Versiones MAYORES X (X.y.z | X > 0) DEBEN ser incrementadas cuando se agreguen
cambios que no es compatible con versiones anteriores.

Versionamiento semántico en ADME 

Los r​ elease branches​ se encargan de esto. La estrategia va a consistir en enumerar estos 

release branches en base versionamiento semántico. 

 
Referencia base: 
https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/use-git-microsoft 
https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-d
evops 
https://semver.org/ 
   

 
  

Roles propuestos para VCS 

Team lead 

Como  parte  del  equipo  de  desarrollo,  se  encarga  de  desarrollar  funcionalidades  o  dar 
mantenimiento  a  software  desarrollado.  También  se  encargará  de  aprobar  cambios  y  unión de 
ramas. Permisos: 

● Crear ramas 
● Eliminar ramas 
● Ver ramas 
● Editar ramas 
● Push ramas 
● Merge ramas 

Developer 

Como  parte  del  equipo  de  desarrollo,  se  encarga  de  desarrollar  funcionalidades  o  dar 
mantenimiento  a  software  desarrollado.  A  diferencia  del  team  lead,  un  developer  no  podrá 
aprobar cambios ni unir feature branches a la rama principal. Permisos: 

● Crear ramas 
● Ver Ramas 
● Editar Ramas 
● Push a ramas 

Project Manager 

Encargado  de  seguir  la  gestión  del  proyecto.  Este  usuario puede crear  , modificar y, en caso de 
ser  necesario,  eliminar  proyectos  y  subproyectos.  Da  seguimiento  a  las  tareas  de  Azure 
DevOps,. Permisos 

● Creación de proyectos 
● Ver proyectos 

 
  

● Editar proyectos 
● Borrar proyectos 

Configuration Manager 

Da  soporte  a  los  equipos  de  trabajo  en  la  configuración  de  items  de  proyectos.  Prepara 
documentación  y  mantiene  la  base  de  datos  de  CM,  hace  reviews  de  procesos  y  cambios, 
mantiene  la  calidad  de  datos  de  la  base  de  datos de CM. Al igual que el Team Lead, este puede 
aprobar cambios y autorizar uniones a la rama principal. Responsabilidades: 

● Ver repositorios 
● Crear repositorios 
● Editar repositorios 
● Eliminar repositorios 
● Merge de ramas