mirror of
https://github.com/3ybactuk/marketplace-go-service-project.git
synced 2025-10-30 05:53:45 +03:00
120 lines
11 KiB
Markdown
120 lines
11 KiB
Markdown
# Шаблон репозитория для реализации проекта на курсе 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).
|
||
|
||
<em><strong>
|
||
Обрати внимание!
|
||
Если не разорвать связь с проектом, можно случайно отправить изменения в общий проект с шаблоном курсового проекта!
|
||
</strong></em>
|
||
|
||
|
||
Рис. 1. Создаем копию проекта
|
||
|
||
|
||
Рис. 2. Переходим в продвинутые настройки репозитория
|
||
|
||
|
||
Рис. 3. Разрываем связь в шаблонным проектом
|
||
|
||
|
||
Рис. 4. Настройки участников проекта
|
||
|
||
|
||
Рис. 5. Добавить новых участников
|
||
|
||
|
||
Рис. 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/configs/values_ci.yaml) такого файла для сервиса `cart`, который используется в CI/CD пайплайне
|
||
(НЕ МОДИФИЦИРОВАТЬ).
|
||
|
||
Файлы конфигурации для локального запуска так-же [находятся в репозитории](cart/configs/values_local.yaml).
|
||
|
||
## Troubleshooting
|
||
1. Чтобы запустить product-service локально требуется выполнить команду
|
||
|
||
```
|
||
docker login gitlab-registry.ozon.dev
|
||
```
|
||
логин и пароль такие-же, как для доступа к https://gitlab.ozon.dev/
|
||
|
||
2. Если при прохождении джобы с тестами вы получаете ошибку
|
||
```
|
||
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
|
||
```
|
||
напишите об этом тьютору, чтобы он сделал необходимые настройки. После подтверждения от тьютора, что работы проведены - просто перезапустите пайплайн
|