MaxLevs
@MaxLevs

Как грамотно организовать хранение исходного кода и сборку NuGet-пакетов в Gitlab?

Имею в распоряжении машинку с GitLab. Хочу в нём хранить NuGet-пакеты вместе c исходным кодом.

С техническими нюансами заливания пакетов в gitlab знаком.
Вопрос возникает в организации логической структуры проектов и групп. Каковы лучшие / распространённые практики?

Текущая идея: одна "жирная" группа c проектами для пакетов внутри. Например:
MyCompany
├ MyCompany.Common.Package.First
├ MyCompany.Common.Package.Second
├ MyCompany.Utills.Package.Third
└MyCompany.Utills.Package.Fourth

Но возникают вопросы:
  • Как назвать группу? Префиксом названий пакетов (что-то вроде названия предприятия)? Или альтернативные варианты? Как было у вас?
  • Как называть проекты? Всегда полными именами пакетов? Не будет ли проблем из-за длинных имен/путей? Альтернативные подходы? Как было у вас?
  • Стоит ли задавать в пути проекта имя также с заглавными буквами или оставлять автосгенерированное? (по умолчанию gitlab заменяет все заглавные буквы в пути на строчные, и при клонировании дефолтное название директории берется из пути, его можно заменять на произвольное, но какие подводные?)
  • В каких случаях имеет смысл делать подгруппы для пакетов? И имеет ли вообще смысл? Как было у вас?


Было бы интересно прочитать про ваш опыт в этом вопросе.
  • Вопрос задан
  • 95 просмотров
Пригласить эксперта
Ответы на вопрос 2
@d-stream
Готовые решения - не подаю, но...
Ну хранить бинарные это в гитлабе - по мне не самая лучшая идея. Идеологически пакеты - это результаты а не исходный материал. Как один из вариантов - использовать внешнее хранилище. К примеру sonatype nexus. Притом он умеет и не только в .nuget. Бонусом - его умение полноценно поддерживать nuget-api. То есть не возникнет вопросов при использовании пакетов и восстановлении транзитивных зависимостей.
Конечно в .nuspec можно и нужно заполнять честно Видимо да, корнем будет Company или нечто подобное для группы компаний.
Дальше видимо отдельная ветвь нечто совсем общего для всех продуктов со своим ветвлением на lib/utils/helpers/etc и ветвления на продукты, где далее опять же нечто общее для всех версий и далее ветвление по версиям и дальше уже опять же modules/libs/utils

(кстати внутреннюю делёжку можно подсмотреть со стороны самой структуры дерева в nuget (рекомендуемая структура target от ms)

То бишь в итоге получится нечто типа такого:
Brand
 - CommonBrandSubTree
   - *
 - Subbrands
   - SubbrandsCommon
     - * 
     - ProductX 
       - ProductCommon
       - *
     - ProductY 
       - ProductCommon
       - *
________
* - это то самое lib/tools/frameworks/etc


Притом не стоит бояться слишком разветвлённого дерева - хотя на первом этапе это и будет выглядеть чрезмерно переинженеренным. Зато потом не придётся его ломать и ветвить на ходу.

Ну а смысл в общем-то есть: у среднего человека мгновенная память/восприятие способна охватить "за раз" 5-9 объектов и исходя из этого максимально комфортной структурой окажется дерево, где на каждом уровне будет видно где-то по 5-9 объектов.

Естественно волшебных гениев не существует и самую идеальную структуру не создать. Но можно посмотреть на те же имена от ms - где более-менее просматривается что-то подобное, но с итерациями к подходу (ветвление по платформам, архитектурам начали появляться попозже и т.п.)

с длиной имён путей/файлов - да можно огрести чуть дальше - на уровне сборки - win-раннеры не умеют в \\?\driveletter и воспользоваться вариантом длины пути в 32767 символов не выйдет...

p.s. ну и по-любому морально стоит готовиться к какому-то кардинальному моменту, когда захочется начать новое дерево с нуля - этакую v.2.0 (возможно стартовав такое уже в другой компании))
Ответ написан
Комментировать
В GitLab есть встроенное хранилище NuGet пакетов: https://docs.gitlab.com/ee/user/packages/nuget_rep...
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы