M>Планируется внутреннее приложение (.net core/react + mssql), доступ будет по АД. OS: не точно, но планируется винда
M>Какие нынче тренды?
Вместо React есть смысл посмотреть Blazor Web Assembly.

M>1. максимально простое разворачивание. Сейчас в другом проекте из гитхаба из нужной ветки вручную создается через дженкинс билд и деплоится на нужный стенд и накатываются миграции.
M> Хочется чтобы билды сами создавались
Это требует поддержки со стороны движка CI/CD. В GitHub для этих целей есть github actions, который, собственно, заменяет весь функционал Jenkins.
Но, т.к. github у вас, по всей видимости, облачный, то не факт, что этот вариант вам подойдет.
За Jenkins не скажу, но, например, TeamCity/Bamboo умеют отслеживать изменения в ветках remote-репозитория и запускать билды по определенным событиям (e.g. push в ветку). Там этот функционал называется тригерами.
В GitLab (который, кстати, можно развернуть standalone, в отличие от GitHub) есть аналог github actions — gitlab CI/CD, который тесно проинтегрирован с git. Там билд (pipiline в терминах GitLab) можно запустить
практически по любому событию в репозитории (push в ветку, создание MR, принятие MR и т.п.)

M>и миграции накатывались. ?
Это делается либо отдельным шагом билда, который готовит и накатывает на БД скрипты обновления.
Либо, прямо в коде при запуске приложения.
У нас, например, используется EF Core+Migrations и подход смешанный.
На LOCAL/TEST/STAGE скрипты накатываются автоматически при старте приложения.
Для PROD готовятся в виде SQL-архива и накатываются вручную ради большего контроля (плюс есть нюансы с созданием/ребилдом индексов на большой PROD БД — там бывает нужен некоторый ручной тюнинг).

M>2. первичный деплой максимально простой. а то часто бывает локально всё работает, а на прод деплоишь первый раз и пляшешь там с бубном. Я так понимаю докер решает эти проблемы? локально настроить и потом можно просто его скопировать на нужный сервер, просто поменяв нужный конфиг?
Нет. Докер эти проблемы полностью не уберет.
Но он дает уверенность, что артифакт (образ), собранный и проверенный на TEST-контуре — это тот же самый бинарный код, что покатится дальше, на STAGE/PROD.
Но проблемы корректной конфигурации, настройки сетевых доступов, логины/пароли/сертификаты для подключения к внешним сервисам — здесь Docker никак не поможет.
Из практики добрая половина ошибок развертывания — это где-то не прокрутили сетевую дырку наружу, где-то забыли создать пользователя для БД или прописали неверный пароль.

M> сразу вопрос по докеру. там просто зайти на hub.docker зайти можно или есть варианты лучше?
Обычно для внутренних разработок разворачивают in-house копию докер-хаба.
Что, логично, т.к. вряд ли вы захотите, чтобы образы ваших корпоративных приложений были доступны всему интернету.
Здесь, опять же, вариантов много. Гуглить "local docker registry".
Например, в том же GitLab есть встроенные docker и package registry.

M>3. как настроить базы, чтобы если один разработчик поменял разработческую базу (удалил столбец к примеру) и не запушал еще изменения другие могли работать, а не ждать пока изменения попадут в гит?
M> думал, в идеале, иметь локальные базы каждому разработчику, но тогда вопрос как настроить репликацию мастер данных (в системе много мастер данных, а их заливают в прод)
Имхо, локальная БД — самый нормальный вариант.
Я по возможности стараюсь сделать так, чтобы все инфраструктурные сервисы (БД, очереди, кэши, S3 и т.п.) разработчик мог развернуть у себя локально в автоматическом режиме.
Docker-compose с этим отлично справляется.

Как вариант — выделенная БД под каждого разработчика на общем MSSQL-сервере + jobs, которые периодически или по требованию актуализируют master-данные в этих БД.
Впрочем, без понимания особенностей ваших данных здесь сложно подсказать что-то дельное.

M>4. дженкинс лучше иметь один на компанию или под разные проекты свой?
Это от размера компании/проектов зависит.
Имхо, лучше начать с одного общего и разделять по мере необходимости.

