Comments 17
Скажите, вот зачем вам в проект тащить конфиги, деплойменты и вообще все то что относиться к DevOps, во первых хранить конфиги рядом с проектом так себе идея, хранить примерный не рабочий конфиг конечно можно, да и обычный никто не запрещает, но есть критерии безопасности, внеся в конфиг что то важное можно это и закомитить ненароком.
Далее деплойменты, я понимаю конечно что это удобно например приходит новый разраб сделал чекаут и может уже куда то задеплоить, например в неймспейс кубера который ему выдали. Или локально. Я ничего не имею против композ файла, но хельм чарты там зачем?
Вообще микросервисов может быть много все они деплоиться могут +- одинаково или разно, да и вообще это девопс задача. И пусть они ими и занимаются, и дают отдельный доступ к отдельному репо с конфигом и деплойментом.
По моему мнению в репозитории с кодом должен лежать только код, и документация к нему. А все что касается его доставки должно жить отдельно. Лично мое мнение мешать мух и котлет можно, если у вас демо проект для обучения или демонстрации возможностей или продукта. Тогда я не спорю, это удобно сам так делаю, прикладываю конфиги и композ файлы, так как изначально знаю что ссылку на проект получит мой коллега имеющий меньший опыт чем я, и для простоты работы для него сделано все вместе, так как он только обучается. Но когда у нас коммерческий проект имхо это лишнее, пусть разрабы пишут код а девопсы его катят...
Появится новая переменная, зависимая от окружения, часть конфигурации. Получается на каждое такое изменение нужно будет дергать девопса или лезть в другую репу?
Как раз очень удобно иметь deployment-ы рядом. А еще часто для отладки локально, создается локальный деплоймент. То есть в проекте лежит все что к нему относится. И деплойменты - это примеры конфигурации. Особенно если новый человек смотрит на проект, он получает максимум информации о нем.
Go хорош как раз тем, что в нем нету этой дичи с навязыванием структуры директорий, как в Django, RoR, разных PHP и JS фреймворках.
Если часть функционала не используется - образуются ненужные директории, а иногда файлы с плейсходерами.
Чуть в сторону отойти надо - и уже приходится вкручивать костыли в эту красивую структуру.
Не надо заниматься усложнением и пытаться формализовать то, что это не требовало
у фреймворков в ГО, по типу gorm и тому подобных тоже нет таких требований
ну если отталкиваться от определения что есть фреймворк то конечно нет, и не будет наверное ибо противоречит идеологии, но то для чего обычно используют фреймворки есть отдельными либами, gorm, mux и прочие
ну и специально для вас
https://github.com/cosmos/cosmos-sdk
https://github.com/oklahomer/go-sarah
и еще куча фреймворков которые так же можно нагуглить
Ну так и автор зачем-то в язык притягивает то, чем изготовители фреймворков занимаются. В этом и суть, что Go — это не фреймворк, и натягивать какую-то формальную структуру смысла нет, даже если вы пишете бэкенд, а не консольное приложение, например.
И что характерно, даже Go фреймворки не требуют какую-то жёсткую привязку к структуре директорий.
С версии Go 1.4 определен механизм, который не позволяет импортировать пакеты вне данного проекта, если они находятся внутри /internal.
Вот прямо внутрь компилятора встроена проверка, что в пути к импортируемому пакету не встречается папка internal?
Привет! это реализовано на уровне языка. Есть специальный go-инструмент, который распознает internal каталог и предотвращает импорт одного пакета другим, если оба не имеют общего предка. Более подробная инфа здесь - https://docs.google.com/document/d/1e8kOo3r51b2BWtTs_1uADIA5djfXhPT36s6eHVRIvaU/edit
Оставлю тут: project layout.
Как структурировать проект на Golang: гайд от backend-разработчика