31 августа пройдет первая JVM-конференция от T-Банка в офисе компании Space. Будут доклады по Java- и Scala-стекам, обсуждение общих инженерных практик, много нетворкинга и активностей.
Я был бы очень рад, если бы главное меню показывалось по однократному нажатию ALT, как меню в большинстве прог в Винде. Но тут почему-то `Alt + \`, который ещё и не работает чаще всего ...
Но утверждение, что “ты должен всегда сначала писать тест, прежде чем писать код для продакшена, потому что в противном случае ты не соблюдаешь TDD” — это то, с чем я не согласен.
Но ведь оно верное, не написав тест вперёд, ты не следуешь TDD :)
Имхо, TDD супер, когда ты правишь баг. Сперва воспроизвёл, убедился, что это оно, а потом поправил прод код, и тест прошёл.
Но утверждение, что “ты должен всегда сначала писать тест, прежде чем писать код для продакшена, потому что в противном случае ты не соблюдаешь TDD” — это то, с чем я не согласен.
Но ведь оно верное, не написав тест вперёд, ты не следуешь TDD :)
Имхо, TDD супер, когда ты правишь баг. Сперва воспроизвёл, убедился, что это оно, а потом поправил прод код, и тест прошёл.
Я понял вашу мысль. Я согласен с тем, чем больше всего протестировано комплексно, тем лучше. Но при этом в ряде моментов я остался при своём, мы видимо на разных языках говорим, у каждого своё понимание ситуации и людей, которые в ней оказались, так что давайте остановимся =)
Хорошим тоном в таких процессах являются "чистые" сборки, не зависимые даже от историчности запусков не говоря уже о особенностях внешней среды
Полностью согласен.
А одинаковость настроек не требуется, т.к. они определяются внешними по отношению к артефакту/контейнеру параметрами
Согласен, конечно, 12factor app никто не отменял =) Приложение отдельно, конфигурация отдельно.
Но вообще, обычно, тестовая среда максимально вариативна для лучшего выявления проблем, а стейдж - максимально приближен к продуктиву, иногда делается прямо на основе него.
Смотрите, я триггерю на то, что в статье описывается развёртывание инстанса GitLab локально, и на то, что вы написали "отлаживать пайплайны". Всё это звучит так, будто это туториал по размножению инстансов гитлабов на своей машине, на тестовом стенде, на продовом стенде. Причём локально только для того, чтобы посмотреть, как запустился и отработал пайплайн — то есть фактически протестировать сам .gitlab-ci.yaml. Я здесь прав или ошибаюсь?
Некий набор операций которые необходимы для преобразования исходников в артефакты для запуска на тестовых или продуктивных серверах: получение, сборка, упаковка, прогон тестов. Все они могут принадлежать разным источникам и иметь разную природу.
Полностью согласен с таким определением.
Девопсам или сисадминам, как минимум, могут потребоваться конкретные инструкции по настройке сложного процесса полностью понимать который будет только разработчик.
Да. Но мне ещё здесь хочется добавить, что удобнее общаться в стиле декларативных зависимостей, а не инструкций. "Мне нужен доступ в интернет с общего раннера, чтобы скачать образ с gradle и jdk; мне нужен docker, чтобы собирать образы; мне нужен registry, чтобы хранить их; мне нужен shell-runner на таком-то стенде с тегом prod, чтобы деплоить туда". Если процесс убер-сложный, нужно его документировать, обсуждать, чтобы обе стороны понимали, что и как работает. Тогда это и есть DevOps.
Смотря, что вы имеете ввиду под этими словами. Сборка — скрипт, запускаемый в джобе? Часто это минимум команд, которые можно просто запустить из IDE, например та же сборка спринговым плагином сразу образа. Если сложнее, можно вынести все команды в .sh, и запускать его. Вариантов очень много, на самом деле.
Что значит отладить пайплайн? Если вы отлаживаете их на локальном инстансе, вы гарантируете, что настройки раннеров и всех других важных административных настроек идентичны тем, что на удаленной среде?
1. Гитлаб, по моему опыту, - самое беспроблемное приложение, не требующее особого ухода. По крайней мере в команде из 10 человек. Я трачу на его сопровождение всего 10 минут в неделю: делаю бэкап, скачиваю новую версию образа (если успела выйти) и перезапускаю на новом образе.
Имея достаточно устаревший опыт (развёртывание omnibus в 2015-2017), я, скорее, соглашусь с этим. Действительно, установка и администрирование были простыми и времени особо не требовали.
Встроенный container registry появился в 2016 году и сразу был доступен для всех. А вот package registry (maven, npm и прочие) был изначально платным, но переехал во free tier в 2020 году. Видимо, автор в 2015 настроил CI до состояния "работает - не трожь" и теперь делится хоть и готовым, но, увы, устаревшим рецептом. А может он поленился узнать какими фичами вообще обладает гитлаб. Или просто теряется в имеющейся документации (как он пишет в комментарии выше).
Ну вообще нет, т.к. я перестал регулярно читать ежемесячные дайджесты по 22 числам только год назад, и сейчас читаю их просто нерегулярно.
Но хочу отметить, что я не являюсь сис.админом, в данный момент я исключительно разработчик. И считаю избыточным для разработчика самостоятельно развёртывать и поддерживать GitLab.
Я продолжаю придерживаться мысли, что GitLab в компании должен быть один и управляться сис.админами, их не должно быть по штуке на разработчика (локально в докере), и разделять инстансы гитлаба на дев/прод среду тоже не нужно. Если речь в статье про разработчика-одиночку, почему бы ему не воспользоваться облачным GitLab.com? Если статья написана про ещё более узкую ситуацию, то, имхо, это должно быть обозначено, а не приведено как универсальный quickstart для любой ситуации.
1.1. Ваше предложение не масштабируется. Придется переделывать, когда возникнет необходимость деплоить более чем на один сервер. Плюс есть проблемы с безопасностью - прод не должен иметь доступ к деву, а в вашей схеме потребуется пробить дырку из прода к гитлабу.
Извините, но не вижу, где оно не масштабируется. Я применяю эту схему на разных проектах. GitLab это не часть ни dev-среды, ни prod-среды, это инфраструктурный компонент, такой же, как и вероятно установленный где-то рядом Registry. Поэтому речь о пробитии дырки прод->дев некорректна, это дырка prod->infra.
Деплойте на сколько угодно серверов, из каких угодно веток. Разделите ветки стендов на protected и нет, чтобы обезопасить прод. Собирайте и пуште образы на общих раннерах, деплойте на "стендовых" раннерах, фильтруя джобы деплоя через фильтры only:refs и tags. Запретите Dev мержить в protected, только Maintainer.
Я дико извиняюсь, но, имхо, вся эта статья пропитана костылями.
Попробую защитить своё мнение.
Итак, мы получили пайплайн, который при фиксации изменений в репозитории запускает сборку проекта и затем докер-образа, публикует его в отдельном реестре, забирает и деплоит докером целевой машины. Благодаря гибкости докера все это мы проделали на локальном компьютере, но теперь, отладив процессы, легко сможем перенести их в производственную среду.
1) Я сторонник DevOps, но самостоятельное развёртывание и администрирование инстанса GitLab, имхо, не должно касаться стороны Dev. Это задача исключительно инфраструктурной команды. Я развёртывал в НИИ в 2015 году инстанс и пару лет админил его, так что это не диванная аналитика =)
1.1) Однако, ничего не имею против развёртывания своих раннеров. Настолько, что мне кажется более стройной идея установки раннера на целевой хост и запуск джобы с деплоем прямо на нём, без всех этих приключений с SSH-ключами.
2) Про поднятие своего реестра -- не уверен, кто-нибудь ниже мб меня поправит. Но если инстанс GitLab развёрнут нормально, в нём же есть встроенный и Image Registry, и Maven / npm Registry и т.п. (честно не помню, может что-то в платных Tier, но образы точно есть в бесплатном).
3) Зачем нам игнорировать базовый функционал раннера по скачиванию репы? Ради чего? Потому что у нас кривая среда?
4) У вас only.refs: main, а если MR из фича ветки в main кривой и всё ломает?
5) В таком виде процессы не "отлажены", я бы на прод это не допускал =)
Раз уж покритиковал, напишу свой вариант. Он, конечно, может быть к вашей ситуации неприменим, я не знаю всех тонкостей.
1) GitLab у нас один и управляется специалистами нужного профиля. Они же предоставляют общие раннеры (и желательно не privileged).
2) У нас есть джоба, которая собирает приложение, прогоняет тесты, пакует всё в образ и пушит в registry под управлением специалистов нужного профиля. На общем раннере, для любой ветки.
3) Для веток, соответствующим стендам (тест/прод), запускаются джобы с тегами раннеров, стоящих в этих средах. Раннеры на месте делают pull нового образа и рестарт приложа.
Поделитесь в комментариях: какие методики модульного тестирования используете вы?
Используем эти:
Высокоуровневые — проверка бизнес‑процесса системы и логики работы программы.
Как-то так вышло, эмпирически, что низкоуровневые тесты всё-таки гарантируют с меньшей степенью отсутствие багов. Высокоуровневые проверяют и то, что сценарий ОКъ, и низкоуровневые моменты.
Не отрицаю, что (1) нет, но пирамида тестирования перевёрнутая выходит в реальности: больше всего (3), есть (2), меньше всех (1).
До того, как я удалил ещё тогда Сбер, он жрал немыслимое кол-во места на телефоне (чуть менее 700 Мб). Подумать только, целый CD! Для меня это было достаточно зловредно :)))
Но тут ещё 5 атмосфер держат, так что глубина уже сильно больше.
А онлайн или запись не планируется?
Да нормально, только делать поменьше вложений, разбивая на отдельные методы :)
Ну или мапстракт :)
Я был бы очень рад, если бы главное меню показывалось по однократному нажатию ALT, как меню в большинстве прог в Винде. Но тут почему-то `Alt + \`, который ещё и не работает чаще всего ...
А я думал, что в статье напишите "Вешайте TxMode.NEVER на все клиенты к внешним системам" :)
Тоже своего рода защита пула коннектов от исчерпания из-за медленных зависимостей...
Но ведь оно верное, не написав тест вперёд, ты не следуешь TDD :)
Имхо, TDD супер, когда ты правишь баг. Сперва воспроизвёл, убедился, что это оно, а потом поправил прод код, и тест прошёл.
В остальных случаях скорее согласен с автором.
Но ведь оно верное, не написав тест вперёд, ты не следуешь TDD :)
Имхо, TDD супер, когда ты правишь баг. Сперва воспроизвёл, убедился, что это оно, а потом поправил прод код, и тест прошёл.
В остальных случаях скорее согласен с автором.
Использую этот шаблон, он действительно местами очень классно применим, спасибо, что популяризируете :)
Я понял вашу мысль. Я согласен с тем, чем больше всего протестировано комплексно, тем лучше. Но при этом в ряде моментов я остался при своём, мы видимо на разных языках говорим, у каждого своё понимание ситуации и людей, которые в ней оказались, так что давайте остановимся =)
Полностью согласен.
Согласен, конечно, 12factor app никто не отменял =) Приложение отдельно, конфигурация отдельно.
Смотрите, я триггерю на то, что в статье описывается развёртывание инстанса GitLab локально, и на то, что вы написали "отлаживать пайплайны". Всё это звучит так, будто это туториал по размножению инстансов гитлабов на своей машине, на тестовом стенде, на продовом стенде. Причём локально только для того, чтобы посмотреть, как запустился и отработал пайплайн — то есть фактически протестировать сам .gitlab-ci.yaml. Я здесь прав или ошибаюсь?
Полностью согласен с таким определением.
Да. Но мне ещё здесь хочется добавить, что удобнее общаться в стиле декларативных зависимостей, а не инструкций. "Мне нужен доступ в интернет с общего раннера, чтобы скачать образ с gradle и jdk; мне нужен docker, чтобы собирать образы; мне нужен registry, чтобы хранить их; мне нужен shell-runner на таком-то стенде с тегом prod, чтобы деплоить туда". Если процесс убер-сложный, нужно его документировать, обсуждать, чтобы обе стороны понимали, что и как работает. Тогда это и есть DevOps.
Смотря, что вы имеете ввиду под этими словами. Сборка — скрипт, запускаемый в джобе? Часто это минимум команд, которые можно просто запустить из IDE, например та же сборка спринговым плагином сразу образа. Если сложнее, можно вынести все команды в .sh, и запускать его. Вариантов очень много, на самом деле.
Что значит отладить пайплайн? Если вы отлаживаете их на локальном инстансе, вы гарантируете, что настройки раннеров и всех других важных административных настроек идентичны тем, что на удаленной среде?
Имея достаточно устаревший опыт (развёртывание omnibus в 2015-2017), я, скорее, соглашусь с этим. Действительно, установка и администрирование были простыми и времени особо не требовали.
Ну вообще нет, т.к. я перестал регулярно читать ежемесячные дайджесты по 22 числам только год назад, и сейчас читаю их просто нерегулярно.
Но хочу отметить, что я не являюсь сис.админом, в данный момент я исключительно разработчик. И считаю избыточным для разработчика самостоятельно развёртывать и поддерживать GitLab.
Я продолжаю придерживаться мысли, что GitLab в компании должен быть один и управляться сис.админами, их не должно быть по штуке на разработчика (локально в докере), и разделять инстансы гитлаба на дев/прод среду тоже не нужно. Если речь в статье про разработчика-одиночку, почему бы ему не воспользоваться облачным GitLab.com? Если статья написана про ещё более узкую ситуацию, то, имхо, это должно быть обозначено, а не приведено как универсальный quickstart для любой ситуации.
Извините, но не вижу, где оно не масштабируется. Я применяю эту схему на разных проектах. GitLab это не часть ни dev-среды, ни prod-среды, это инфраструктурный компонент, такой же, как и вероятно установленный где-то рядом Registry. Поэтому речь о пробитии дырки прод->дев некорректна, это дырка prod->infra.
Деплойте на сколько угодно серверов, из каких угодно веток. Разделите ветки стендов на protected и нет, чтобы обезопасить прод. Собирайте и пуште образы на общих раннерах, деплойте на "стендовых" раннерах, фильтруя джобы деплоя через фильтры only:refs и tags. Запретите Dev мержить в protected, только Maintainer.
Я дико извиняюсь, но, имхо, вся эта статья пропитана костылями.
Попробую защитить своё мнение.
1) Я сторонник DevOps, но самостоятельное развёртывание и администрирование инстанса GitLab, имхо, не должно касаться стороны Dev. Это задача исключительно инфраструктурной команды. Я развёртывал в НИИ в 2015 году инстанс и пару лет админил его, так что это не диванная аналитика =)
1.1) Однако, ничего не имею против развёртывания своих раннеров. Настолько, что мне кажется более стройной идея установки раннера на целевой хост и запуск джобы с деплоем прямо на нём, без всех этих приключений с SSH-ключами.
2) Про поднятие своего реестра -- не уверен, кто-нибудь ниже мб меня поправит. Но если инстанс GitLab развёрнут нормально, в нём же есть встроенный и Image Registry, и Maven / npm Registry и т.п. (честно не помню, может что-то в платных Tier, но образы точно есть в бесплатном).
3) Зачем нам игнорировать базовый функционал раннера по скачиванию репы? Ради чего? Потому что у нас кривая среда?
4) У вас only.refs: main, а если MR из фича ветки в main кривой и всё ломает?
5) В таком виде процессы не "отлажены", я бы на прод это не допускал =)
Раз уж покритиковал, напишу свой вариант. Он, конечно, может быть к вашей ситуации неприменим, я не знаю всех тонкостей.
1) GitLab у нас один и управляется специалистами нужного профиля. Они же предоставляют общие раннеры (и желательно не privileged).
2) У нас есть джоба, которая собирает приложение, прогоняет тесты, пакует всё в образ и пушит в registry под управлением специалистов нужного профиля. На общем раннере, для любой ветки.
3) Для веток, соответствующим стендам (тест/прод), запускаются джобы с тегами раннеров, стоящих в этих средах. Раннеры на месте делают pull нового образа и рестарт приложа.
Терминал и Far это боль :)
Но если добавить фольги, кажется, должен получится хороший конденсатор )
Жаль, что ни слова про Новосибирск, вдруг тоже какие-нибудь интересные факты нашлись бы :)
Используем эти:
Как-то так вышло, эмпирически, что низкоуровневые тесты всё-таки гарантируют с меньшей степенью отсутствие багов. Высокоуровневые проверяют и то, что сценарий ОКъ, и низкоуровневые моменты.
Не отрицаю, что (1) нет, но пирамида тестирования перевёрнутая выходит в реальности: больше всего (3), есть (2), меньше всех (1).
До того, как я удалил ещё тогда Сбер, он жрал немыслимое кол-во места на телефоне (чуть менее 700 Мб). Подумать только, целый CD! Для меня это было достаточно зловредно :)))
А зачем таскать 300 Гб артефактами? Может надо что-то из них выпилить?