между требованиями иметь как можно меньше внешних зависимостей и выполнять только одну задачу и при том хорошо в реальной жизни восновном будет возникать противоречие, т.к. если вы, например, имеете потребность, но не используете XStream или его аналог как зависимость, значит вы решаете его задачу внутри своей разработки т.е. добавляете ее к перечню задач решаемых вашей единицей кода. Решение проблемы с логгерами лежало где-то как раз в сфере SOLID: 1) зависеть от интерфейсов, а не от реализаций, 2) не иметь дублирующих реализаций в рамках одной системы.
Причём локально только для того, чтобы посмотреть, как запустился и отработал пайплайн — то есть фактически протестировать сам .gitlab-ci.yaml. Я здесь прав или ошибаюсь?
В том числе протестировать пайплайн, ситуация может быть различной, у вас могут быть отдельные виртуалки или железяки под все включая реестр, надо быть готовым ко всему. Специфика данной статьи - джава-проекты которые надо деплоить автоматически, докер как среда их выполнения, гитлаб как система неприрывной интеграции. Вы не становитесь сисадмином от того, что выполнеяте docker start локально или на выделенном сервере.
Да. Но мне ещё здесь хочется добавить, что удобнее общаться в стиле декларативных зависимостей, а не инструкций.
просто не всегда бывает так, что вы можете все определить самостоятельно и решить задачу "с нуля", реестр может потребоваться использовать уже готовый и сторонний, например из артифактори или нексуса или того же докерхаба или аналога. Конкретно для программиста отдельный реестр удобнее в том плане, что гитлаб наигравшись можно выключить, а реестр оставить для поддержки других своих задач.
девопс это почти сисадмин готовый заниматься вопросами выше уровней сетевой маршрутизации, но он не программист и может и не знать для чего надо запускать препроцессоры или с какими профилями собирать. Конечно, надо ему эти знания как-то передать, но прежде чем это получится сделать этот процесс желательно проработать разработчику, т.к. если с какой-то проблемой застрянет девопс ему разобраться в особенностях наделанного программистами будет гораздо сложнее. Ну и я совершенно не возражаю против того, что бы этой статьей воспользовались сисадмины и девопсы, даже хочу им помочь как в плане получения базовых рецептов, так и специфики типа развертывания джава-приложений в контейнерах.
Если вы отлаживаете их на локальном инстансе, вы гарантируете, что настройки раннеров и всех других важных административных настроек идентичны тем, что на удаленной среде?
хорошим тоном в таких процессах являются "чистые" сборки, не зависимые даже от историчности запусков не говоря уже о особенностях внешней среды, а одинаковость настроек не требуется, т.к. они определяются внешними по отношению к артефакту/контейнеру параметрами. Но вообще, обычно, тестовая среда максимально вариативна для лучшего выявления проблем, а стейдж - максимально приближен к продуктиву, иногда делается прямо на основе него.
Смотря, что вы имеете ввиду под этими словами. Сборка — скрипт, запускаемый в джобе?
некий набор операций которые необходимы для преобразования исходников в артефакты для запуска на тестовых или продуктивных серверах: получение, сборка, упаковка, прогон тестов. Все они могут принадлежать разным источникам и иметь разную природу. Кроме того, это может быть какая-то новая для вашей ситуации технология или контекст. Девопсам или сисадминам, как минимум, могут потребоваться конкретные инструкции по настройке сложного процесса полностью понимать который будет только разработчик.
это статья-туториал(к сожалению не нашел такой опции при публикации, хотя раньше она была), т.е. этакий практикум для тех кто еще не знаком с темой, поэтому одной из главных ее задач является отработка потенциальных проблемных зон. Если их не рассмотреть, специалисту придется искать другие статьи, копаться на стековерфлоу в гугле и ассистентах. Мне в свое время как раз приходилось решать не только упомянутые проблемы, но и многие другие. Конечно, лучше быть здоровым и богатым, но в реальности все бывает по-разному. А для совсем стандартных решений типа использования встроенных или докерхабовских реестров существует официальная документация, правда в ней тоже не всегда могут быть такие квикстарты для новичков закрывающие сразу некоторый полный минимальный набор. А что-бы побеждать в борьбе с деревом официальной документации уже требуются некоторые знания и опыт. Поэтому для освоения технологии достаточно эффективным оказывается пройти сначала некий базовый туториал, а потом с пониманием идти в сторону улучшений. Программистам тоже приходится в этом ориентироваться, сейчас у каждого локально могут быть развернуты кластеры, каталоги, субд, что-бы разбираться и решать проблемы их использование часто оказывается необходимым и оправданным как раз в ситуациях с большими компаниями, когда хождение в официальную инфраструктуру требует долгих согласований, а сроки горят как по-аджайлу;)
в плане небиблиотечных зависимостей можно посмотреть как сделаны сервисы в Liferay. Мне показалось очень крутой возможность переопределять любые сервисы ядра без патчинга и "плагинов" и межмодульное взаимодействие как при использовании локального контекста.
между требованиями иметь как можно меньше внешних зависимостей и выполнять только одну задачу и при том хорошо в реальной жизни восновном будет возникать противоречие, т.к. если вы, например, имеете потребность, но не используете XStream или его аналог как зависимость, значит вы решаете его задачу внутри своей разработки т.е. добавляете ее к перечню задач решаемых вашей единицей кода. Решение проблемы с логгерами лежало где-то как раз в сфере SOLID: 1) зависеть от интерфейсов, а не от реализаций, 2) не иметь дублирующих реализаций в рамках одной системы.
В том числе протестировать пайплайн, ситуация может быть различной, у вас могут быть отдельные виртуалки или железяки под все включая реестр, надо быть готовым ко всему. Специфика данной статьи - джава-проекты которые надо деплоить автоматически, докер как среда их выполнения, гитлаб как система неприрывной интеграции. Вы не становитесь сисадмином от того, что выполнеяте docker start локально или на выделенном сервере.
просто не всегда бывает так, что вы можете все определить самостоятельно и решить задачу "с нуля", реестр может потребоваться использовать уже готовый и сторонний, например из артифактори или нексуса или того же докерхаба или аналога. Конкретно для программиста отдельный реестр удобнее в том плане, что гитлаб наигравшись можно выключить, а реестр оставить для поддержки других своих задач.
девопс это почти сисадмин готовый заниматься вопросами выше уровней сетевой маршрутизации, но он не программист и может и не знать для чего надо запускать препроцессоры или с какими профилями собирать. Конечно, надо ему эти знания как-то передать, но прежде чем это получится сделать этот процесс желательно проработать разработчику, т.к. если с какой-то проблемой застрянет девопс ему разобраться в особенностях наделанного программистами будет гораздо сложнее. Ну и я совершенно не возражаю против того, что бы этой статьей воспользовались сисадмины и девопсы, даже хочу им помочь как в плане получения базовых рецептов, так и специфики типа развертывания джава-приложений в контейнерах.
хорошим тоном в таких процессах являются "чистые" сборки, не зависимые даже от историчности запусков не говоря уже о особенностях внешней среды, а одинаковость настроек не требуется, т.к. они определяются внешними по отношению к артефакту/контейнеру параметрами. Но вообще, обычно, тестовая среда максимально вариативна для лучшего выявления проблем, а стейдж - максимально приближен к продуктиву, иногда делается прямо на основе него.
некий набор операций которые необходимы для преобразования исходников в артефакты для запуска на тестовых или продуктивных серверах: получение, сборка, упаковка, прогон тестов. Все они могут принадлежать разным источникам и иметь разную природу. Кроме того, это может быть какая-то новая для вашей ситуации технология или контекст. Девопсам или сисадминам, как минимум, могут потребоваться конкретные инструкции по настройке сложного процесса полностью понимать который будет только разработчик.
А что делать если вам надо отладить саму сборку или пайплайн и сисадмины такого точно не смогут?
это статья-туториал(к сожалению не нашел такой опции при публикации, хотя раньше она была), т.е. этакий практикум для тех кто еще не знаком с темой, поэтому одной из главных ее задач является отработка потенциальных проблемных зон. Если их не рассмотреть, специалисту придется искать другие статьи, копаться на стековерфлоу в гугле и ассистентах. Мне в свое время как раз приходилось решать не только упомянутые проблемы, но и многие другие. Конечно, лучше быть здоровым и богатым, но в реальности все бывает по-разному. А для совсем стандартных решений типа использования встроенных или докерхабовских реестров существует официальная документация, правда в ней тоже не всегда могут быть такие квикстарты для новичков закрывающие сразу некоторый полный минимальный набор. А что-бы побеждать в борьбе с деревом официальной документации уже требуются некоторые знания и опыт. Поэтому для освоения технологии достаточно эффективным оказывается пройти сначала некий базовый туториал, а потом с пониманием идти в сторону улучшений. Программистам тоже приходится в этом ориентироваться, сейчас у каждого локально могут быть развернуты кластеры, каталоги, субд, что-бы разбираться и решать проблемы их использование часто оказывается необходимым и оправданным как раз в ситуациях с большими компаниями, когда хождение в официальную инфраструктуру требует долгих согласований, а сроки горят как по-аджайлу;)
в плане небиблиотечных зависимостей можно посмотреть как сделаны сервисы в Liferay. Мне показалось очень крутой возможность переопределять любые сервисы ядра без патчинга и "плагинов" и межмодульное взаимодействие как при использовании локального контекста.