Megosztás a következőn keresztül:

Az együttműködés és az agilis fejlesztés felgyorsítása komponensekkel

  • Cikk

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

A termék sikeres, a szervezet növekszik, és ideje felskálázni a kódbázist, hogy megfeleljen ennek a sikernek. Amikor az elmúlt 2-3 csapatot skálázza fel egyetlen kódbázisban egyetlen terméken, előfordulhat, hogy a következő kérdéseket teszi fel:

  • Hogyan oszthatják meg hatékonyan a csapataim az újrafelhasználható összetevőket?

  • Hogyan lehetővé tenni a funkciócsapatok számára, hogy gyorsan iteráljanak anélkül, hogy más csapatok munkájára lépnék?

  • Hogyan a csapatomnak autonómiát adni, hogy a számukra megfelelő ütemben haladjanak?

A teams bármely szakaszában hasznos lehet ezeknek a kérdéseknek a mérlegelése. Ha ön egy régi kódbázissal rendelkező, már meglévő csapat, akkor ugyanazokat a kérdéseket teheti fel, mint amit a rendszer arra kér, hogy minden eddiginél több értéket biztosítson. A helyzettől függetlenül az összetevők segíthetnek létrehozni egy olyan kódbázist, amely a csapat méretére és a mai fejlesztés sebességére skálázható.

Ebben a cikkben azt ismertetjük, hogy az Azure Artifactsen keresztüli bináris összetétel hogyan segíthet a külső függőségek, a nyílt forráskódú szoftverek és az elkülönített megosztott összetevők kezelésében és megosztásában.

Összetevők és összetétel

Az összetevő-készítés a termék különböző összetevőkre való felosztásának és rendszerezésének folyamata. A legtöbb .NET-projekt már rendelkezik bizonyos összetevők fogalmával a megoldáson belüli projektek formájában. Egy alapszintű webhely például egy előtér-összetevőből, egy adatelérési összetevőből és egy modell/adattárolási összetevőből állhat.

Forrásösszeállítás

A termék növekedésével a megoldás és a projektmodell nem lesz hatékony. A módosítások integrálása hosszabb időt vesz igénybe, és nehezebben egyesíthetők, a build lassabb lesz, és az összetevők egyetlen projektből több projektbe nőnek. Általában ez az a pont, ahol a csapatok külön megoldásokra bontják ezeket a kapcsolódó projekteket.

Miután kinőtt egy megoldást, az összetevők összetevői érdekes kérdéssé válnak. A forráskompozícióval kezdtük, ahol minden összetevőre egy projektreferencián keresztül hivatkozunk a Visual Studióban. A forrásösszetétel mindaddig lehetséges, amíg a forrás egyetlen összetételű határban él: egyetlen megoldás egy forrásadattárban.

Sajnos ezek a projekthivatkozások több megoldás használata esetén kezdenek szétesni. Ezen a ponton, amikor az A megoldás a B megoldástól függ, a B megoldás által létrehozott bináris fájlokra (például DLL-ekre) kell hivatkoznia – ez bináris összetétel.

Ennek megfelelően ezeket a bináris fájlokat létre kell hozni és elérhetővé kell tenni az A megoldáshoz, mielőtt sikeresen felépíthető lenne. Ezt többféleképpen is megteheti:

  • Ellenőrizheti őket a forrásvezérlőben. A forrásvezérlő rendszertől függően a bináris fájlok gyorsan ballonosabbá tehetik az adattár méretét, lelassíthatják a kivételi időket és általános adattárteljesítményt. Ha ágakban kezd dolgozni, több csapat is bevezetheti ugyanazt a bináris fájlt különböző verziókban, ami kihívást jelent az egyesítési ütközésekhez.

  • Másik lehetőségként fájlmegosztáson is üzemeltetheti őket, bár ez a megközelítés bizonyos korlátozásokkal jár. A fájlmegosztások nem rendelkeznek indexeléssel a gyors keresésekhez, és a jövőben nem nyújtanak védelmet a verzió felülírása ellen.

