Delen via

Samenwerking en Agile-ontwikkeling versnellen met componentisatie

  • Artikel

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

Uw product is succesvol, uw organisatie groeit en het is tijd om uw codebasis omhoog te schalen om aan dit succes te voldoen. Wanneer u de afgelopen 2-3 teams uitschaalt die in één codebasis op één product werken, kunt u vragen stellen zoals:

  • Hoe kunnen mijn teams efficiënt herbruikbare onderdelen delen?

  • Hoe kan ik mijn functieteams in staat stellen om snel te herhalen zonder dat ze op het werk van andere teams hoeven te stappen?

  • Hoe kan ik mijn teams autonomie geven om het tempo te herhalen dat geschikt is voor hen?

Teams kunnen op elk gewenst moment profiteren van het overwegen van deze vragen. Als u een gevestigd team bent met een verouderde codebasis, stelt u mogelijk dezelfde vragen als u wordt gevraagd om meer waarde te leveren, sneller dan ooit. Ongeacht uw situatie kunt u met componentisatie een codebasis bouwen die wordt geschaald naar de grootte van uw team en de snelheid van de huidige ontwikkeling.

In dit artikel verkennen we hoe binaire samenstelling via Azure Artifacts u kan helpen bij het beheren en delen van uw externe afhankelijkheden, uw opensource-software en uw geïsoleerde gedeelde onderdelen.

Onderdelen en samenstelling

Componentisatie is het proces van het verdelen en ordenen van uw product in afzonderlijke onderdelen. De meeste .NET-projecten hebben al een idee van onderdelen in de vorm van de projecten binnen de oplossing. Een basiswebsite kan bijvoorbeeld bestaan uit een front-endonderdeel, een gegevenstoegangsonderdeel en een model/gegevensopslagonderdeel.

Bronsamenstelling

Naarmate uw product groeit, kunnen de oplossing en het projectmodel inefficiënt worden. Het duurt langer om wijzigingen te integreren en zijn moeilijker samen te voegen, de build wordt langzamer en onderdelen groeien van één project naar meerdere projecten. Over het algemeen is dit het punt waarop teams beginnen met het uitsplitsen van deze reeks gerelateerde projecten in afzonderlijke oplossingen.

Zodra u één oplossing hebt ontgroeid, wordt de componentize een interessante vraag. We zijn begonnen met bronsamenstelling, waar elk onderdeel wordt verwezen via een projectverwijzing in Visual Studio. Bronsamenstelling is mogelijk zolang uw bron zich in één samenstellingsgrens bevindt: één oplossing binnen één bronopslagplaats.

