- Строго после сдачи 1-й работы (я закрыл issue без вопросов) приступить к выполнению issues из своего проекта, следуя выбранному методу управления ветками.
- Задачи необходимо линковать с issues. Если в процессе работы возникнет необходимость создать дополнительную issue под фичу или баг -- можно смело это сделать.
- Предоставить возможность запуска своего сервиса в Docker-контейнере. При этом финальный образ должен быть чист от промежуточных артефактов сборки (используйте multistage build).
- После завершения работы, подготовить релиз (в случае
git-flow, этоrelease/ветка и коммит вmaster). Протегать свой релиз (в случае GitHub, справа есть колонка, где можно указать тег решиза и написатьrelease notes). В процессе подготовки релиза, обновитьREADME.mdфайл, он должен содержать информацию о проекте, инструкцию по его сборке и запуску и пару примеров работы. - Отправить мне на проверку (так же создать issue в моём репо) -- https://github.com/SemenMartynov/Software-Engineering-2022
- Пока не нужно беспокоиться о тестах, это будет в следующей работе.
Задание принято, если я закрыл issue. Мягкий дедлайн по этой работе -- 03 декабря. Тогда за 04 декабря я постараюсь всё проверить.
- Просто напоминаю, что это должна быть оригинальная работа автора.
- Нарушение методов управления ветками (к примеру, прямые коммиты в
masterилиdevelopветки при работе по git-flow). - Нарушение хороших практик работы с git (если не настроен
.gitconfigв системе, и коммиты идут от неизвестного пользователя). - Коммиты не слинкованы с issues, либо один коммит имеет решения для задачи выходящий за скоуп одной issue (коммит должен решать только ту задачу, которая поставлена в issue).
- Наличие мусора в репозитории (бинарники, служебные файлы используемой IDE) -- всё это должно быть прикрыто
.gitignode. Однако Gradle Wrapper в репо допускается. - Плохое (не полное, непонятное) описание сообщений к коммитам.