Включване на зависимости в стратегия за разклоняване?

Търся опростяване на текущото хранилище на изходния код и настройката на решението. В момента това е много сложно и огромно и правенето на промени дори в най-простия код може да отнеме много време.

За по-голяма простота, да кажем, че имам следната настройка:

  • Имам 1 проект за уебсайт (W1)
  • Имам 2 проекта за уеб услуги (S1, S2)
  • Имам 3 библиотечни проекта за клас (L1, L2, L3)

Те се управляват от 3 решения:

  • 1 решение, съдържащо W1, L1, L2, L3 и използващо сервизни препратки към S1 и S2
  • 1 разтвор, съдържащ S1, L1, L2, L3
  • 1 разтвор, съдържащ S2, L1, L2, L3

Всичко това понастоящем се контролира от едно хранилище на изходен код, в което прилагам схема за разклоняване, която използва клон Main, Development и Release по всяко време.

Както можете да видите, библиотечните проекти се споменават многократно и, както може да се очаква, това понякога води до сблъсъци, когато множество разработчици работят върху една и съща библиотека. Както споменах и преди, в действителност имам много повече библиотечни проекти. В момента има решения, които съдържат над 50 проекта и почти всички решения съдържат едни и същи проекти. За да ги направя по-поддържаеми, бих искал да преместя библиотечните проекти в тяхното собствено решение и да създам NuGet пакети от тях.

Освен това имам три среди, в които се разполагат нещата:

  • TST среда, към която се изгражда клонът за развитие, се прилага ежедневно
  • QA среда, към която се изгражда клонът Release, се насочва
  • ЖИВА среда, към която се изгражда основният клон, се насочва

Проблемът, с който се сблъсквам, е, че не виждам как трябва да включа пакетите NuGet в тази стратегия за внедряване, тъй като разработката се извършва на всички проекти по време на един спринт и ако разработчик проверява клон Release или Main клон за създаване на актуална корекция, не искам той да обърка посочените NuGet пакети и случайно да въведе пакет за разработка в главния клон.

От целта на изграждането е възможно просто да се използва същата стратегия за разклоняване, когато се изграждат библиотечните проекти и да се публикуват NuGet пакетите на всеки клон в различно хранилище. От гледна точка на разработчици, не знам как мога лесно да превключвам между множество хранилища. Не мога да притеснявам разработчиците с изискване да променят своя URL адрес на хранилище на NuGet при плащане на различен проект или клон.

Така че въпросът е: какъв е правилният начин за активно разработване на набор от библиотеки и проекти за преден край паралелно?

Не мисля, че това, което искам да правя, е толкова трудно или че само аз искам това. И все пак не намирам подходяща документация за това. Дали гледам на това напълно погрешно?


person Jensen    schedule 28.06.2014    source източник


Отговори (1)


Отговорът всъщност е доста прост.

В моя случай най-доброто решение е да се дефинират различни източници на пакети за клон в конфигурационен файл на NuGet.

<packageSources>
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" />
    <add key="MyRepo - ES" value="http://MyRepo/ES/nuget" />
</packageSources>

Мога да създам различно NuGet хранилище за всеки клон, да създам различен NuGet конфигурационен файл за всеки клон и просто да дефинирам правилния URL адрес на хранилището в този конфигурационен файл.

person Jensen    schedule 01.07.2014
comment
Страхотно решение. Човек може също да добави източник на пакет за (напр.) клон stable като резервен вариант за онези пакети, които не са в процес на разработка в клон на функция, който има свой собствен източник на пакет. - person Anton Tykhyy; 10.02.2018