Comments 11
При изменении исходного кода пересобирать контейнер, серьезно?
Я ничего не имею против виртуализации сборки, так как это во-первых решает вопрос настройки окружения, во-вторых изолирует процесс сборки, т.е. есть уверенность, что если собралось на его машине, то соберется и на билд сервере, и у других разработчиков.
Лучше собрать контейнер со всем необходимым, при запуске контейнера монтировать каталог с исходным кодом (можно и каталог куда будут складываться результат сборки, чтобы они сохранялись между перезапусками контейнера). А разработчик вручную запускает сборку в контейнере (контейнер предоставляет консоль, X Server или в нем запущен ssh сервер). При изменнии исходного кода разработчик заново запускает сборку без пересборки контейнера.
Я ничего не имею против виртуализации сборки, так как это во-первых решает вопрос настройки окружения, во-вторых изолирует процесс сборки, т.е. есть уверенность, что если собралось на его машине, то соберется и на билд сервере, и у других разработчиков.
Лучше собрать контейнер со всем необходимым, при запуске контейнера монтировать каталог с исходным кодом (можно и каталог куда будут складываться результат сборки, чтобы они сохранялись между перезапусками контейнера). А разработчик вручную запускает сборку в контейнере (контейнер предоставляет консоль, X Server или в нем запущен ssh сервер). При изменнии исходного кода разработчик заново запускает сборку без пересборки контейнера.
Ну, ничего плохого в сборке контейнера нету, но в этом примере стоило бы сделать дополнительные 2 контейнера с установленными зависимостями, чтобы не тратить зря кучу времени. Особенно, если деплой осуществляется при помощи этих контейнеров.
В результате для сборки будет только копироваться исходный код и скомпиленый бинарник, что заметно ускорит процесс.
А вот запуск сборки вручную — очень странная идея. Сборка должна быть по коммиту, как минимум, чтобы удостовериться, что код компилируется и тесты проходят. В противном случае добавляется человеческий фактор, который обычно выстреливает в самый неподходящий момент.
В результате для сборки будет только копироваться исходный код и скомпиленый бинарник, что заметно ускорит процесс.
А вот запуск сборки вручную — очень странная идея. Сборка должна быть по коммиту, как минимум, чтобы удостовериться, что код компилируется и тесты проходят. В противном случае добавляется человеческий фактор, который обычно выстреливает в самый неподходящий момент.
Я думаю под "вручную запускает сборку в контейнере" подразумевалось на хардкодить вызов cmake в Dockerfile, а использовать что-то типа: docker run build-container cmake /app && cmake --build ....
Кто и как будет выполнять эту команду — вопрос отдельный.
Возможны варианты. На текущем месте есть контейнер к которому я подсоединяюсь по VNC и запускаю сборку, запускаю приложение. Это удобно, так как развернуть все необходимое окружение, точнее осбрать все библиотеки довольно длителное занятие плюс они других версий от того, что используется для других проектов и могут возникнуть проблемы из-за этого.
Это было сделано в первую очередь, чтобы вновь пришедшим разработчикам не пришлом возиться со всем этим. Опять же, можно делать инкрементальную сборку, что может быть весьма актуально на больших проектах.
Это было сделано в первую очередь, чтобы вновь пришедшим разработчикам не пришлом возиться со всем этим. Опять же, можно делать инкрементальную сборку, что может быть весьма актуально на больших проектах.
точнее осбрать все библиотеки довольно длителное занятие плюс они других версий от того, что используется для других проектов и могут возникнуть проблемы из-за этого.
У нас решается это просто, есть отдельный репозиторий depends, в котором уже собраны либы для osx, windows, linux, asm.js. Цепляем все через cmake, поэтому для развертки требуется всего лишь компилятор и cmake.
Сборка по коммиту при помощи docker реализовано в GitLab CI, поэтому тут говорить не о чем. Автор говорит именно об освобождении от настройки окружения:
Таким образом, освободив последующих разработчиков от необходимости тратить время на настройку локальной сборки.
UFO just landed and posted this here
Я с Вами согласен, но автор статьи или их смешивает в один, или говорит только про контейнер для локальной сборки на машине разработчика:
В результате мы создали полноценное C++ приложение, настроили окружение для его сборки и запуска под Linux и завернули его в Docker-контейнер. Таким образом, освободив последующих разработчиков от необходимости тратить время на настройку локальной сборки.
Почему в cmake используете, достаточно мощный, механизм find_package, но без его плюсов? Зачем эти глобальные include_directories и ${Boost_libraries}? Ведь гораздо лаконичнее писать Boost::program_info, GTest::main в target_link_libraries. Люди же стараются, пишут для вас find модули, а вы не пользуетесь.
ENTRYPOINT нужно заменить на CMD иначе не будет работать корректное завершение работы контейнера. Ентрипоинт предназначен для предварительной подготовки контейнера к работе(к примеру создания пользователей базы данных при первом запруске)
Sign up to leave a comment.
Использование Docker для сборки и запуска проекта на C++