M>5. очень много слышал про trunk development. как он? сейчас просто каждый в своей ветке делает (часто фронт с бэком в одной) и потом сливают и потом ручками делают деплой и ручками меняют версию
А что вы лично хотите получить от trunk development?
Придется менять весь текущий процесс разработки — от способа постановки/декомпозиции задач, до деплоя и эксплуатации.
Стоит ли оно того в ваших реалиях?

Здравствуйте, RushDevion, Вы писали:

M>>Планируется внутреннее приложение (.net core/react + mssql), доступ будет по АД. OS: не точно, но планируется винда
M>>Какие нынче тренды?
RD>Вместо React есть смысл посмотреть Blazor Web Assembly.

а какие аргументы в пользу блэйзор? не нужно отдельного фронтендера или блэйзор в чем-то лучше реакта?

M>>1. максимально простое разворачивание. Сейчас в другом проекте из гитхаба из нужной ветки вручную создается через дженкинс билд и деплоится на нужный стенд и накатываются миграции.
M>> Хочется чтобы билды сами создавались
RD>Это требует поддержки со стороны движка CI/CD. В GitHub для этих целей есть github actions, который, собственно, заменяет весь функционал Jenkins.

github actions они только в десктопной версии?



а еще вопрос вот такой.
решили попробовать микросервисную архитектуру впервые. это нынче еще в тренде?

и если в тренде то вопрос такой. чтобы сократить время на изучение настроек кубера, можно же вначале написать микросервисный апп и запустить это не в контейнерах в иис?

M>а какие аргументы в пользу блэйзор? не нужно отдельного фронтендера или блэйзор в чем-то лучше реакта?

1. Унифицированный coding experience идентичный обычной разработке на .net. Не нужен отдельный редактор (VsCode, WebStorm), не нужно заморачиваться со сборкой (npm/webpack/rollup), не нужен выделенный фронтендер (если, конечно, нет упора на pixel perfect-верстку и всякие css/js эффекты), достаточно будет фулстека с минимальными навыками верстки.
2. Это WebAssembly. Бинарный код, по сути. Небольшой по размеру и очень быстрый.
3. Достаточно стабильный фреймворк, в отличие от реакта, где каждые пол-года что-нибудь да меняется.

M>github actions они только в десктопной версии?
Десктопная версия — это GitHub Desktop что ли? Это просто UI-клиент для гита. А тебе нужна серверная часть, которая у них в облаке крутится.
Т.о. GitHub actions есть только в облачной версии. В том смысле, что GitHub — он сам по себе облачный. Его нельзя развернуть self-hosted. По крайней мере, я о таком варианте не слышал.
Есть Gitea, который заявляет поддержку GitHub actions, но насколько он рабочий, не скажу, не пользовался.

M>а еще вопрос вот такой.
M>решили попробовать микросервисную архитектуру впервые. это нынче еще в тренде?
До кучи возьмите акторный фреймворк, in-memory grid и пишите на F#. Можно ещё AI/Chat GPT прикрутить. Это тоже сейчас модно.
Это я к тому, что строить архитектуру по принципу "в тренде/не в тренде", это путь боли и отчаяния.

M>и если в тренде то вопрос такой. чтобы сократить время на изучение настроек кубера, можно же вначале написать микросервисный апп и запустить это не в контейнерах в иис?
Можно, но бесшовно его потом не перенесешь. Все равно придется заморочиться и с настройками кубера, и со сборкой образов, и с выпиливанием iis-специфичного функционала.

Здравствуйте, RushDevion, Вы писали:

M>>а какие аргументы в пользу блэйзор? не нужно отдельного фронтендера или блэйзор в чем-то лучше реакта?

RD>1. Унифицированный coding experience идентичный обычной разработке на .net. Не нужен отдельный редактор (VsCode, WebStorm), не нужно заморачиваться со сборкой (npm/webpack/rollup), не нужен выделенный фронтендер (если, конечно, нет упора на pixel perfect-верстку и всякие css/js эффекты), достаточно будет фулстека с минимальными навыками верстки.
RD>2. Это WebAssembly. Бинарный код, по сути. Небольшой по размеру и очень быстрый.
RD>3. Достаточно стабильный фреймворк, в отличие от реакта, где каждые пол-года что-нибудь да меняется.

Я думал что это сырое тормозное говно, годящееся только для hello world. Я не прав? Вы его и правда используете?
Просто для самообразования.

