Nombre: Cristhian Isaac Taveras Diaz

Matrícula: 2020-10541

Materia: Electiva 2

Profesor: Francis Ramirez

 Resumen de Azure DevOps: Implementing Azure DevOps
Solutions

Introducción:

El control de código fuente es crucial en el desarrollo de software.

Permite a los equipos rastrear y administrar cambios en el código a lo
largo del tiempo, facilitando la colaboración entre desarrolladores. Con
herramientas como Git, subversión o Mercurial, los equipos pueden
mantener un registro de versiones, ramificar el código y combinar
cambios de manera ordenada, lo que simplifica la gestión de
proyectos.

En esta introducción, vamos a estar cubriendo el tema de Azure Boards

más a detalle, así como los diferentes procesos disponibles que hay en
Azure DevOps.

En el ámbito de DevOps, el control de código es fundamental para la

integración y la entrega continuas. Automatiza pruebas, compilaciones
y despliegues basados en cambios de código, agilizando el proceso de
desarrollo y garantizando entregas de software rápidas y confiables.

Además, el control de código es esencial para prácticas como la

infraestructura como código y la gestión de configuraciones como
código. Esto amplía su alcance más allá del código de la aplicación para
incluir la gestión de la infraestructura y la configuración asociada, lo
que permite una administración coherente y reproducible de la
infraestructura y las aplicaciones a lo largo de su ciclo de vida.
En Azure DevOps, existen dos tipos principales de control de código
fuente: TFVC (Team Foundation Version Control) y Git. TFVC es un
sistema centralizado que sigue un modelo tradicional, mientras que Git
es distribuido y ofrece mayor flexibilidad y poder. Azure Repos facilita
la adopción de ambos sistemas al proporcionar una plataforma
integrada que admite tanto TFVC como Git, junto con herramientas de
colaboración, seguimiento de problemas y automatización de
compilación e implementación. Esto permite a los equipos gestionar
eficientemente el ciclo completo de desarrollo de software.

Tipos de Control de código Fuente en Azure DevOps

Existen dos tipos principales de sistemas de control de código fuente:

centralizados y descentralizados. En un sistema centralizado, toda la
historia y las ramas del repositorio están almacenadas en un solo
servidor. En cambio, en un sistema descentralizado, cada usuario tiene
una copia completa del repositorio, incluyendo su historial y ramas.

Azure Repos, parte de Azure DevOps, ofrece dos opciones principales:

TFVC (Team Foundation Version Control) y Git.

TFVC es centralizado y sigue un enfoque tradicional, con un solo

repositorio central donde los desarrolladores hacen cambios
directamente. Es útil para equipos que prefieren un flujo de trabajo
más controlado.
Git es descentralizado y permite a cada desarrollador tener una copia
completa del repositorio en su máquina local. Esto brinda más libertad
y flexibilidad para experimentar con diferentes flujos de trabajo.

Azure Repos es compatible con ambos sistemas, ofreciendo

herramientas para colaboración, seguimiento de problemas y
automatización de compilación e implementación.

En un sistema centralizado, el servidor es el único lugar donde se

almacena el repositorio, lo que puede causar problemas si el servidor
falla. Los desarrolladores dependen del servidor para acceder al código
y realizar cambios. En cambio, en un sistema descentralizado, cada
desarrollador tiene su copia del repositorio, lo que proporciona
redundancia y flexibilidad.
Aunque los sistemas centralizados como TFVC son utilizados en
muchos entornos de desarrollo, especialmente en organizaciones que
prefieren un control más estricto sobre el flujo de código y los
permisos de acceso, la popularidad de los sistemas distribuidos como
Git está en aumento debido a su flexibilidad, capacidad de trabajo sin
conexión y eficiencia en entornos distribuidos o con equipos
geográficamente dispersos.

Control de Código Fuente Centralizado

En un sistema centralizado de control de código fuente, el repositorio

