Зависимости. Дженерики. Они часто звучат в списке проблем в Go сообществе, но есть одна проблема, о которой вспоминают довольно редко — организация кода вашего пакета.

Каждое Go приложение, с которым я работал, похоже, имеет свой ответ на вопрос "Как я должен организовать код?". Некоторые приложения засовывают всё в один пакет, в то время, как другие группируют логику по типам или модулям. Без хорошей стратегии, которой придерживаются все члены команды, вы рано или поздно увидите, что код сильно разбросан по многочисленным пакетам. Нам нужен некий стандарт для дизайна кода в Go приложениях.

Я предлагаю подход получше. Следуя набору простых правил, мы можем добиться того, что код будет несвязанным, легко тестируемым и структура проекта будет цельная. Но прежде, чем мы углубимся в детали, давайте посмотрим на наиболее часто используемые подходы к структуризации Go кода.

Хотел бы поделиться опытом настройки CI/CD в нашей компании, плюс, послушать советы, если у вас похожая структура проектов.

Кому, как мне кажется, данная статья может оказаться полезной:

• ваши проекты содержат несколько отдельных репозиториев с приложениями;
• вы хотите быть уверены, что каждый репозиторий проходит тесты;
• вы хотите быть уверены в совместимости версий между репозиториями;
• вы ещё не успели, но планируете, перевести свои проекты на докер;
• хотите посмотреть пару playbook'ов Ansible.