Комментарии 12
Сборка и тесты выполняются на том же окружении, что и продуктивное.
Каким образом это следствие перехода на Nuke (или любой другой способ описания билда)?
Все сервисы собираются и тестируются одинаково, что позволяет упростить их поддержку и обслуживание.
Как это сочетается с
Разработчики теперь сами настраивают процесс сборки так, как нужно им
?
Не подумайте, я люблю описание (много чего) в коде, я просто не понимаю, как конкретно Nuke достигает описанных преимуществ.
Билд идёт в Docker'е, что сразу приближает нас к тому, как это потом в том же Docker'e будет развёрнуто. Раньше была ситуация, что билд шёл на Windows, а потом деплоили в Linux.
Разработчики теперь контролируют (пишут) Dockerfile'ы для всех точек деплоя (а не пользуются каким-то универсальным и перегруженным вариантов от DevOps-коллег), настраивают версионирование и другие фишки. Раньше это всё делали DevOps и не всегда прозрачно. Ну и code-ревью никто не отменял - раньше оно было невозможно.
В то же самое время, наша общая библиотека поставляет нам обобщённый конвейер сборки (там где картинка в статье) - разработчикам остаётся разобраться с Dockerfile'ми и переопределить то, что им хочется. Опять же пример такого представлен в последнем примере кода - вся магия скрыта за Nuget-пакетом.
Билд идёт в Docker'е
Для того, чтобы билд шел в докере, нужно, чтобы это поддерживал билд-сервер. Nuke, как и любой другой скрипт, для этого лишь сильно вспомогательный инструмент.
Разработчики теперь контролируют (пишут) Dockerfile'ы для всех точек деплоя
Так билда или деплоя?
Ну и code-ревью никто не отменял - раньше оно было невозможно.
Что вам раньше запрещало класть dockerfile в версионник?
В то же самое время, наша общая библиотека поставляет нам обобщённый конвейер сборки
В этот момент мы и возвращаемся к вопросу "все собирается одинаково" vs "каждый настраивает, как хочет". Как человек, который поддерживает аналогичный обобщенный компонент для деплоя, я много плохих слов могу тут сказать.
Для того, чтобы билд шел в докере, нужно, чтобы это поддерживал билд-сервер. Nuke, как и любой другой скрипт, для этого лишь сильно вспомогательный инструмент.
Бесспорно
Так билда или деплоя?
В рамках билда решения (Solution) мы можем получить N сервисов для деплоя в Docker (монолит, что поделать) - для этого мы и пишем эти N Dockerfile'ов :)
Что вам раньше запрещало класть dockerfile в версионник?
Отличное замечание! В компании много сервисов, относительно много legacy, настроенного много лет назад. На Linux/Docker мы только недавно перевели все сервисы и теперь у нас есть более удобный и единообразный способ настройки билда.
В этот момент мы и возвращаемся к вопросу "все собирается одинаково" vs "каждый настраивает, как хочет". Как человек, который поддерживает аналогичный обобщенный компонент для деплоя, я много плохих слов могу тут сказать.
Так отлично же! Был бы рад узнать Вашу историю и проблемы, с которыми столкнулись :)
Наши проблемы:
Более чёткий ошибок сборки (dotnet build) в Docker'е с агентом сборки в TeamCity - работаем над этим.
Наш вариант версионирования GitFlow - решили, просто нужно было скурпулёзно перенести всю эту древнюю логику вычисления версий.
А насчёт "все собирается одинаково" vs "каждый настраивает, как хочет" - наш конвеер довольно простой (сборка - отправка артефактов - интеграционные тесты - создание релиза) и все сервисы хорошо на него легли. Конвеер общий для всех, но поддающийся конфигурированию там, где это нужно.
Ну и, в конце концов, раньше все эти многочисленные скрипты и шаги сборки писали DevOps'ы - вряд ли у них был процесс ревью кода, да и кто знает, под каким SDK и с какими подключёнными библиотеками это всё происходило.
В рамках билда решения (Solution) мы можем получить N сервисов для деплоя в Docker
Тогда Nuke, как и любая другая билд-система, никак на это не влияет.
На Linux/Docker мы только недавно перевели все сервисы
Ну то есть ваш профит - он от того, что вы сервисы перевели на докер, а не от того, что вы Nuke взяли.
Был бы рад узнать Вашу историю и проблемы, с которыми столкнулись
Основная проблема очень простая: есть общий компонент для деплоя, он использутся в 15 сервисах, внезапно одному из них нужна функциональность, которой в этом компоненте нет. Дальше веселье.
Ну и, в конце концов, раньше все эти многочисленные скрипты и шаги сборки писали DevOps'ы - вряд ли у них был процесс ревью кода
В моем скромном понимании весь смысл Dev в DevOps как раз в том, что они пользуются теми же практиками с ревью и версионированием. А если еще точнее, то это не кто-то отдельный от вас должен быть...
Тогда Nuke, как и любая другая билд-система, никак на это не влияет.
Она помогает более детально, при необходимости, отнестись к сборке решений и пройти ревью.
Ну то есть ваш профит - он от того, что вы сервисы перевели на докер, а не от того, что вы Nuke взяли.
Docker нам помог, безусловно. Но и общий конвеер тоже - раньше, чтобы добавить проекту возможность запуска интеграционных тестов с поднятием БД, скажем, в Docker, нужно было идти к DevOps и просить добавить новый шаг сборки в TeamCity. То же самое и при создании новых сервисов - мы уменьшили TTM.
Основная проблема очень простая: есть общий компонент для деплоя, он использутся в 15 сервисах, внезапно одному из них нужна функциональность, которой в этом компоненте нет. Дальше веселье.
Это применимо к абсолютно любой общей библиотеке, да :)
Что ж поделать, жизнь такая. Возможно, у вас очень изощрённые требования.
В моем скромном понимании весь смысл Dev в DevOps как раз в том, что они пользуются теми же практиками с ревью и версионированием. А если еще точнее, то это не кто-то отдельный от вас должен быть...
Не уверен, что в TeamCity это есть. Ну кроме чужеродного нам Kotlin DSL.
Она помогает более детально, при необходимости, отнестись к сборке решений и пройти ревью.
Для докерфайлов, используемых для деплоя? Нет, не помогает. Докерфайлы как до Nuke должны были лежать в репо, так и после. Ничего не поменялось (не должно было поменяться).
Но и общий конвеер тоже - раньше, чтобы добавить проекту возможность запуска интеграционных тестов с поднятием БД, скажем, в Docker, нужно было идти к DevOps и просить добавить новый шаг сборки в TeamCity.
Вот снова. Вам не общий конвеер помог. Вам помогло то, что ваши девопсы дали вам права управлять сборкой из вашего кода. Общий это конвеер или десять разных, на nuke или на PS - уже не важно.
Это применимо к абсолютно любой общей библиотеке, да
Просто конкретно в случае билда/деплоя иногда оказывается, что профит от общей библиотеки меньше, чем оверхед.
Не уверен, что в TeamCity это есть.
Так при чем тут то, что есть или нет в TeamCity? DevOps могут пользоваться всеми теми же инструментами, что и вы. Если вы смогли управлять билдом из Nuke, то и они могут.
Не уверен, что в TeamCity это есть. Ну кроме чужеродного нам Kotlin DSL.
А что мешает хранить код buildStep-ов в git и обновлять его по тригеру?
Разработчики теперь контролируют (пишут) Dockerfile'ы для всех точек деплоя (а не пользуются каким-то универсальным и перегруженным вариантов от DevOps-коллег), настраивают версионирование и другие фишки
По сути ничего же и не изменится. Почти наверняка в компании принято N конвенций версионировния, которые в скрипт сборки были зашиты. Дав разработчику свободу выбора при построении пайплайна сборки, вы все равно не освободите его от существующих требований.
На выходе либо получится тот же старый пайплайн, но написанный на другом языке, либо улей локальных решений, не соответствующих требованиям компании, которые потом все устанут приводить к общему знаменателю
Почти наверняка в компании принято N конвенций версионировния, которые в скрипт сборки были зашиты. Дав разработчику свободу выбора при построении пайплайна сборки, вы все равно не освободите его от существующих требований.
Конвенции всего две и разработчику достаточно выбрать нужную. Более того, идём к тому, чтобы осталась только одна конвенция. Все новые сервисы - только SemVer.
На выходе либо получится тот же старый пайплайн, но написанный на другом языке, либо улей локальных решений, не соответствующих требованиям компании, которые потом все устанут приводить к общему знаменателю
Да, получился унифицированный вариант старого пайплайна без вороха локальных решений, которые были раньше.
Т.е. у разработки в целом ничего не изменилось, был "один путь", "один путь" и остался. В чем профит тогда?
Профит описан в статье и в первой половине доклада https://www.youtube.com/watch?v=yaQsQvPwlvg :)
Теперь мы, как разработчики, сами контролируем происходящее и имеем Dockerfile для настройки, под какое окружение нужно собирать решение, какие библиотеки подключать и др. А не использовать единый сферический базовый образ от DevOps.
Сборка .NET решений через код на Nuke Build