Здравствуйте, Qulac, Вы писали:
Q>Главный вопрос: Сколько времени у Вас потребуется программисту для добавления нового модуля(сервиса) в систему и довести его до продакшена.
Норматив — один рабочий день. Т.е. если в один день я на стендапе слышу "я начал минимальный сервис", на следующем я должен услышать "он был задеплоен, работаю над следующей задачей". Сколько там потратил программист — не важно. Если вдруг сервиса не будет — я уже буду разбираться, что и где пошло не так. Там не так много работы, но для
нового сервиса есть некоторая специфика. Процесс примерно следующий:
Взять скелет приложения. Отрезать лишнее, проверить базовые настройки, проверить настройки (пакеты в коде, имя приложения для деплоймента и мониторинга, требуемые ресурсы, autoscaling и прочие радости). Приложение "без базы" на данном этапе потребует чуть больше работы, чем с базой. У нас база в скелете 
. Сделать обработчик. Прогнать тест локально. На это уйдет полчаса-час.
Залить в source control, сделать MR.
Попинать CI, чтобы оно быстрее проект заметило (это я плохо пинаю ответственных за CI, чтобы сделать процесс чуть быстрее).
Дождаться аппрува на MR
Смержить
Найти ответственных за promotion (они вообще от времени года зависят!). Получить подтверждение, задеплоить. И так для каждой среды в цепочке.
Сделать операционную документацию. Вроде "сервис ничего не использует. Падать не должен. Если упадет — удивиться и перезапустить". По моим наблюдениям ее никто не читает. Но заполнять надо — традиция бюрократия. Полчаса примерно.
Сделать дашборды для метрик. Они как раз используются, когда операторы, не читавшие документацию из предыдущего пункта, пытаются сказать, что сервис не работает. А мы можем на метрики посмотреть и сказать, что все работает по плану. 15-30 минут.
Проверить, что логи видны.
Подумать про alerts. Сделать их или решить, что не нужно.
Вот это то, что у нас считается production приложением. И все из этого входит в норматив.
Сложности здесь скорее в переключениях типов работы. В промежутках разработчик может еще на какой-нибудь корпоративный митинг сходить (пока другие смотрят MR), выкурить чаю, откомментировать другие MR и т.п. В режиме буста (когда все рядом и готовы давать approval) часа за 2 можно все сделать. Часть — бюрократия вне нашего контроля. Еще часть не оптимизирована под новые приложения — новые сервисы не так часто делаются, чтобы инвестиции времени окупились.
