Здравствуйте, Sharov, Вы писали:
S>А какая предментая область, если не секрет?
B2B2C. Если совсем упрощенно, мы делаем некоторые сервисы для интернет-магазинов. Т.е. наши клиенты — интернет-магазины. Но наши (условно) плагины видны посетителям интернет-магазинов. Моя команада отвечает за платежи и все, что с ними связано.
S>И кто придумал этот пайплайн -- скопипастили у кого-то или продиктовано бизнес потребностями?
Скорее так исторически сложилось на основе организационной структуры. Когда-то давно, может, и скопировали. Но с тех пор практически все уже поменялось. Например, изначально CI разрабатывался вообще отдельной командой без какой-либо связи с продуктовыми командами. Разработчикам спускались инструкции "пишите так и только так" (в виде огромного boilerplate для каждого проекта). Сейчас ситуация меняется, появляется обратная связь и больше свободы. Promotion approval — по большей части исторические. Зависят от уровня паранойи у руководства. При этом считаюстся по худшей команде. Т.е. косячит одна команда, а репрессии устраивают всем. Тоже есть подвижки в сторону упрощения. Хотя конкретно у нас какая-то часть будет идти строго из-за специфики платежей. Мы вообще PCI-certified, для этого нужно немного бюрократии. Логи/алерты — смесь "глобальных технических инициатив" и конкретно нашей команды.
Многие части процесса или особенности наши (определяются внутри команды). Они нам подходят и какого-то особого недовольства не доставляют.
Boilerplate/skeleton — это заготовка с основными аспектами (каркас web-обработчиков, логи, мониторинг, деплоймент, база), принадлежит нашей команде. Вообще у нас в команде достаточно радикальная политика по отношению к фреймворкам и библиотекам: "Если библиотека/фреймворк не устраивает — можно (и даже рекомендуется) велосипедить так, чтобы было удобно". Я не хочу, чтобы мы тратили время только потому, что когда-то приняли формальное решение. Это повышает требования к качеству библиотек. И особенно — к их модульности. Так что, с одной стороны, мы на конкретном проекте можем изменить конкретный выбор. Например, не нравится веб-уровень — можно сделать другой (бюрократии нет, но причины нужно где-нибудь записать). Или решить отдавать метрики в другом формате. Или, например, использовать какой-то специфический слой для базы. Но это же значит, что мы не можем просто "включить фреймворк" в котором есть все (потому что в нем со временем может оказаться куча ненужного). Так и появляесят полуфабрикат — все вроде есть, но можно открутить (сейчас или потом) что угодно. Стандартный набор велосипедов и деталей у нас удачный. Так что "взять базу и выпилить лишнее" работает хорошо и в краткосрочной, и в долгой перспективах.
Merge request — это правила хорошего тона уже практически везде. Плюс по нашим процессам я почти во всех outages участвую в группе поддержки. Поэтому мне лично интересно, чтобы если что-то падало, то падало в одном месте и заметно. А не отдавалось фантомными болями где-то далеко-далеко. И у меня обычно есть возможность быстро переключиться с текущей задачи и сделать ревью. CI у нас делает pre-merge. Проходит оно быстро (меньше 10 минут обычно), типичное ревью занимает больше времени. Так что merge check нас не замедляет. Иногда он даже падает (иначе бы упало после мержа), так что некоторая польза есть. А еще у нас члены команды имеют разные интересы (кому-то интереснее технические детали, кому-то — бизнес) и ревью дает разносторонние отзывы.
Так как мы платежи, тестироваться интеграционно с реальными системами нам сложно. А тестирование в pre-merge еще и не ложится в environments. Здесь нам очень помогают различные эмуляторы. Заодно мы можем эмулировать "особенности" наших поставщиков услуг. Заодно упрощается и локальная разработка. Честные "интеграционные" тесты мы тоже делаем вручную, но это долго, сложно и не автоматизируется.
Promotion я уже сказал. Частично — исторически-бюрократические, частично — для PCI и прочего legal.
Метрики — фишка нашей команды. Я лично считаю, что найти что-то в логах на хоть какой-то интересной нагрузке (допустим, мизерные 100 запросов в минуту) становится практически не реально. Если добавить несколько экземпляров сервиса и несколько других систем, все становится очень печально. В метриках можно делать почти все то же, что в логах (вместе с записью исключения можно и счетчик увеличить). Потом мы можем сначала посмотреть на дашборды а потом прогнать какие-нибудь ручные запросы по метрикам. Т.е. тормозит "все" или конкретные типы запросов? Привязано это к отдельной машине или медленно везде? Что у нас с вызовами persistence и внешних сервисов? И все это в динамике (сейчас, час назад, "обычно").
Логи в нашей организации — отдельная грустная история. Чтобы логи были полезны, они должны содержать достаточно информации. Поэтму они становятся "большими". Бизнес жалуется, что все дорого и просит логи почикать. А почиканные логи становятся бесполезными. В рамках "дорого" мы еще и несколько миграций logging system сделали. Поэтому "проверить, что логи видны" — суровая необходимость. Мало-ли что отвалится. А конкретные exception traces все же бывают полезны. Обычно уже после того, как что-то нашли в метриках. Или для новой функциональности, когда у нас все работает с тестовой средой вендора, а в production все ну совсем по-другому. Поэтому полностью отказаться от логов мы тоже не можем.
Alerts — это еще сверху к логам и метрикам. Мы 24/7 работаем и вроде как в надежности хотим минимум 99.9% доступности. Поэтому нужны alerts. Желательно — до того, как наши клиенты начали жаловаться (это добавляет необходимость успокаивать нашу команду поддержки). Обычно все сводится к "вендор упал — звоните им и спрашивайте", но иногда бывает и интереснее.
Лично мне процесс в целом нравится. Команде — тоже. Некоторые вещи можно сделать лучше, но не все зависит от нас. Alerts происходят напрямую из бизнес-требований. Часть — была задолго до меня (и вообще до нашей команды). Почти половину мы сделали сами в команде для себя. Если переводить на язык бизнеса — уменьшает время на разработку (boilerplate — локально и "сейчас", принципы — для того, чтобы в будущем не застопориться на каких-нибудь несовершенствах). Еще мы повышаем надежность в ревью/тестировании (вклад в количество девяток). Также имеем хороший observability (т.е. меньше времени требуется на обнаружение и исправление проблем, тоже в девятки идет).
