Готовим сборку Go-приложения в продакшн

Да, спасибо! Почему-то я прям была уверена, что где-то видела пример с константами, но действительно не заработает :) Поправила текст.

Спасибо за жизненный пример и интересный вопрос.

Чтобы работать с приватными репозиториями мы добавляем маленький хак в .gitconfig. По умолчанию go get тянет репозитории по http(s), мы подменяем на уровне git эту часть url'а на нужную нам. Наверное, не самое красивое решение, но оно работает. Примеры для github'а и абстрактного bitbucket'а:

[url "git@github.com:"]
insteadOf = https://github.com/

[url "ssh://git@my-secret-bitbucket-url:1234"]
insteadOf = https://my-secret-bitbucket-url/scm


А вот насчет второго вопроса, пожалуй, не всё так просто. У меня всего однажды был похожий случай, когда захотелось переехать на другой хостинг, но я просто пробежалась sed'ом по нужным репозиториям, перегенерила vendor и поправила пути импорта. Ну и путей импорта в коде, по-моему, все-таки не так уж много, как может иногда показаться :)

хак с .gitconfig, описанный выше — очень помог в свое время, долго головой бился как через ssh использовать приватный репозиторий.

Столкнулся с другой проблемой, некоторые приватные репозитории нельзя было обновлять в силу архитектурных решения с помощью

go get -u <repo-url>

есть N микросервисов, они используют общие модули (подключаемых код через импорт) из приватного репозитория: jwt авторизация, управление пользователями, данные о микросервисах микросервиса (например сервис емейл рассылки) и т.п. не вдаваясь в подробности.

В общем, возник бизнес-кейс: нужно изменить поведение модуля (части кода который используют многие микросервисы) но таким образом, чтобы обновление было контролируемым.

1. внести изменения в модуль, адаптировать микросервисы которые его используют и сделать большой (огромный) апдейт, что в разы отсрочит введение в продакшн необходимых изменений;

2. обновлять по мере необходимости микросервисы по мере необходимости.

Для удобства отказались от плясков с gopath, много было хлопот

1. создаем в корне проектов ./lib, туда и клонируем все с гита
2. добавили в .gitignore lib
3. сделали скрипт обновления ./lib, и при необходимости запускаем что нужно:
ЗЫ: рабочая директория ./bin/linux

скрипт update-go-lib.sh

Repos=(repoA repoB repoC)

cd ../../lib

for repo in ${Repos[*]}
do
    if [ -d $repo ]
    then
        cd $repo
        git pull origin master
        cd ..
    else
        git clone git@bitbucket.org:example/$repo.git
    fi
done

все делает 1 команда и размещает нужный код в нужном месте

sh update-go-lib.sh

далее используем библиотеку

package main

import "./lib/repoA"

...

более сложный вариант update-go-lib.sh — использование тегов

Также такой подход сделал возможность более динамично изменять части используемых библиотек под нужды конкретного микросервиса: добавление новых функций, изменение респонса (к примеру) и т.п.,

В результате разработка проходит достаточно плавно и прогнозировано, продукт большой, сервисом много.

похожий подход используем и для документации, каждый модуль может иметь свои ендпоинты и т.п., он содержит api-reference.json который отображается в доке используемых сервисов, изменения одного модуля отображается в доке зависимого микросервиса с сохранением версии апдейта.

Как-то так. Решение, возможно, не из лучших, но оно работает, хорошо зарекомендовало на разных серверах и ос.

пытался химичить и как-то использовать известные системы управления зависимостями — но все приводило в Ад.

Сама я в продакшн пробовала только goose (как раз для PostgreSQL), встроить в приложение можно было, насчет локов точно не скажу, но да, в случае с несколькими инстансами проблем не было.

Вообще, я сейчас (вот прямо сейчас) как раз пишу управление миграциями для reform, но, думаю, пока там всё будет готово к продакшн, пройдет еще какое-то время.

Приходите к нам в русскоязычный слак — slack.golang-ru.com, у нас там есть канал #databases как раз для таких вопросов — может, кто что интересное посоветует из своего опыта.