зачем сами шаблоны — как я понял, вы используете стандартные шаблоны, нас они не устраивают, поэтому мы используем свои. При этом мы не коммитим основную часть сгенерированного кода (по ряду причин), поэтому шаблоны храним в самом сервисе. Так же это добавляет удобство при редактировании api — у нас автоматически создаются файлы хэндлеров с заглушками, меняются / добавляются модели api — такая рутинная работа делается автоматически.
Что касается в целом подхода — собственно об этом статья:)
Основные причины — поддержка актуальности контрактов api, единый подход подходам в разработке сервисов, автоматизация рутинных задач.
Верно, по-умолчанию — swagger, но для того, чтобы либа не конфликтовала с текущей версией (если установлена), я в доке по установке указал goswagger: github.com/delivery-club/go-swagger-example
это верно, но как сказано в комментарии по вашей ссылке — для большинства задач второй версии хватает.
Варианты перехода на 3ю версию есть, но еще не дошли до конкретного решения.
minikube — это да, но интересуют нюансы, например, как монтируются локальные директории, чтобы они были доступны в подах (при этом, желательно не плодить разны конфигурации кластера для дева и прода )?
Возможно используется helm для работы поддержания 1 конфигурации в разных контурах? Как происходит отладка приложения?
Спасибо за статью, подскажите, используете ли Вы kubernetes в локальной разработке? Если да, то как?
Запуск тестов в docker-образе это конечно хорошо, но как Вы тестируете взаимодействие нескольких сервисов (подов)?
Спасибо!
Я думаю, что подобные инструменты действительно заточены под конечных пользователей, а для студий, наверно, предполагается использовать более профессиональные инструменты. ИМХО, конечно
Вопрос от новичка — разве так можно? Ведь теперь образ не соответствует тому, что написано в Dockerfile. Что будет, если я завтра решу пересоздать образ из Dockerfile?
Вы вернетесь к первоначальному состоянию.
А представьте, что те изменения, которые вы накатили — были не нужны? Снова изменте Dockerfile? — если изменений не много это будет легко, а иначе — посложнее.
Собственно я к тому, что «слоистая архитектура» докера тем и хороша, что при изменениях контейнера достаточно эти изменения закомитить (при необходимости вернуться на одно из предыдущих состояний) и там где еще используется этот контейнер нужно будет просто сделать пулл — в таком случае не нужно полностью собирать контейнер заново. Т.е. некая реализация vcs, а Dockerfile для первоначальной настройки.
Но как я уже писал — и только погружаюсь эту тему)
В 3м подходе локальные интерфейсы, наверно, стоит сделать приватными
Что касается в целом подхода — собственно об этом статья:)
Основные причины — поддержка актуальности контрактов api, единый подход подходам в разработке сервисов, автоматизация рутинных задач.
Варианты перехода на 3ю версию есть, но еще не дошли до конкретного решения.
Поправим.
github.com/golang/go/wiki/CodeReviewComments#interfaces
Поддерживаю, странная история, что верхняя планка бэка в мск — 160, а верхняя планка go-разработчика (который тоже бэк) — 200
А я как-раз недавно лиду дал "Цель" почитать)
Про api не написали, а оно есть
Возможно используется helm для работы поддержания 1 конфигурации в разных контурах? Как происходит отладка приложения?
Запуск тестов в docker-образе это конечно хорошо, но как Вы тестируете взаимодействие нескольких сервисов (подов)?
Спасибо!
С ассемблером тест проводили?
Я думаю, что подобные инструменты действительно заточены под конечных пользователей, а для студий, наверно, предполагается использовать более профессиональные инструменты. ИМХО, конечно
Вы вернетесь к первоначальному состоянию.
А представьте, что те изменения, которые вы накатили — были не нужны? Снова изменте Dockerfile? — если изменений не много это будет легко, а иначе — посложнее.
Собственно я к тому, что «слоистая архитектура» докера тем и хороша, что при изменениях контейнера достаточно эти изменения закомитить (при необходимости вернуться на одно из предыдущих состояний) и там где еще используется этот контейнер нужно будет просто сделать пулл — в таком случае не нужно полностью собирать контейнер заново. Т.е. некая реализация vcs, а Dockerfile для первоначальной настройки.
Но как я уже писал — и только погружаюсь эту тему)