bnk>Я думал что это сырое тормозное говно, годящееся только для hello world. Я не прав? Вы его и правда используете?
bnk>Просто для самообразования.
Да, я тоже так думал поначалу.
Но сейчас у нас уже с десяток админок на нем работает. Очень удобно, как оказалось.
Не представляю, как бы мы подобное на angular/react/vue поддерживали.
Самые большие тормоза поначалу были от visual studio: долгая сборка, совершенно уродский hot-reload, подвисания при редактировании вьшек.
Но в новых версиях с этим с этим стало гораздо лучше. Всё ещё не идеально, но пользоваться вполне можно.

Здравствуйте, RushDevion, Вы писали:


bnk>>Я думал что это сырое тормозное говно, годящееся только для hello world. Я не прав? Вы его и правда используете?
bnk>>Просто для самообразования.
RD>Да, я тоже так думал поначалу.
RD>Но сейчас у нас уже с десяток админок на нем работает. Очень удобно, как оказалось.
ну вы пришли к этому не потому что у вас не было фронтендендеров и внезапно упали проекты где нужен фронт или что фронту не было регулярной загрузки?

RD>Не представляю, как бы мы подобное на angular/react/vue поддерживали.

кхм, интересно, а что на реакте сложно поддерживать, а легко в blazor? или не представляете как бэкендер с небольшими знаниями фронта сделал такое в реакте?

M>RD>Не представляю, как бы мы подобное на angular/react/vue поддерживали.

M>кхм, интересно, а что на реакте сложно поддерживать, а легко в blazor? или не представляете как бэкендер с небольшими знаниями фронта сделал такое в реакте?

Я никого не агитирую, просто рассказываю про свой опыт.
Хз, как там у вас в команде. Может вы все PHP-шники и JS-шники с 20-летним стажем.
А у нас так сложилось, что команда — это чисто бэкэнд разработчики.
React/Vue мы, собственно, тоже можем. Но все отмечают, что пилить новые админки на Blazor гораздо приятнее чем ковырять старые на Knockout и React.

Смысл в том, что стек один и тот же. Ты пишешь бэкэнд на .NET/C# и фронт пишешь на нем же. А JS там практически не нужен.
И все действо происходит в едином солюшене в VS, ты по F5 запускаешь и API-шку, и фоновые службы, и фронтовую часть.
Не нужно постоянно переключаться между VS и WebStorm.
Да, в VS как бы тоже можно вести react-проект, но по сравнению с WebStorm — это как бежать на костылях за велосипедистом.
Плюсом, не нужны гигабайты node_modules (с которыми, к слову, нередко были проблемы при скачке на блид-серверах).
А если хочешь переиспользовать собственные UI-компоненты — заворачиваешь в те же nuget-пакеты, что обычный C# код.

Здравствуйте, merge, Вы писали:

M>Всем привет!

M>Планируется внутреннее приложение (.net core/react + mssql), доступ будет по АД. OS: не точно, но планируется винда
M>Какие нынче тренды?

M>что интересует:

M>1. максимально простое разворачивание. Сейчас в другом проекте из гитхаба из нужной ветки вручную создается через дженкинс билд и деплоится на нужный стенд и накатываются миграции.
M> Хочется чтобы билды сами создавались и миграции накатывались. Как такое организовать? Или может есть варианты лучше сейчас?

Я бы использовал gitlab и все настроил из него.

M>2. первичный деплой максимально простой. а то часто бывает локально всё работает, а на прод деплоишь первый раз и пляшешь там с бубном. Я так понимаю докер решает эти проблемы? локально настроить и потом можно просто его скопировать на нужный сервер, просто поменяв нужный конфиг?
M> сразу вопрос по докеру. там просто зайти на hub.docker зайти можно или есть варианты лучше?

Можно один раз настроить IIS если под виндой. Или же сделать скрипты для его настройки.

M>3. как настроить базы, чтобы если один разработчик поменял разработческую базу (удалил столбец к примеру) и не запушал еще изменения другие могли работать, а не ждать пока изменения попадут в гит?
M> думал, в идеале, иметь локальные базы каждому разработчику, но тогда вопрос как настроить репликацию мастер данных (в системе много мастер данных, а их заливают в прод)

Обычно у каждого разраба своя, а потом миграции накатываются при мерже ветки и деплое.

