Стоит ли хранить исходные коды приложения и конфигураций Docker в одном или разных git репозиториях?
Мы ведем разработку приложения на php. Исходные коды находятся в отдельном репо git на собственном gitlab.
До недавнего времени, настройку окружения для разработки, тестирования и прода у заказчика (выкладку релиза) делали вручную. До автоматизации руки не доходили, да и обычно бывали какие-то моменты, которые требовали ручного участия... Потом начали сталкиваться с тем, что на компах у разрабов бывает, что несколько отличается конфигурация ПО и из-за этого (периодически!) происходили какие-то "чудеса" (у одного работает, а у другого нет). Задумались о docker, но как-то не срослось... Прорыв наступил, когда очередной релиз не взлетел на сервере у заказчика из-за разницы в версиях установленных библиотек и ряда других настроек. Причем установить другую библиотеку было никак нельзя... Пришлось срочно переключаться на поставку приложения в виде набора docker-контейнеров.
Это я описал к тому, что наработанного процесса поставки решения на основе docker у нас пока нет... Мы только учимся!
В процессе анализа задачи, мы пришли к выводу, что нам нужны следующие образы:
* Кастомный образ с php (web и cli), который мы собираем с дистрибутивного php-образа путем установки и настройки разных библиотек и расширений. Причем в двух вариантах: с xdebug (для dev) и без (stage, prod). Он собирается достаточно долго, т.ч. решили его собрать заранее и положить в hub (gitlab).
* Итоговый образ php вместе с приложением (на основе кастомного образа) и всем необходимым. Собирается часто, для каждой новой фичи или фикса.
* Различны образы дополнительного ПО (nginx, rabbitmq и т.д.) собираются по мере потребности, например, может потребоваться новая версия для новой фичи, а может и нет.
Запуском всего этого хозяйства во всех окружениях (на машинах разработчиков, на тесте, проде и т.д.) занимается docker-compose со своим файлом конфигурации и возможностью выбора варианта окружения.
Все это хозяйство (файлы docker) решили тоже хранить в git и, из-за возможной связи версии этих файлов с самим приложением, решили положить все в одно репо. Исходные коды php из корня переложили в каталог src, а остальное "разложили вокруг"...
Собственно так это сейчас и живет, но не всем такая "конфигурация" нравится... Во-первых, из-за массового переноса исходников приложения из корня в подкаталог src одним коммитом, стало неудобно "ходить по истории". Во-вторых, при такой структуре каталогов (периодически) "как-то странно" работает phpstorm, например, для require_once, говорит, что не находит файл. Да и вообще, мне кажется исходники должны быть в своем репо, а инструменты сборки в другом, хотя они и могут быть взаимосвязаны.
Дальше планируем настраивать CI/CD, в том числе автоматический прогон автотестов разных уровней, но вначале хотелось бы окончательно определиться с конфигурацией "сборочной линии"...
Дмитрий, А Вас не смущает, что в одном репо смешаны две разные по назначению "фичи"? Исходники php вообще-то самодостаточны и если рассматривать вариант доработок через pull requests, то "куски от сборки" тут совсем не к чему... Для php в принципе "сборка", как, например, make-файл для C, вообще не нужна! С другой стороны сами скрипты сборки, возможно с небольшими изменениями, могут быть переиспользованы на другом подобном проекте... То, что у нас так сделано, это исключительно наше решение для CI/CD (условно!).
У меня, почему-то, вообще есть "стойкое чувство", что все связанное со "сборкой" и деплоем должно быть только в конфигурационном файле сборщика gitlab и все... Правда тогда непонятно, как "все это" разворачивать на рабочем месте разработчика и на проде руками.
