Здравствуйте, Pauel, Вы писали:

P>>>changelog сам пойдет тестировать задеплоеные сервисы и
P>·>Ну да, естественно. Деплоймент и прогон тестов называется. Выкатываешь новую версию и смотришь какие тесты упали.
P>Очевидно — никакие. Дальше что?
Дальше работаем.

P>>>проверять, покрывают ли тесты все критические места или нет?
P>·>У тестов должно быть ровно два состояния — PASS и FAIL. Чем тут помогут warnings?
P> Подозреваю, щас у тебя будет очередной аргумент "а надо писать без багов". 100% покрытие просто недостижимо, даже если считать по строчкам кода. Отсюда ясно, что должны быть другие механизмы обнаруживать и репортить ошибки
P>1. логирование
P>2. мониторинг
P>3. эксплорейтори тестирование (не путать с рандомным)
P>4. ассерты, варнинги, фолты, итд
Это всё внутренняя кухня. Зачем это слать наружу, в каждом респонзе и засирать прод трафик-то? С учётом того, что консьюмеры это могут всё влёгкую игнорировать.

P>>>·>Это всё средства.
P>>>Это автоматизируется.
P>·>Добавление хедеров и варнингов в правильных местах? Правильная реакция на неправильные хедеры? Что именно автоматизируется-то?
P>Тебе что, не ясно, что такое мониторинг? Цитирую себя:
P>"А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и "
Ты обещал автоматически. Как автоматически появится такой мониторинг? И как ты убедишься, что этот мониторинг есть и выдаёт адекватные сигналы? Кто будет проверять эти сигналы? Никакой автоматики я пока не вижу — всё придётся вручную сооружать, расставлять эти варнинги, майнтейнить, анализировать и... в итоге слать менеджерам письма, чтобы они на эти варнинги хоть как-то реагировали. Не проще ли сразу начать с писем?

P>>>А changelog — нет.
P>·>changelog автоматизировать на порядки легче. Даже во всяких github/jira это всё из коробки.
P> ну написано в там — пофиксили уязвимость в парсере. твои тесты зелёные. Дальше что?
Ты сценарий не с потолка бери, а начни с того, как тебе помогут варнинг-хедеры.

P>>>Степенью автоматизации.
P>·>Верно. Емейлы-то элементарно автоматизируются. Чего не скажешь о кастомных хедерах.
P>С емейлами одна проблема — это в чистом виде человеческий фактора, например, потому что "устал, много писем, (не)прочитаю в понедельник"
P>Я например регулярно сталкиваюсь с ситуацией , что какой либо менеджер не отвечает на письма. Думаешь если ему подкинуть еще сотню-другу емейлов, так он быстрее разгребется?
Ясно. Хедеры значит этот менеджер читает, а на емейлы сил уже не хватает.

P>>>Неважно, первая или последняя. Закладываться на один только changelog идея так себе — например, некто забыл включить строчку этот changelog. Приплыли.
P>·>Тесты должны упасть.
P>Ну ок — реквест состоит из 100 переменных true-false, как долго будешь искать, какая же комбинация "та самая"?
Не дольше, чем искать для какой комбинации нужен варнинг.

Здравствуйте, Pauel, Вы писали:

P>>>changelog сам пойдет тестировать задеплоеные сервисы и
P>·>Ну да, естественно. Деплоймент и прогон тестов называется. Выкатываешь новую версию и смотришь какие тесты упали.
P>Очевидно — никакие. Дальше что?
Дальше работаем.

P>>>проверять, покрывают ли тесты все критические места или нет?
P>·>У тестов должно быть ровно два состояния — PASS и FAIL. Чем тут помогут warnings?
P> Подозреваю, щас у тебя будет очередной аргумент "а надо писать без багов". 100% покрытие просто недостижимо, даже если считать по строчкам кода. Отсюда ясно, что должны быть другие механизмы обнаруживать и репортить ошибки
P>1. логирование
P>2. мониторинг
P>3. эксплорейтори тестирование (не путать с рандомным)
P>4. ассерты, варнинги, фолты, итд
Это всё внутренняя кухня. Зачем это слать наружу, в каждом респонзе и засирать прод трафик-то? С учётом того, что консьюмеры это могут всё влёгкую игнорировать.

P>>>·>Это всё средства.
P>>>Это автоматизируется.
P>·>Добавление хедеров и варнингов в правильных местах? Правильная реакция на неправильные хедеры? Что именно автоматизируется-то?
P>Тебе что, не ясно, что такое мониторинг? Цитирую себя:
P>"А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и "
Ты обещал автоматически. Как автоматически появится такой мониторинг? И как ты убедишься, что этот мониторинг есть и выдаёт адекватные сигналы? Кто будет проверять эти сигналы? Никакой автоматики я пока не вижу — всё придётся вручную сооружать, расставлять эти варнинги, майнтейнить, анализировать и... в итоге слать менеджерам письма, чтобы они на эти варнинги хоть как-то реагировали. Не проще ли сразу начать с писем?

P>>>А changelog — нет.
P>·>changelog автоматизировать на порядки легче. Даже во всяких github/jira это всё из коробки.
P> ну написано в там — пофиксили уязвимость в парсере. твои тесты зелёные. Дальше что?
Ты сценарий не с потолка бери, а начни с того, как тебе помогут варнинг-хедеры и каким образом они появятся _автоматически_ как ты обещаешь.

P>>>Степенью автоматизации.
P>·>Верно. Емейлы-то элементарно автоматизируются. Чего не скажешь о кастомных хедерах.
P>С емейлами одна проблема — это в чистом виде человеческий фактора, например, потому что "устал, много писем, (не)прочитаю в понедельник"
P>Я например регулярно сталкиваюсь с ситуацией , что какой либо менеджер не отвечает на письма. Думаешь если ему подкинуть еще сотню-другу емейлов, так он быстрее разгребется?
Ясно. Хедеры значит этот менеджер читает, а на емейлы сил уже не хватает.

P>>>Неважно, первая или последняя. Закладываться на один только changelog идея так себе — например, некто забыл включить строчку этот changelog. Приплыли.
P>·>Тесты должны упасть.
P>Ну ок — реквест состоит из 100 переменных true-false, как долго будешь искать, какая же комбинация "та самая"?
Не дольше, чем искать для какой комбинации нужен варнинг.