Я уже несколько лет использую Git для некоторых проектов, но я новичок в Docker.
Сегодня я хотел бы найти рабочий процесс, позволяющий мне правильно использовать Git и Docker для моих командных проектов.
Сегодня
Сегодня без Docker мы используем именованные ветви для разработки. Когда функциональные возможности завершены, мы тянем их к «хозяину». Когда мы хотим перейти в производство, мы создаем версионную ветку preprod (например, preprod-2.3.0) мастера для тестов. Если у нас есть исправления, мы нажимаем на текущий препрод и сливаемся с мастером. Когда ветка preprod готова (автоматическое и ручное тестирование), мы создаем ветку prod с той же версией, что и preprod (ex: prod-2.3.0). Если у нас есть срочные исправления в prod, мы создаем новую ветку из preprod (например, preprod-2.3.1), прежде чем продолжить нормальный процесс (test + prod -> prod-2.3.1).
с докером
В Docker для разработки мы хотим создать локальные изображения с именем $ PROJECT_NAME / $ IMAGE_NAME: dev (project / api: dev, project / db: dev, project / webui: dev ...).
Каждый раз, когда мы перестраиваем локальные проекты, мы теряем образы разработки, но в противном случае это стало бы неуправляемым.
Для тестирования мы также использовали бы версии dev.
Но у меня есть вопросы по запуску производства.
Несколько блогов / статей создают образы докеров после того, как код помещен в git, выполняют модульные тесты и, наконец, сохраняют действительные изображения. После этого действительное изображение будет названо «последним» и использовано для производственной реализации.
В нашем случае мы могли бы использовать эту систему для сохранения действительных изображений ветвей prod- $ VERSION, используя $ VERSION и последние теги для версионирования изображений.
Проблемы
Моя проблема с этой системой заключается в том, что я чувствую, что теряю одно из преимуществ Докера. Когда я выполняю свои тесты локально, я тестирую код, а также образ разработчика. Именно это изображение должно использоваться на КИ и в производстве. Находясь там, CI несколько раз воссоздает изображение для master, preprod и наконец prod перед тем, как его заморозить.
Если версии образов концентратора (например, nginx: latest, node: lastest) изменились за это время, это может вызвать проблемы.
Смотри: https://nickjanetakis.com/blog/docker-tip-18-please-pin-your-docker-image-versions
Другим решением будет сохранение изображений непосредственно в preprod с тегом preprod. После тестирования я добавляю теги «prod» и «latest». Но если обновление происходит во время создания препрода, я иногда могу тратить время на то, чтобы понять, почему оно работает в dev, а не в prod. Но, по крайней мере, это позволяет избежать проблем между подготовкой и производством.
Я также не смог найти систему с блокировкой nodejs (package.json / package-lock.json), которая позволяла бы запускать npm build / npm ci (скачать последнюю версию пакетов и обновить файл блокировки, указав, какой версия была точно использована / перестроена по той же архитектуре, что и файл блокировки).
Смотри: https://docs.npmjs.com/files/package-lock.json
Вопросы
Есть ли у вас система / идея, чтобы убедиться, что изображение идентично предыдущему (в виде блокировки)?
Или рабочий процесс, который позволяет вам работать в команде, удаляя изображения непосредственно из разработчика (с версиями)?