se almacena exclusivamente en el servidor, incluyendo todo su
historial. Al crear una versión local, solo se obtiene la última iteración
del código. Este enfoque requiere consultar el servidor para acceder a
cualquier cambio anterior, ya que los desarrolladores solo tienen
acceso local a la versión más reciente y a sus cambios locales. Si el
servidor central experimenta problemas, como fallas o interrupciones,
los desarrolladores pueden enfrentar dificultades para acceder al
código o continuar con su trabajo. Además, las operaciones que
implican consultar el servidor pueden ser más lentas si hay problemas
de rendimiento en la red o en el servidor. A pesar de estas limitaciones,
los sistemas centralizados como TFVC todavía se utilizan en muchos
entornos de desarrollo, aunque los sistemas distribuidos como Git
están ganando popularidad debido a su flexibilidad y eficiencia en
entornos distribuidos o con equipos geográficamente dispersos.

En los sistemas centralizados, el control de versiones se lleva a cabo de

manera más estructurada y controlada. Esto puede ser beneficioso
para equipos que prefieren un flujo de trabajo más ordenado y
controlado. Sin embargo, puede haber limitaciones en cuanto a la
velocidad de acceso a los cambios anteriores y la capacidad de trabajar
sin conexión. Estas limitaciones han llevado al crecimiento de sistemas
distribuidos como Git, que ofrecen una mayor flexibilidad y autonomía
a los desarrolladores.

Control de Código Fuente Descentralizado:

En un sistema descentralizado de control de código fuente, todos los

archivos, historiales y ramas se almacenan en un servidor central, pero
la diferencia clave es que al copiar el repositorio para tener una versión
local, obtienes una réplica completa del mismo. Esto significa que
puedes acceder al historial de archivos y otras ramas sin necesidad de
estar conectado al servidor todo el tiempo. Esta capacidad reduce la
carga en el servidor y permite trabajar incluso sin conexión a Internet,
lo que facilita la colaboración entre equipos distribuidos
geográficamente o con horarios diferentes.

Los cambios pueden compartirse y sincronizarse entre diferentes

repositorios mediante operaciones de "empuje" y "tirar" hacia y desde
el servidor central. Esto hace que la colaboración en entornos
altamente distribuidos sea mucho más sencilla.

Los sistemas descentralizados dan a los desarrolladores una mayor

autonomía, ya que les permiten trabajar de forma independiente en
sus propias copias del repositorio. Esto promueve la experimentación y
la creatividad, especialmente en proyectos que requieren iteraciones
rápidas y colaborativas. Además, facilitan la colaboración entre equipos
distribuidos geográficamente, ya que cada desarrollador puede
trabajar en su propio entorno local y luego compartir y fusionar
cambios de manera fluida.

Sistemas de Control de Código Fuente

En el mundo del control de código fuente, hay tres sistemas principales:

TFVC, Git y subversión (también conocido como SVN). TFVC es
centralizado, desarrollado por Microsoft; Git es distribuido y muy
popular; y subversión es centralizado, desarrollado por la Fundación
Apache.

Cada uno tiene sus ventajas: TFVC es bueno para entornos donde se
necesita un control estricto sobre el código y los permisos; Git ofrece
flexibilidad y autonomía para proyectos que requieren colaboración
rápida y flexible; y Subversion es una opción intermedia que combina
características de sistemas centralizados y distribuidos.

La elección del sistema de control de código fuente depende de las

necesidades y preferencias específicas de cada equipo y proyecto.

Almacenamiento de Archivos Grandes:

Git está optimizado para archivos de texto, pero puede ser necesario
almacenar otros tipos de archivos, como imágenes o archivos binarios.
Para esto, se introdujo el almacenamiento de archivos grandes (LFS),
que permite gestionar estos archivos de manera eficiente en Git.

El almacenamiento de archivos grandes es útil para proyectos que

requieren el seguimiento de archivos de gran tamaño, como imágenes,
videos o archivos binarios. Esto permite a los desarrolladores manejar
estos archivos de manera eficiente dentro del repositorio Git, sin
comprometer el rendimiento o la integridad de los datos.

Migración entre Sistemas de Control

En el proceso de adopción de DevOps, puede ser necesario migrar

fuentes de un sistema de control a otro. Esto puede implicar migrar
desde GitLab o Subversion a Azure Git Repos. Existen múltiples
opciones para realizar estas migraciones, lo que permite a las
empresas optimizar y unificar sus herramientas de desarrollo.
La migración entre sistemas de control de código fuente es un paso
crucial en el proceso de adopción de DevOps. Permite a las empresas
mejorar la eficiencia y la agilidad de su equipo de desarrollo al unificar
sus herramientas y procesos. Además, facilita la colaboración y la
integración continua en todo el ciclo de vida del desarrollo de software.