Helaas beginnen deze projectverwijzingen op te splitsen wanneer er meerdere oplossingen betrokken zijn. Wanneer oplossing A op dit moment afhankelijk is van oplossing B, moet deze verwijzen naar de ingebouwde binaire bestanden (zoals DLL's) die door oplossing B worden geproduceerd. Dit is binaire samenstelling.

Daarom moeten deze binaire bestanden nu worden gebouwd en beschikbaar worden gesteld aan oplossing A voordat deze kan worden gebouwd. U kunt dit op een aantal manieren doen:

  • U kunt ze controleren in broncodebeheer. Afhankelijk van uw broncodebeheersysteem kunnen binaire bestanden snel de grootte van uw opslagplaats ballonnen, waardoor de check-outtijden en de algemene prestaties van de opslagplaats worden vertraagd. Als u in vertakkingen begint te werken, kunnen meerdere teams uiteindelijk hetzelfde binaire bestand in verschillende versies introduceren, wat leidt tot uitdagende samenvoegingsconflicten.

  • U kunt ze ook hosten op een bestandsshare, hoewel deze aanpak bepaalde beperkingen heeft. Bestandsshares hebben geen index voor snelle zoekacties en bieden geen bescherming tegen het overschrijven van een versie in de toekomst.

Samenstelling van pakket

Pakketten pakken veel van de uitdagingen aan van het verwijzen naar binaire bestanden. In plaats van ze in de bron te checken, kunt u een oplossing B de binaire bestanden laten produceren als NuGet-pakketten die een andere oplossing A vervolgens kan gebruiken. Als oplossing A en oplossing B als afzonderlijke onderdelen worden onderhouden, waarbij gelijktijdige wijzigingen in A en B zeldzaam zijn, is pakketsamenstelling een uitstekende manier om de afhankelijkheid van A op B te beheren. Met pakketsamenstelling kan B op eigen frequentie herhalen, terwijl A vrij is om updates van B te krijgen wanneer A's planning toestaat, en hiermee kunnen meerdere teams oplossing B herhalen en bijwerken zonder dat dit van invloed is op oplossing A (of andere oplossingen C of D).

Pakketsamenstelling heeft echter wel een eigen set uitdagingen. Tot nu toe hebben we een eenvoudig voorbeeld onderzocht. Het schalen van pakketsamenstelling tot de grootte van een grote codebasis (iets zoals Windows of Bing) kan een reeks uitdagingen veroorzaken:

  • Inzicht in de impact van belangrijke wijzigingen in een onderdeel dat laag in de afhankelijkheidsgrafiek is, wordt erg lastig.

  • Diamantafhankelijkheden kunnen een aanzienlijk obstakel voor flexibiliteit worden. In een diamantafhankelijkheid zijn onderdelen B en C beide afhankelijk van een gedeeld onderdeel A, terwijl onderdeel D afhankelijk is van zowel B als C. Wanneer onderdeel A een nieuwe versie introduceert met belangrijke wijzigingen, als B wordt bijgewerkt naar de nieuwe versie, maar C niet, kan D de updates van B niet overnemen zonder een afhankelijkheidsconflict in te voeren. In dit eenvoudige voorbeeld is een gesprek met C mogelijk alles wat nodig is om het conflict op te lossen. In een complexe grafiek kunnen diamanten echter snel onoplosbaar worden.

  • Wanneer wijzigingen moeten worden toegepast op twee onderdelen die zijn samengesteld met behulp van pakketten, wordt de iteratiecyclus van de ontwikkelaar aanzienlijk langzamer. Als onderdeel A is bijgewerkt, moet het opnieuw worden opgebouwd, opnieuw verpakt en opnieuw worden gepubliceerd. Vervolgens moet onderdeel B worden bijgewerkt naar de onlangs gepubliceerde versie om de wijziging te valideren die is aangebracht in onderdeel A. Het gebruik van bronsamenstelling, waarmee gelijktijdig bouwen van component A en B mogelijk is, levert consistent een snellere iteratiecyclus voor ontwikkelaars.

Wat moet u gebruiken

Over het algemeen hebben we gezien dat grote teams het meest succesvol zijn wanneer ze een combinatie van samenstellingsstrategieën gebruiken. Om te bepalen wat geschikt is voor uw codebase, begint u met het toewijzen van de afhankelijkheidsgrafiek van uw product en begint u met het groeperen van uw onderdelen in sets met gerelateerde onderdelen.

U hebt bijvoorbeeld een verzameling onderdelen die uw framework vormen en een andere set onderdelen die uw gebruikersgerichte service vormen. Stel vervolgens voor elke groep gerelateerde onderdelen de volgende vragen:

  • Kan ik regelmatig inchecken in de sets die ik heb ingesteld voor mijn teams?

  • Is één team verantwoordelijk voor de hele set?

  • Is er voor één set een gedeelde releasefrequentie?

In onze ervaring hebben we vastgesteld dat het gebruik van bronsamenstelling het meest effectief is voor gerelateerde projecten die worden afgehandeld door één team of een groep gerelateerde teams. Omgekeerd bewijst binaire samenstelling voordelig voor opensource-software, externe afhankelijkheden (onderdelen van verre of geïsoleerde teams) en onafhankelijke gedeelde onderdelen.