Csomagösszetétel

A csomagok a bináris fájlok hivatkozásának számos kihívásával foglalkoznak. Ahelyett, hogy ellenőrizned kell őket a forrásban, a B megoldás létrehozhatja a bináris fájljait NuGet-csomagokként, amelyeket aztán egy másik A megoldás felhasználhat. Ha az A és a B megoldás különálló összetevőkként van fenntartva, ahol az A és A közötti egyidejű változások ritkán fordulnak elő, a csomagösszetétel nagyszerű módszer az A és a B függőségének kezelésére. A csomagösszetétel lehetővé teszi a B számára, hogy saját ütemben iteráljon, míg az A szabadon kaphat frissítéseket a B-től, amikor az A ütemezése lehetővé teszi, és lehetővé teszi, hogy több csapat is iterálja és frissítse a B megoldást az A (vagy más C vagy D) megoldás befolyásolása nélkül.

A csomagösszetétel azonban saját kihívásokkal jár. Eddig egy egyszerű példát vizsgáltunk meg. A csomagösszetétel nagy kódbázis méretre (például Windows vagy Bing) való méretezése számos kihívást okozhat:

  • A függőségi gráfban alacsonyan lévő összetevők kompatibilitástörő változásainak hatásainak megértése nagy kihívást jelent.

  • A gyémántfüggőségek jelentős akadályt jelenthetnek az agilitás számára. Gyémántfüggőség esetén a B és a C összetevő egyaránt egy megosztott A összetevőtől függ, míg a D összetevő a B-től és a C-től is függ. Ha az A összetevő kompatibilitástörő módosításokkal új verziót vezet be, ha az új verzió B frissítései nem, de a C nem, a D nem tudja a B frissítéseit függőségi ütközés bevezetése nélkül elvégezni. Ebben az egyszerű példában előfordulhat, hogy a C-vel folytatott beszélgetés csak az ütközés feloldásához szükséges. Egy összetett gráfban azonban a gyémántok gyorsan megoldhatatlanná válhatnak.

  • Ha a módosításokat két, csomagokból álló összetevőre kell alkalmazni, a fejlesztő iterációs ciklusa jelentősen lassabb lesz. Ha az A összetevő frissül, az újraépítést, újracsomagolást és újbóli közzétételt igényel. Ezt követően a B összetevőnek frissítenie kell a nemrég közzétett verzióra az A összetevőben végrehajtott módosítás ellenőrzéséhez. A forrásösszetétel alkalmazása, amely lehetővé teszi az A és a B összetevő egyidejű létrehozását, következetesen gyorsabb iterációs ciklust biztosít a fejlesztők számára.

Mit érdemes használni?

Általánosságban elmondható, hogy a nagy csapatok akkor a legeredményesebbek, ha összetételi stratégiák keverékét használják. A kódbázis megfelelőségének meghatározásához először írja le a termék függőségi gráfját, és kezdje el csoportosítani az összetevőket kapcsolódó összetevők készleteibe.

Előfordulhat például, hogy rendelkezik a keretrendszert alkotó összetevők gyűjteményével, és egy másik összetevőkészlettel, amely a felhasználó számára elérhető szolgáltatást alkotja. Ezután a kapcsolódó összetevők minden csoportjához tegye fel a következő kérdéseket:

  • Számíthatok a csapatok számára létrehozott készletek gyakori beadásaira?

  • Egyetlen csapat felel a teljes készletért?

  • Egyetlen készlet esetén van közös kiadási ütem?

Tapasztalataink szerint a forrásösszetétel használata a leghatékonyabb az egyetlen csapat vagy egy kapcsolódó csoport által kezelt kapcsolódó projektek esetében. Ezzel szemben a bináris összetétel előnyösnek bizonyul a nyílt forráskódú szoftverek, a külső függőségek (távoli vagy izolált csapatok összetevői) és a független megosztott összetevők esetében.