Като компания, ние създаваме NuGet пакети от различни git репо в Azure DevOps. След като пакетът бъде тестван и одобрен, той трябва да бъде споделен в рамките на организацията Azure DevOps.
Все още се боря с настройката на тръбопровода за изграждане/издаване чрез използване на емисии на Azure DevOps. Пакетите трябва първо да станат достъпни за тестване, преди да бъдат споделени в организацията.
Въпреки че има много препоръки и най-добри практики, споделени от Microsoft, все още не мога да намеря работещо решение. Ще обясня решенията, които съм пробвал досега:
Решение А
Използване на един канал за цялата организация. Пакетите се изпращат автоматично към @local feed и към изгледа @prerelease и @release, след като тестването приключи. Тръбопроводът се използва, както следва:
- Работим според git-flow с разклонения за разработка, функция и главни.
- Изграждането на CI се задейства в клона за разработка
- Пакетът със суфикс за предварителна версия се изпраща към емисията @local.
- Тестовете за приемане се извършват в други инструменти чрез активиране на квадратчето за отметка преди пускане в мениджъра на пакети NuGet във Visual Studio.
- Когато пакетът бъде приет, се създава издание и се задейства нова компилация.
- Опаковката е избутана
Проблеми Решение A:
- Когато пакет бъде приет, той трябва да бъде повишен в изглед @release, но името на пакета все още съдържа суфикса -pre.
- Когато пакетът е приет, според мен не трябва да се изисква нова компилация, освен ако не можете да извършите това от клон за освобождаване може би?
- Въпреки че пакетът е видим само във визуално студио с предварителния суфикс, той може да бъде избутан със суфикса към @release изглед.
- Когато даден пакет се рекламира, той трябва да се копира и съхранява без суфикс.
Разтвор Б
Използване на специален канал за всяко git хранилище (препоръчано от Microsoft) и публикуване на NuGet пакети в този канал от CI компилации. Всеки пакет се изпраща към емисията @local без суфикс. Когато пакет е тестван и приет, пакетът се повишава до изгледа @release. Всеки специален канал е конфигуриран като източник нагоре (@release view), пакетите от изгледа на изданието ще бъдат „кеширани“ в общия канал, споделен в организацията между всички екипи за разработка.
Проблеми Решение B:
- Пакетите, които стават видими чрез източниците нагоре по веригата, се добавят/кешират само след като бъде извършено едно разполагане/сглобяване. Не можете да наложите това, когато пакет е повишен в изглед @release.
- Всички екипи за разработка трябва да се абонират във Visual Studio за всички емисии на NuGet, за да инсталират най-новата версия на пакет. (30 git repos = 30 емисии)
Общи въпроси:
- Работещ ли е git-flow, когато създаваме само NuGet пакети?
- Трябва ли да работим с предварителни пакети или да ги запазим в @pre-release изглед без суфикса?
- Чувствате се грешно да започнете нова компилация, за да имате пакет без суфикса. След като пакетът преди пускане бъде тестван, той трябва да бъде повишен само в изгледа за пускане.
- Трябва ли да изградим пакета в компилацията на CI и да използваме компилация за освобождаване, за да освободим пакета. Виждал съм хора, които използват PowerShell с променливи на средата, за да популяризират пакет от една версия в друга.
Знам, че има много въпроси, но от доста време се боря с този проблем. Надявам се, че някой може да ми даде добри предложения.
Благодаря!
