Какова практика деплоя Golang проектов?
собирать бинарник на продакшене - идея так себе.
даже образ 1.9-alpine занимает 83 метра + будут зависимости в GOPATH
Я делал следующим образом
В GitLab CI создавалась задача на тесты проекта, сборку его в бинарник и создания docker образа FROM: SCRATCH, где находится ТОЛЬКО этот бинарник.
На входе я получал образ размером с бинарник - без зависимостей в GOPATH и среды сборки - около 15 мб.
Есть ньюансы для сборки такого бинарника, но в большинстве случаев ИМХО они не существенны.
+ недостатком такого подхода является то, что просто так в контейнер не залезешь и не выполнишь какую-то bash команду, т.к. там ничего нет вообще, кроме бинарника.
вот статья. https://blog.codeship.com/building-minimal-docker-...
Немного смутило ваше видение.
1. Не иметь собранного биинарника плохо: если вдруг нарушен доступ к репозиторию с исходным кодом, вы не можете деплоить стенды
2. Тесты надо прогонять до того, как изменения попадают в релизный бранч
3. Независимо от способа доставки данных, для сборки вам нужны все исходники проекта и стандартной библиотеки, их размер по очевидным причинам больше бинарника
4. Вам придется тянуть зависимости еще и для тестов