Migración de TFVC a un Repositorio Azure Git

Para migrar de TFVC a un repositorio Git en Azure, se puede utilizar el

mismo repositorio de importación que para cualquier migración de Git
a Azure. Si se necesita mover historial de más de 180 días, existen otros
métodos más complicados disponibles.

La migración de TFVC a Azure Git Repos es un proceso importante en el

camino hacia DevOps. Permite a las empresas aprovechar las
características y capacidades específicas de Azure DevOps, como

la integración nativa con otras herramientas de DevOps y la gestión

avanzada de proyectos.
Migración de subversión a un Repositorio Azure Git

No hay una solución lista para usar para migrar de subversión a Git en
Azure, pero se pueden utilizar herramientas de terceros, como las
proporcionadas por Atlassian, para realizar esta migración
conservando el historial de cambios.

La migración de subversión a Azure Git Repos es un proceso complejo

que requiere planificación y ejecución cuidadosas. Permite a las
empresas aprovechar las ventajas de Git, como su estructura
distribuida y su flexibilidad, mientras conservan el historial de cambios
de sus proyectos.

• Migración sin Conservar el Historial:

Si es necesario migrar sin conservar el historial, se puede crear un
nuevo repositorio vacío y enviar los cambios existentes usando un
comando específico.

La migración sin conservar el historial es una opción para empresas

que desean comenzar desde cero en un nuevo sistema de control de
código fuente. Permite una transición rápida y sencilla, aunque puede
implicar la pérdida de datos históricos importantes.

Selección de una Estrategia de Ramificación y Fusión

El control de código fuente permite trabajar temporalmente por

separado y luego fusionar los cambios. Las ramas se utilizan para aislar
trabajos temporales y decidir más tarde qué cambios se incluirán en la
versión final.

La selección de una estrategia de ramificación y fusión es crucial para

garantizar un desarrollo de software eficiente y organizado. Permite a
los equipos trabajar en paralelo en diferentes características o
correcciones de errores sin interferir entre sí.

Estrategias de Ramificación

Hay varias estrategias de ramificación disponibles, pero tres de las más

populares en la actualidad son las siguientes:

-Flujo de GitHub: GitHub Flows es una estrategia simple pero efectiva.

Consiste en tener una rama maestra que siempre debe estar lista para
implementarse. No se permiten cambios incompletos en la rama
maestra para mantener un código limpio y funcional.

-GitFlow: GitFlow es otra estrategia bien conocida y desarrollada que

puede manejar prácticamente cualquier situación al trabajar con
software de manera más estructurada y específica.

-Flujo de liberación: Este flujo implica la creación de ramas

temáticas efímeras a partir de la rama maestra. Estas ramas se utilizan
para desarrollar nuevas funcionalidades y se fusionan con la rama
maestra una vez completadas.

Cada una de estas estrategias tiene sus propias características y

ventajas, y la elección entre ellas depende de las necesidades y
preferencias del equipo de desarrollo.

Repositorios Seguros

Aunque la configuración de seguridad para el control de código fuente

descentralizado suele ser menos detallada que para el control
centralizado, Azure Repos ofrece formas de establecer autorizaciones
en repositorios y ramas a nivel de servidor. Por defecto, todas las
autorizaciones se heredan de los valores predeterminados del
proyecto.

Política de Sucursales

En Azure DevOps, la política de sucursales es una característica crucial

que permite a los equipos establecer reglas y restricciones para la
gestión de ramas en repositorios Git. Estas políticas garantizan la
coherencia, calidad y seguridad del código, facilitando un flujo de
trabajo colaborativo y eficiente.

Con las políticas de sucursales, los equipos pueden aplicar controles

como revisiones de código obligatorias, pruebas automatizadas antes
de fusionar cambios y restricciones de aprobación. Esto asegura que
los cambios se integren adecuadamente sin comprometer la
estabilidad del proyecto.
Configurar políticas de sucursales en Azure DevOps permite a los
equipos personalizar sus flujos de trabajo según las necesidades del
proyecto y los estándares de calidad establecidos. Por ejemplo, pueden
requerir que cada cambio propuesto pase por una revisión de código
antes de fusionarse en la rama principal, lo que ayuda a detectar
errores temprano y mantener la calidad del código.