Здравствуйте, merge, Вы писали:

M>Всем привет!

M>Планируется внутреннее приложение (.net core/react + mssql), доступ будет по АД. OS: не точно, но планируется винда
M>Какие нынче тренды?

M>что интересует:

M>1. максимально простое разворачивание. Сейчас в другом проекте из гитхаба из нужной ветки вручную создается через дженкинс билд и деплоится на нужный стенд и накатываются миграции.
M> Хочется чтобы билды сами создавались и миграции накатывались. Как такое организовать? Или может есть варианты лучше сейчас?
Использовать менеджеры конфигураций: ansible, paper и т.д.

M>2. первичный деплой максимально простой. а то часто бывает локально всё работает, а на прод деплоишь первый раз и пляшешь там с бубном. Я так понимаю докер решает эти проблемы? локально настроить и потом можно просто его скопировать на нужный сервер, просто поменяв нужный конфиг?
Опять это решают менеджеры конфигураций.

M> сразу вопрос по докеру. там просто зайти на hub.docker зайти можно или есть варианты лучше?
M>3. как настроить базы, чтобы если один разработчик поменял разработческую базу (удалил столбец к примеру) и не запушал еще изменения другие могли работать, а не ждать пока изменения попадут в гит?
M> думал, в идеале, иметь локальные базы каждому разработчику, но тогда вопрос как настроить репликацию мастер данных (в системе много мастер данных, а их заливают в прод)
Да, каждому разработчику лучше иметь свою локальную базу для разработки он же и пишет скрипты миграции.

M>4. дженкинс лучше иметь один на компанию или под разные проекты свой?
Дженкинс кривой, косой, дерганный. Найдите что ни будь получше.

M>5. очень много слышал про trunk development. как он? сейчас просто каждый в своей ветке делает (часто фронт с бэком в одной) и потом сливают и потом ручками делают деплой и ручками меняют версию
Не знаю, не пробовал.

Здравствуйте, merge, Вы писали:

M>1. максимально простое разворачивание. Сейчас в другом проекте из гитхаба из нужной ветки вручную создается через дженкинс билд и деплоится на нужный стенд и накатываются миграции.
M> Хочется чтобы билды сами создавались и миграции накатывались. Как такое организовать? Или может есть варианты лучше сейчас?

А в чем загвоздка? Вроде все системы CI/CD умеют создавать новый билд на пул-реквест или коммит. Или я не понял вопроса.

M>2. первичный деплой максимально простой. а то часто бывает локально всё работает, а на прод деплоишь первый раз и пляшешь там с бубном. Я так понимаю докер решает эти проблемы? локально настроить и потом можно просто его скопировать на нужный сервер, просто поменяв нужный конфиг?
M> сразу вопрос по докеру. там просто зайти на hub.docker зайти можно или есть варианты лучше?

По мне так это особо не лечится. Непонятно чем тут может помочь докер.
Просто скрипт который все собирает и деплоит должен быть достаточно аккуратным, и не должно быть никаких ручных действий при билде или деплое.
Подразумевается, что есть что-то куда это все деплоится после билда. И это не продакшен, а его копия (dev environment)

M>3. как настроить базы, чтобы если один разработчик поменял разработческую базу (удалил столбец к примеру) и не запушал еще изменения другие могли работать, а не ждать пока изменения попадут в гит?
M> думал, в идеале, иметь локальные базы каждому разработчику, но тогда вопрос как настроить репликацию мастер данных (в системе много мастер данных, а их заливают в прод)

Ну а насколько они большие, и насколько часто меняются мастер-данные? Они вообще важны для разработки?
Честно говоря не вижу особой проблемы сделать локальную базу для каждого разработчика.

M>4. дженкинс лучше иметь один на компанию или под разные проекты свой?

У вас можно использовать что-нибудь получше чем дженкинс, нафига это убожество?
Ну типа мелкомягкого Azure DevOps например..

M>5. очень много слышал про trunk development. как он? сейчас просто каждый в своей ветке делает (часто фронт с бэком в одной) и потом сливают и потом ручками делают деплой и ручками меняют версию

Насколько я понимаю это просто значит что на каждый коммит (или пул реквест) имеем новый билд (с новой версией)? Вроде гуд.
Непонятно зачем что-то делать руками, если можно этого не делать.