В смысле читать тяжко до конца?) Что следует поправить?
По второму абзацу - в статье рассуждаю в контексте команды DevOps, а не разработки, как таковой. Старался донести в том числе, мол Google может себе позволить сделать Kubernetes, а локальная команда - вряд ли... Вряд ли ей вообще стоит этим заниматься.
Шучу конечно. На самом деле ответ лежит в самой парадигме контейнеризации. Это отвязка от окружения. Я не хочу гвоздями в ноду сборки прибивать версии и параметры и не хочу привязываться к ресурсам этой ноды.
А если мы когда-нибудь корпоративно уйдем в облака, а мы это обязательно сделаем, то будет подниматься машина в облаке, отрабатывать пайплайн и удаляться. Экономия ресурсов и все такое.
Приоткрою завесу тайны. Версию изменяет сам разработчик в build.gradle, Jenkins же парсит build.gradle, вытаскивает версию+номер, копирует из контейнера в хранилище. В хранилище смотрит nginx со строчкой autoindex on;
Ввиду определенного git-flow, в хранилище автоматом попадают версия на тест и версия релизная
Однако есть нюанс. Беспощадный ру-девелоп в больших структурах (особенно родом из 90-х) как правило завязаны на определенных версиях окружения. И обновляются с новым разработчиком\команды, посему тут захардкожено.
Но соглашусь, что правильнее было бы ввести переменную (но уже в пайплайн), чтобы магия происходила в нужной директиве FROM в Dockerfile. Но тогда и Adndroid SDK нужно ставить весь, со всеми (или большинством) версиями и пакетами.
В идеальном мире - сразу в репозитории есть ряд переменных окружения, с которым работает разработчик, которые можно спарсить и подложить в Dockerfile
Интересный тезис, апробирую =)
Отчасти да, разработка присутствует, спору нет.
Впрочем и на феррари можно картошку возить, а не... а не ездить к внукам)
В смысле читать тяжко до конца?) Что следует поправить?
По второму абзацу - в статье рассуждаю в контексте команды DevOps, а не разработки, как таковой. Старался донести в том числе, мол Google может себе позволить сделать Kubernetes, а локальная команда - вряд ли... Вряд ли ей вообще стоит этим заниматься.
это скорее вопросы восприятия схемы, в данном примере цвет квадратиков, легенда в самом начале
от себя могу сказать, что такой подход понял коренной гуманитарий, так сказать контрольная группа (:
так ведь по отдельному прайсу)
перечень технических решений и краткий мануал по how-to поражает, респект отдельный
а в целом... вы для себя открыли Nexus и шаблоны в gitlab-ci?
Как насчёт самих мастер год и ингресса, их тоже желательно резервировать.
Байт на потеребить колокольчик)
Шучу конечно. На самом деле ответ лежит в самой парадигме контейнеризации. Это отвязка от окружения. Я не хочу гвоздями в ноду сборки прибивать версии и параметры и не хочу привязываться к ресурсам этой ноды.
А если мы когда-нибудь корпоративно уйдем в облака, а мы это обязательно сделаем, то будет подниматься машина в облаке, отрабатывать пайплайн и удаляться. Экономия ресурсов и все такое.
История про публикацию в следующей серии =)
Приоткрою завесу тайны. Версию изменяет сам разработчик в build.gradle, Jenkins же парсит build.gradle, вытаскивает версию+номер, копирует из контейнера в хранилище. В хранилище смотрит nginx со строчкой autoindex on;
Ввиду определенного git-flow, в хранилище автоматом попадают версия на тест и версия релизная
Хорошее замечание!
Однако есть нюанс. Беспощадный ру-девелоп в больших структурах (особенно родом из 90-х) как правило завязаны на определенных версиях окружения. И обновляются с новым разработчиком\команды, посему тут захардкожено.
Но соглашусь, что правильнее было бы ввести переменную (но уже в пайплайн), чтобы магия происходила в нужной директиве FROM в Dockerfile. Но тогда и Adndroid SDK нужно ставить весь, со всеми (или большинством) версиями и пакетами.
В идеальном мире - сразу в репозитории есть ряд переменных окружения, с которым работает разработчик, которые можно спарсить и подложить в Dockerfile