На своих проектах тоже пришёл к выводу, что огромной пользы от юнит-тестов нет и получить не выйдет, как покрытие не повышай. Плюс лично я против того, чтобы, когда вносятся нефункциональные изменения в боевой код (рефакторинг), требовалось изменять тесты. Потому что тест должен защитить боевой код от потенциальных проблем при рефакторинге, а изменяя его — ты защищаешь этот самый баг ) И, к слову, даже наличие проблем в непроверенных краевых вызовах какого-то метода может спокойно быть нивелировано реальной невозможностью этот код таким образом вызвать (в рамках ввода пользователя).
Теперь у нас развёрнутая пирамида тестирования — больше всего кейсов у QA, backend-разработчики пишут преимущественно тесты по веткам пользовательский сценариев процессов (как хотите называйте, e2e / интеграционные), а юнитами покрываются только изолированные кирпичики. А TDD очень хорошо заходит, когда реально от QA или с боя прилетает баг — сперва тестом воспроизводится, затем фиксится.
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.
Мы тоже осенью перешли с 2.7.18 на 3.3.4. Какие-то проблемы пересекались, какие-то свои поймали :) Ушло примерно 1.5 месяца одного разработчика.
Чем больше проект, ИМХО, тем чаще нужно делать более минорные обновления, иначе очень быстро они накапливаются в непреодолимый ком.
В Java 24 ... или В 24-м году в Java 24 ... ? :)
Поддерживаю вопрос, ведь только каждый 4й должен быть LTS...
UseCase это хорошая реализация, а сервис с 100 ответственностями — не очень хорошая :)
Мне понравилось, как это на телефоне выглядит. Согласен :)
На своих проектах тоже пришёл к выводу, что огромной пользы от юнит-тестов нет и получить не выйдет, как покрытие не повышай. Плюс лично я против того, чтобы, когда вносятся нефункциональные изменения в боевой код (рефакторинг), требовалось изменять тесты. Потому что тест должен защитить боевой код от потенциальных проблем при рефакторинге, а изменяя его — ты защищаешь этот самый баг ) И, к слову, даже наличие проблем в непроверенных краевых вызовах какого-то метода может спокойно быть нивелировано реальной невозможностью этот код таким образом вызвать (в рамках ввода пользователя).
Теперь у нас развёрнутая пирамида тестирования — больше всего кейсов у QA, backend-разработчики пишут преимущественно тесты по веткам пользовательский сценариев процессов (как хотите называйте, e2e / интеграционные), а юнитами покрываются только изолированные кирпичики. А TDD очень хорошо заходит, когда реально от QA или с боя прилетает баг — сперва тестом воспроизводится, затем фиксится.
Но тут ещё 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.