Когда решение готово - аналитик показывает решение разработчикам. Возможно, аналитик упустил детали из-за неполного понимания внутренней архитектуры системы. Разработчиками проводится ревью решения и, если что-то не учтено, предлагают, как можно улучшить.
Может быть такое, что где-то лучше использовать подход с асинхронным взаимодействием между сервисами, использовать kafka, а не restAPI.
Аналитик вносит изменения до тех пор, пока разработчики не согласятся с решением.
Иногда прибегают к помощи архитектора, если не получается прийти к согласию.
Далее это решение нужно разбить на задачи для параллельной разработки. Это делет вся команда разработки или один человек, например, технический лидер, который хорошо разбирается в системе. Он разбивает всю задачу на список конкретных подзадач, что предстоит сделать в каждом сервисе.
После разбиения, команда встречается на груминге, вместе оценивают каждую задачу по трудозатратам.
Про встречи внутри команды писал тут
Этап разработки
Задачи должны быть распределены между разработчиками. Это происходит на планировании спринта, когда решается, что будет включено в новый спринт. На планировании задачи распределяются по разработчикам, которые затем их выполняют.
В процессе разработки разработчик обращается к аналитику за уточнением требований или советуется с коллегами о способе реализации. Параллельно с кодом разработчик пишет тесты для нового функционала (в идеале). После завершения разработки код направляется на code review, где другие разработчики проверяют его на соответствие требованиям, стилю кодирования и отсутствие ошибок. Если присутствуют какие-то серьезные разногласия на code-review, то собирается встреча разработчиками и обсуждается решение, приходят к общему мнению.
Насчет разработки на Java, у меня есть серия видео разработки приложения с самого нуля до деплоя.
Тестирование
Разработчик пишет задание на тестирование или тестировщик самостоятельно ознакамливается с решением аналитика. Тестировщик проверяет, ведет ли система себя так, как ожидается, и если обнаруживаются ошибки, отправляет их обратно разработчику для исправления. Этот процесс повторяется до тех пор, пока все ошибки не будут устранены.
Тестирование бывает проходит за 1 день, а в некоторых случаях длится неделю или даже до месяца. Может потребоваться проверить сборку на разных стендах. Если есть интеграции со смежными командами, то их надо все проверить. Каждое тестирование со смежной командой может сопровождаться специальной заявкой на проведение тестирования.
Релиз
После проверки тестировщиком задача переводится в статус "Готово к релизу". Сборка с новым функционалом должна отправиться на продакшн. В разных компаниях процесс может отличаться.
‘Выкатить релиз’ — поставить сборку сервиса с новым функционалом на прод. сервера, убедиться что он работает корректно.
Пример №1 - релиз катит сам разработчик, который писал новую фичу
Разработчик сам следит за метриками, логами в реальном режиме, что бы проверить что все встало корректно.
Если разработчик видит ошибки или некорректную работу фичи - откатывает релиз на старую версию.
Обычно в крупных компаниях приложение запущено не в единственном экземпляре. Запущено несколько экземпляров сервиса, которые находятся под балансировщиком нагрузки. В этом случае используется *канареечный релиз*. Если у вас поднято 10 экземпляров сервиса, то 1 из них останавливается и вместо него поднимается экземпляр с новой версией. Получается 9 сервисов со старой версией и 1 с новой. Проверяется как работает сервис с новой версией. Это помогает уменьшит аффект на пользователей, если в новой сборке есть ошибки.
Пример №2 - релиз катит сопровождение
Тот же механизм раскатки, только это делают не разработчики, а специальные люди из сопровождения прода. Когда они катят на прод, могут разработчика позвать вместе с ними посмотреть логи релиза, если там есть какие-то ошибки. Если релиз установить не получилось, то они присылают тебе ошибки, которые случились.
У меня в канале еще больше про Java
Вступай в сообщество | Расти в IT | Присылай историю