Никита Шубин 3ebaad5558 Merge branch 'hw-3' into 'master'
[hw-3] loms service

See merge request nvshubin1/homework!3
2025-06-20 10:11:59 +00:00
2025-06-20 10:11:59 +00:00
2025-06-20 10:11:59 +00:00
2025-03-21 09:40:42 +03:00
2025-06-20 10:11:59 +00:00
2025-06-20 10:11:59 +00:00
2025-06-20 10:11:59 +00:00
2025-03-21 09:40:42 +03:00
2025-06-20 10:11:59 +00:00
2025-06-20 10:11:59 +00:00
2025-03-21 09:40:42 +03:00
2025-06-20 10:11:59 +00:00
2025-06-20 10:11:59 +00:00
2025-06-20 10:11:59 +00:00
2025-06-20 10:11:59 +00:00
2025-03-21 09:40:42 +03:00

Шаблон репозитория для реализации проекта на курсе Route 256

Поздравляем с зачислением на курс "Продвинутая разработка микросервисов на Go"! Надеемся, что процесс обучения будет увлекательным, а полученные знания пригодятся в работе!

В рамках курса вам предстоит разработать проект– копию Озона в миниатюре. Не нужно пугаться, ведь на этом пути вас будет сопровождать команда преподавателей и тьюторов. Работа над проектом будет разбита из 8 модулей, каждому из которых, посвящены две лекции и одно практическое занятие. Действующие инженеры Озона поделятся своим опытом и обратят внимание на важные аспекты, которые неизбежно возникают при разработке высоконагруженных распределенных систем. По окончании каждого модуля будет предложено реализовать ту или иную часть из курсового проекта, имеющую непосредственное отношение к теме модуля.

Желаем успехов в прохождении курса!

Работа над курсовым проектом

Инициализация проекта

Для работы над курсовым проектом необходимо выполнить инициализацию репозитория:

  1. Открыть репозиторий https://gitlab.ozon.dev/go/classroom-18/students/homework-draft (вы уже в нем);
  2. Создать копию данного репозитория https://gitlab.ozon.dev/go/classroom-18/students/homework-draft (форк проекта в свой приватный репозиторий (см. рис. 1));
  3. Разорвать связь с шаблонным репозиторием, для этого в GitLab необходимо выполнить: Settings Advanced Remove fork relationship (см. рис. 2 и 3);
  4. Добавить тьютора в Members проекта. Для этого: Project information Members Invite member, пригласить своего тьютора с правами Maintainer (см. рис. 4, 5 и 6).

Обрати внимание! Если не разорвать связь с проектом, можно случайно отправить изменения в общий проект с шаблоном курсового проекта!

Рис. 1. Форк проекта Рис. 1. Создаем копию проекта

Рис. 2. Продвинутые настройки Рис. 2. Переходим в продвинутые настройки репозитория

Рис. 3. Разрыв связи Рис. 3. Разрываем связь в шаблонным проектом

Рис. 4. Настройки участников проекта Рис. 4. Настройки участников проекта

Рис. 5. Добавить новых участников Рис. 5. Добавить новых участников

Рис. 6. Добавление тьютора с ролью Maintainer Рис. 6. Добавление тьютора с ролью Maintainer

Выполнение домашнего задания:

  1. В своём форке проекта необходимо создать ветку от master под выполняемое задание. Ветку необходимо (MUST) назвать hw-N, где N номер модуля, к которому относится выполняемое задание;
  2. Выполнить задание;
  3. Создать мерж-реквест ветки с решением в master в своём форке проекта;
  4. Уведомить тьютора об отправке решения на проверку и поделиться ссылкой на мерж-реквест в Telegram;
  5. После проверки задания тьютором он может оставить комментарии к решению. Если требующие исправления замечания отсутствуют, тьютор засчитывает решение, оставляя отметку (approve) на мерж-реквесте. По итогам проверки тьютор проставляет оценку за работу в таблице прогресса;
  6. Необходимо устранить все обязательные замечания и добиться успешного прохождения проверки тьютором;
  7. После того как решение зачтено тьютором, и работа над ним со стороны студента завершена, решение необходимо вмержить в ветку master.

Формат названий на курсе Go на примере домашнего задания №1 (HW1):

Формат наименования Пример
Для ветки hw-1
Для коммита [hw-1] Свободный комментарий
Для мерж-реквеста [hw-1] Свободный комментарий

Прохождение автоматизированных проверок

На текущем потоке мы в пилотном режиме запускаем систему автоматизированной проверки решений. Это не означает, что тьюторы будут проверять решения менее тщательно, напротив– мы хотим освободить тьюторов от рутинных проверок и помочь им фокусироваться на проверке других важных аспектов реализации. Это требует от вас внимательнее относится к именованию веток, потому что для запуска проверок необходимо чтобы ветки удовлетворяли указанному шаблону hw-N.

Поскольку это пилотный запуск тестирующей системы, возможно возникновение проблем в ее работе, в том числе ложно негативных срабатываний, успешное прохождения решением всех автоматизированных проверок не является обязательным. Тем не менее постарайтесь, чтобы ваше решение проходило столько проверок, на сколько это возможно. Уделите внимание проверкам кода (линтеру golangci-lint). Все это поможет избежать лишних замечаний в мерж-реквестах, которые непременно оставит тьютор, и позволит сдать задание быстрее и за меньшее количество проверок.

Блюдите культуру и гигиену работы с git, постарайтесь не пушить бессодержательные коммиты в систему контроля версий. Количество коммитов не оценивается. Большое количество коммитов вызывает запуск автоматизированных проверок, а ввиду ограниченности ресурсов это может создать очередь в их прохождении. Более того, большое количество коммитов в репозитории, где одновременно работает много разработчиков (как обычно и бывает на настоящем крупном проекте), может затруднить слияние и разрешение конфликтов, сложнее понять состояние репозитория и ориентироваться в истории. Хорошей практикой считается выполнение объединения коммитов в один (squash) перед созданием мерж-реквеста и аналогичное объединение коммитов с исправлениями в один перед повторной отправкой тьютору на повторную. Таким образом количество коммитов в ветке будет соответствовать количеству итераций проверки. Мы не считаем количество коммитов и не оцениваем работу по этому признаку. Сказанное выше является рекомендацией, но не требованием.

Чтение файла конфигурации

В вашем решинии каждый из сервисов должен (MUST) использовать переменную окружения CONFIG_FILE в которой указан ПУТЬ до файла конфигурации.

Пример такого файла для сервиса cart, который используется в CI/CD пайплайне (НЕ МОДИФИЦИРОВАТЬ).

Файлы конфигурации для локального запуска так-же находятся в репозитории.

Troubleshooting

  1. Чтобы запустить product-service локально требуется выполнить команду
docker login gitlab-registry.ozon.dev

логин и пароль такие-же, как для доступа к https://gitlab.ozon.dev/

  1. Если при прохождении джобы с тестами вы получаете ошибку
ERROR: Job failed: failed to pull image "gitlab-registry.ozon.dev/go/...." with specified policies [always]: Error response from daemon: pull access denied for gitlab-registry.ozon.dev/go/...., repository does not exist or may require 'docker login': denied: requested access to the resource is denied

напишите об этом тьютору, чтобы он сделал необходимые настройки. После подтверждения от тьютора, что работы проведены - просто перезапустите пайплайн

Description
A microservice architecture of a marketplace platform project that I did on a "Go Microservice Development Course [Middle]"
Readme 8.4 MiB
Languages
Go 93.1%
Makefile 6%
Dockerfile 0.9%