Ну как же, колбэки поддерживаются и обрабатываются также, как и команды.
Хранение состояний тоже есть - те же роли пользователя и его языковые предпочтения (которые устанавливаются отдельной командой). Для начала и как демонстрация - этого вполне должно хватить, как мне кажется.
Но, вероятно, надо было чуть более подробно рассказать об этом в статье, да :)
Теперь мы, как разработчики, сами контролируем происходящее и имеем 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# :(
Или, всё-таки, есть?
Бред полнейший. Очень глупо дискриминировать и ограничивать людей только по IP-адресу.
Сервис должен быть для пользователей, а не против… как и государство, кстати 8-)
Ммм.. новый функционал весь сводится к написанию классов команд и хендлеров с реализацией... всего одного интерфейса в каждом :)
Если нужно будет задействовать БД, то еще придётся дописать сущности и репозитории, что логично.
Ну как же, колбэки поддерживаются и обрабатываются также, как и команды.
Хранение состояний тоже есть - те же роли пользователя и его языковые предпочтения (которые устанавливаются отдельной командой). Для начала и как демонстрация - этого вполне должно хватить, как мне кажется.
Но, вероятно, надо было чуть более подробно рассказать об этом в статье, да :)
В контексте примера и данной статьи - ничего.
А вы? :)
Профит описан в статье и в первой половине доклада https://www.youtube.com/watch?v=yaQsQvPwlvg :)
Теперь мы, как разработчики, сами контролируем происходящее и имеем Dockerfile для настройки, под какое окружение нужно собирать решение, какие библиотеки подключать и др. А не использовать единый сферический базовый образ от DevOps.
Конвенции всего две и разработчику достаточно выбрать нужную. Более того, идём к тому, чтобы осталась только одна конвенция. Все новые сервисы - только SemVer.
Да, получился унифицированный вариант старого пайплайна без вороха локальных решений, которые были раньше.
Она помогает более детально, при необходимости, отнестись к сборке решений и пройти ревью.
Docker нам помог, безусловно. Но и общий конвеер тоже - раньше, чтобы добавить проекту возможность запуска интеграционных тестов с поднятием БД, скажем, в Docker, нужно было идти к DevOps и просить добавить новый шаг сборки в TeamCity. То же самое и при создании новых сервисов - мы уменьшили TTM.
Это применимо к абсолютно любой общей библиотеке, да :)
Что ж поделать, жизнь такая. Возможно, у вас очень изощрённые требования.
Не уверен, что в TeamCity это есть. Ну кроме чужеродного нам Kotlin DSL.
Бесспорно
В рамках билда решения (Solution) мы можем получить N сервисов для деплоя в Docker (монолит, что поделать) - для этого мы и пишем эти N Dockerfile'ов :)
Отличное замечание! В компании много сервисов, относительно много legacy, настроенного много лет назад. На Linux/Docker мы только недавно перевели все сервисы и теперь у нас есть более удобный и единообразный способ настройки билда.
Так отлично же! Был бы рад узнать Вашу историю и проблемы, с которыми столкнулись :)
Наши проблемы:
Более чёткий ошибок сборки (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. Ну и размер батча тоже влияет на скорость выгрузки.
Или, всё-таки, есть?
например, Sony Reader 650 при том же размере экрана поменьше будет
Сервис должен быть для пользователей, а не против… как и государство, кстати 8-)
а то как же без Основного закона… :)