Что-то из ветки мастер, да. Но какой коммит? До или после той фичи, когда мы где-то тут (где сломалось) и вносили изменения?
"до конца проверенный мастер“. Это состояние в "классической схеме" соответствует итоговому состоянию release-ветки перед мержем в мастер. Эта ветка вам понадобится, если у вас ведётся разработка настолько интенсивно, что, когда вы интегрировали большое количество изменений, вам нужно время "устаканить" все возникающие при этом конфликты (stable-версия), когда при этом летят уже новые готовые изменения. Чтобы не быть в состоянии постоянного тестирования)
В целом соглашусь про облачный GitLab, но в самое главное ограничение — 400 минут для Pipeline-ов вполне вероятно упереться и начинающим. Хотя, если настроите раннеры на своих мощностях, то они не считаются. Но тогда в целом и свой GitLab не так уж и трудно конфигурируется. Все настройки приведены тут, даже для случая за реверс-прокси, в чем и смысл данной статьи. Ну и за этот год уже были случаи, что облачный гитлаб падал, а мы спокойно продолжаем работу.
По поводу latest тэгов. Да, при использовании общественных образов с докерхаба, лучшая практика — привязываться к версии. Но для собственных образов это уже без особой разницы — вы же сами ими управляете. Зато так чуть проще файл конфигурации прода — не нужно передавать тэг для выкатки. Ну и быстрее понять, если что-то не так.
К такой эпической задаче нужно готовиться — закончить и слить все открытые ветки. А после этого все разработчики работают над рефакторингом, как я описал в 4м пункте процесса разработки. Или у вас есть опыт других граблей, кроме вылезающих повсюду конфликтов?
Прискорбно читать. Как писали ниже, человек со светлым умом уходит из востребованной профессии чтобы тратить время на пиксели. Можно спросить, что сподвигло на это? Желание большего заработка или скорее творческие порывы?
А можно использовать werf только для сборки и хранения образов? Например, мой проект пока не требует k8s, хватает докер-композа. Но удобный ci/cd и чистый registry хочется).
Заметка: во время установки будет настраиваться Postfix и grub — одна из них может завершиться с ошибкой. Возможно, это будет вызвано тем, что хостнейм не резолвится по имени. Отредактируйте hosts записи и выполните apt-get update
почему установка не с помощью ISO-образа, а на готовый Debian?
На какую конфигурацию хранилища устанавливаете ОС-хост? Сам Proxmox рекомендует использовать hardware RAID (но только поддерживаемый). Есть статьи, в которых для подобных систем (FreeNAS на ZFS) вообще рекомендуют устанавливать на рейд из внешних SSD (или того хуже, USB-стики).
У меня сейчас Proxmox работает на одном диске в ext4, думаю на рейд перебраться — интересны лучшие практики по железу. Если для основного файлового хранилища уже есть hardware RAID (PREC H330 и MegaRAID SAS 9341-4i), стоит ли его выдергивать и использовать ZFS RAID 10? Оперативки хватает.
Что-то из ветки мастер, да. Но какой коммит? До или после той фичи, когда мы где-то тут (где сломалось) и вносили изменения?
"до конца проверенный мастер“. Это состояние в "классической схеме" соответствует итоговому состоянию release-ветки перед мержем в мастер. Эта ветка вам понадобится, если у вас ведётся разработка настолько интенсивно, что, когда вы интегрировали большое количество изменений, вам нужно время "устаканить" все возникающие при этом конфликты (stable-версия), когда при этом летят уже новые готовые изменения. Чтобы не быть в состоянии постоянного тестирования)
В целом соглашусь про облачный GitLab, но в самое главное ограничение — 400 минут для Pipeline-ов вполне вероятно упереться и начинающим. Хотя, если настроите раннеры на своих мощностях, то они не считаются. Но тогда в целом и свой GitLab не так уж и трудно конфигурируется. Все настройки приведены тут, даже для случая за реверс-прокси, в чем и смысл данной статьи. Ну и за этот год уже были случаи, что облачный гитлаб падал, а мы спокойно продолжаем работу.
По поводу latest тэгов. Да, при использовании общественных образов с докерхаба, лучшая практика — привязываться к версии. Но для собственных образов это уже без особой разницы — вы же сами ими управляете. Зато так чуть проще файл конфигурации прода — не нужно передавать тэг для выкатки. Ну и быстрее понять, если что-то не так.
Если вы не выкатываете каждую фичу сразу же после мержа на прод, то как минимум два кейса:
Можно создать ветку release, но тогда функции dev просто примет на себя ветка master.
К такой эпической задаче нужно готовиться — закончить и слить все открытые ветки. А после этого все разработчики работают над рефакторингом, как я описал в 4м пункте процесса разработки. Или у вас есть опыт других граблей, кроме вылезающих повсюду конфликтов?
Прискорбно читать. Как писали ниже, человек со светлым умом уходит из востребованной профессии чтобы тратить время на пиксели. Можно спросить, что сподвигло на это? Желание большего заработка или скорее творческие порывы?
А можно использовать werf только для сборки и хранения образов? Например, мой проект пока не требует k8s, хватает докер-композа. Но удобный ci/cd и чистый registry хочется).
https://habr.com/ru/post/342310/
По официальному руководству это даже требуется сделать.
Добрый день. Спасибо за статью! Вопросы: