Pull to refresh
4
0
Aleksei Ermilov @alex_ozr

.NET developer

Send message

Ммм.. новый функционал весь сводится к написанию классов команд и хендлеров с реализацией... всего одного интерфейса в каждом :)

Если нужно будет задействовать БД, то еще придётся дописать сущности и репозитории, что логично.

Ну как же, колбэки поддерживаются и обрабатываются также, как и команды.

Хранение состояний тоже есть - те же роли пользователя и его языковые предпочтения (которые устанавливаются отдельной командой). Для начала и как демонстрация - этого вполне должно хватить, как мне кажется.

Но, вероятно, надо было чуть более подробно рассказать об этом в статье, да :)

В контексте примера и данной статьи - ничего.

А вы? :)

Профит описан в статье и в первой половине доклада https://www.youtube.com/watch?v=yaQsQvPwlvg :)

Теперь мы, как разработчики, сами контролируем происходящее и имеем Dockerfile для настройки, под какое окружение нужно собирать решение, какие библиотеки подключать и др. А не использовать единый сферический базовый образ от DevOps.

Почти наверняка в компании принято N конвенций версионировния, которые в скрипт сборки были зашиты. Дав разработчику свободу выбора при построении пайплайна сборки, вы все равно не освободите его от существующих требований.

Конвенции всего две и разработчику достаточно выбрать нужную. Более того, идём к тому, чтобы осталась только одна конвенция. Все новые сервисы - только SemVer.

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

Да, получился унифицированный вариант старого пайплайна без вороха локальных решений, которые были раньше.

Тогда Nuke, как и любая другая билд-система, никак на это не влияет.

Она помогает более детально, при необходимости, отнестись к сборке решений и пройти ревью.

Ну то есть ваш профит - он от того, что вы сервисы перевели на докер, а не от того, что вы Nuke взяли.

Docker нам помог, безусловно. Но и общий конвеер тоже - раньше, чтобы добавить проекту возможность запуска интеграционных тестов с поднятием БД, скажем, в Docker, нужно было идти к DevOps и просить добавить новый шаг сборки в TeamCity. То же самое и при создании новых сервисов - мы уменьшили TTM.

Основная проблема очень простая: есть общий компонент для деплоя, он использутся в 15 сервисах, внезапно одному из них нужна функциональность, которой в этом компоненте нет. Дальше веселье.

Это применимо к абсолютно любой общей библиотеке, да :)

Что ж поделать, жизнь такая. Возможно, у вас очень изощрённые требования.

В моем скромном понимании весь смысл Dev в DevOps как раз в том, что они пользуются теми же практиками с ревью и версионированием. А если еще точнее, то это не кто-то отдельный от вас должен быть...

Не уверен, что в TeamCity это есть. Ну кроме чужеродного нам Kotlin DSL.

Для того, чтобы билд шел в докере, нужно, чтобы это поддерживал билд-сервер. Nuke, как и любой другой скрипт, для этого лишь сильно вспомогательный инструмент.

Бесспорно

Так билда или деплоя?

В рамках билда решения (Solution) мы можем получить N сервисов для деплоя в Docker (монолит, что поделать) - для этого мы и пишем эти N Dockerfile'ов :)

Что вам раньше запрещало класть dockerfile в версионник?

Отличное замечание! В компании много сервисов, относительно много legacy, настроенного много лет назад. На Linux/Docker мы только недавно перевели все сервисы и теперь у нас есть более удобный и единообразный способ настройки билда.

В этот момент мы и возвращаемся к вопросу "все собирается одинаково" vs "каждый настраивает, как хочет". Как человек, который поддерживает аналогичный обобщенный компонент для деплоя, я много плохих слов могу тут сказать.

Так отлично же! Был бы рад узнать Вашу историю и проблемы, с которыми столкнулись :)

Наши проблемы:

  • Более чёткий ошибок сборки (dotnet build) в Docker'е с агентом сборки в TeamCity - работаем над этим.

  • Наш вариант версионирования GitFlow - решили, просто нужно было скурпулёзно перенести всю эту древнюю логику вычисления версий.

А насчёт "все собирается одинаково" vs "каждый настраивает, как хочет" - наш конвеер довольно простой (сборка - отправка артефактов - интеграционные тесты - создание релиза) и все сервисы хорошо на него легли. Конвеер общий для всех, но поддающийся конфигурированию там, где это нужно.

Ну и, в конце концов, раньше все эти многочисленные скрипты и шаги сборки писали DevOps'ы - вряд ли у них был процесс ревью кода, да и кто знает, под каким SDK и с какими подключёнными библиотеками это всё происходило.

Билд идёт в Docker'е, что сразу приближает нас к тому, как это потом в том же Docker'e будет развёрнуто. Раньше была ситуация, что билд шёл на Windows, а потом деплоили в Linux.

Разработчики теперь контролируют (пишут) Dockerfile'ы для всех точек деплоя (а не пользуются каким-то универсальным и перегруженным вариантов от DevOps-коллег), настраивают версионирование и другие фишки. Раньше это всё делали DevOps и не всегда прозрачно. Ну и code-ревью никто не отменял - раньше оно было невозможно.

В то же самое время, наша общая библиотека поставляет нам обобщённый конвейер сборки (там где картинка в статье) - разработчикам остаётся разобраться с Dockerfile'ми и переопределить то, что им хочется. Опять же пример такого представлен в последнем примере кода - вся магия скрыта за Nuget-пакетом.

В EF еще не завезли Bulk insert, к сожалению. Есть платный Entity Framework Extensions, но решили не использовать его по причинам платности/зарубежности.

AsNoTracking у нас используется на уровне реализации IDbReader (это есть в примерах кода).

Что касается времени выгрузки - у меня это заняло 1 сутки на 150ГиБ базу с 12 таблицами, 4 из которых по ±10,000,000 записей. Дольше всего, конечно, выгружались сами геоданные, тк они содержали маршруты для авто по всей стране и состояли из большого количества точек, да еще и конвертировались на лету из формата одной БД в другой. Пришлось даже сделать адаптивный размер батча при выгрузке, тк по 4к записей за раз с геоданными можно легко получить OutOfMemoryException. Ну и размер батча тоже влияет на скорость выгрузки.

Очень жаль, что убрали поддержку Visual Studio Setup Project… больше нет бесплатного удобного инструмента для создания установщиков с поддержкой user custom action'ов на c# :(
Или, всё-таки, есть?
Та же картина и в NYC. Просто на картах нигде дома и их номера не отображаются…
Кому надо, тоже могу добавить в дев-аккаунт. 10 человек.
Да даже дома и их номера на картах не отображаются в стандартном режиме — только дороги и одиноко стоящие в пустоте кафешки… независимо от страны.
а так — читалка в целом слишком большая для 6'' экрана :)
например, Sony Reader 650 при том же размере экрана поменьше будет
лучше бы экран больше сделали… как раз вместо огромного бесполезного куска пластика внизу с iPod-style кругляшкой-управлением :)
Бред полнейший. Очень глупо дискриминировать и ограничивать людей только по IP-адресу.
Сервис должен быть для пользователей, а не против… как и государство, кстати 8-)
Спасибо!
а то как же без Основного закона… :)
Софтина классная, но почему в ней нет Конституции РФ? :)
глянец итак везде… а c2d — вполне под любые задачи подходит… для 13'' малютки-то)
MBP 13'' — то, что надо! :)
1

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity

Specialization

Backend Developer
Senior
C#
.NET
Entity Framework
ASP.NET Web API
OOP
Git
Docker
SQL
PostgreSQL
SOLID