Compartir a través de

Aceleración de la colaboración y el desarrollo ágil con componentes

  • Artículo

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

El producto se ha realizado correctamente, su organización está creciendo y es el momento de escalar verticalmente el código base para que coincida con este éxito. A medida que escale horizontalmente los equipos anteriores a 2 a 3 que trabajan en un único código base en un solo producto, puede encontrarse haciendo preguntas como:

  • ¿Cómo pueden mis equipos compartir componentes reutilizables de forma eficaz?

  • Cómo permitir que mis equipos de características iteran rápidamente sin avanzar en el trabajo de otros equipos?

  • Cómo dar autonomía a mis equipos para iterar al ritmo adecuado para ellos?

Los equipos en cualquier fase pueden beneficiarse de considerar estas preguntas. Si es un equipo establecido con un código base heredado, puede hacer estas mismas preguntas que se le pide que entreguen más valor, más rápido que nunca. Independientemente de su situación, la componenteción puede ayudarle a crear un código base que se escala al tamaño de su equipo y a la velocidad del desarrollo actual.

En este artículo, exploraremos cómo la composición binaria a través de Azure Artifacts puede ayudarle a administrar y compartir las dependencias externas, el software de código abierto y los componentes compartidos aislados.

Componentes y composición

La componenteización es el proceso de dividir y organizar el producto en componentes distintos. La mayoría de los proyectos de .NET ya tienen algunas nociones de componentes en forma de proyectos dentro de la solución. Por ejemplo, un sitio web básico puede constar de un componente front-end, un componente de acceso a datos y un componente de almacenamiento de datos o modelo.

Composición de origen

A medida que crece el producto, la solución y el modelo de proyecto pueden ser ineficaces. Los cambios tardan más tiempo en integrarse y son más difíciles de combinar, la compilación se ralentiza y los componentes empiezan a crecer de un solo proyecto a varios proyectos. Por lo general, este es el punto en el que los equipos empiezan a dividir estos conjuntos de proyectos relacionados en soluciones independientes.

Una vez que haya superado una única solución, la forma en que se convierte en una pregunta interesante. Empezamos con la composición de origen, donde se hace referencia a cada componente a través de una referencia de proyecto en Visual Studio. La composición de origen es posible siempre que el origen resida en un único límite de composición: una única solución dentro de un único repositorio de origen.

Desafortunadamente, estas referencias de proyecto comienzan a desglosarse cuando hay varias soluciones implicadas. En este punto, cuando la solución A depende de la solución B, debe hacer referencia a los archivos binarios compilados (como archivos DLL) generados por la solución B: esta es la composición binaria.

En consecuencia, estos archivos binarios ahora deben compilarse y ponerse a disposición de la solución A para poder compilarse correctamente. Hay varias maneras de hacerlo:

  • Puede comprobarlos en el control de código fuente. En función del sistema de control de código fuente, los archivos binarios pueden activar rápidamente el tamaño del repositorio, ralentizar los tiempos de des check-out y el rendimiento general del repositorio. Si empieza a trabajar en ramas, varios equipos pueden acabar introduciendo el mismo binario en distintas versiones, lo que provoca conflictos de combinación difíciles.

  • Como alternativa, puede hospedarlos en un recurso compartido de archivos, aunque este enfoque viene con ciertas limitaciones. Los recursos compartidos de archivos carecen de un índice para búsquedas rápidas y no proporcionan protección contra la sobrescritura de una versión en el futuro.

Composición del paquete

Los paquetes abordan muchos de los desafíos de hacer referencia a archivos binarios. En lugar de comprobarlos en el origen, puede hacer que una solución B genere sus archivos binarios como paquetes NuGet que otra solución A pueda consumir. Si la solución A y la solución B se mantienen como componentes independientes, donde los cambios simultáneos en A y B son poco frecuentes, la composición del paquete es una excelente manera de administrar la dependencia de A en B. La composición del paquete permite iterar por su propia cadencia, mientras que A es libre de obtener actualizaciones de B cuando la programación de A permite, y permite a varios equipos iterar y actualizar la solución B sin afectar a la solución A (u otras soluciones C o D).

Sin embargo, la composición del paquete viene con su propio conjunto de desafíos. Hasta ahora, hemos examinado un ejemplo sencillo. El escalado de la composición de paquetes hasta el tamaño de un código base grande (algo como Windows o Bing) puede provocar una serie de desafíos:

  • Comprender el impacto de los cambios importantes en un componente bajo en el gráfico de dependencias se vuelve muy difícil.

  • Las dependencias de diamante pueden convertirse en un obstáculo importante para la agilidad. En una dependencia de diamante, los componentes B y C dependen de un componente compartido A, mientras que el componente D depende de B y C. Cuando el componente A introduce una nueva versión con cambios importantes, si B se actualiza a la nueva versión pero C no, D no puede tomar las actualizaciones de B sin introducir un conflicto de dependencias. En este ejemplo sencillo, una conversación con C puede ser todo lo necesario para resolver el conflicto. Sin embargo, en un gráfico complejo, los diamantes se pueden deshacer rápidamente.

  • Cuando es necesario aplicar modificaciones a dos componentes que se componen mediante paquetes, el ciclo de iteración del desarrollador se vuelve considerablemente más lento. Si se actualiza el componente A, necesita volver a generarlo, volver a empaquetarlo y volver a publicarlo. Posteriormente, el componente B debe actualizar a la versión publicada recientemente para validar el cambio realizado en el componente A. El empleo de la composición de origen, que permite la creación simultánea de Componente A y B, proporcionará de forma coherente un ciclo de iteración más rápido para los desarrolladores.

¿Qué debe usar?

En general, hemos visto que los equipos grandes son más exitosos cuando usan una mezcla de estrategias de composición. Para ayudar a determinar lo que es adecuado para el código base, empiece por asignar el gráfico de dependencias del producto y empiece a agrupar los componentes en conjuntos de componentes relacionados.

Por ejemplo, puede tener una colección de componentes que constituyen el marco y otro conjunto de componentes que forman el servicio orientado al usuario. A continuación, para cada grupo de componentes relacionados, haga estas preguntas:

  • ¿Puedo prever check-ins frecuentes en los conjuntos que he establecido para mis equipos?

  • ¿Es un único equipo responsable de todo el conjunto?

  • Para un único conjunto, ¿existe una cadencia de versión compartida?

En nuestra experiencia, hemos encontrado que el uso de la composición de origen es más eficaz para los proyectos relacionados administrados por un único equipo o un grupo de equipos relacionados. Por el contrario, la composición binaria resulta ventajosa para software de código abierto, dependencias externas (componentes de equipos distantes o aislados) y componentes compartidos independientes.