Я бы не назвал это велосипедом — скорее лайфхак. NPX это не только запуск одноразовых скриптов — вот тут прекрасно все описано medium.com/...​ckage-runner-55f7d4bd282b

В L1/L2/L3 нету места обучению — их задача решать проблемы. Я же пытался донести, что по итогу надо учить команды, дабы в будущем снизить количество обращений в L1/L2/L3

Инфраструктурная команда и работает через тикеты. Однако часто надо говорить — твой тикет не приоритетный, мы сосредоточены сейчас на другой более важной и глобальной работе

Тут дело о том что инфраструктурная команда должна помогать идти вперед всей фирме, а не решать частные вопросы отдельных индивидов. Думаю если бы бухгалтер делала систему оптимизации налогов при которой каждый сотрудник фирмы стал платить скажем на 3% меньше отчислений — то думаю все и каждый бы согласился какое то время позаполнять журналы учета самостоятельно. Не так ли?

1) Коммуникация должна вестись через определенные каналы — а не просто подходить просить — дежурный это публичный интерфейс коммуникации с командой. Я не обзывал человека медведем — это аллегория с помощью которой можно быстрее донести свою мысль
2) Задачи редко кто делает из-за лени, да и зачастую задачи когда создаются то они требуют уточнения, потому как люди часто не понимают конкретной причины
3) Скажите у Вас все девелоперы смотрят на графану? Могу поспорить что многие и в аккаунты свои ни разу не заходили

Дима, спасибо за статью!

Мне эта проблема знакома причем знакома с разных сторон: как DevOps, Dev, QA да еще и как Product Owner — Добавляйтесь на фейсбук — в личке обсудим данную проблему

Я бы тут сказал не дополнительным индикатором. В моей практике было такое что юниты хорошо отрабатывали а сама фича лежала. Е2Е это оценка того как вы делаете фичу в целом.

Про уровень порога зелености — он у меня только один, хотя бы один тест завален — завелен весь тестовый прогон. Прогонять имеет смысл всегда, прогон показывает насколько затронули изменения функционал. Однако ждать многие не любят. бывает просто команду не устраивает что каждый разраб будет ожидать(хотя тут можно работать и паралельно) результатов прогона тестов перед тем как смерджить свои изменения в масте/дев/стейдж. Но мое мнение надо прогонять всегда в фичабранче при создании пулл реквеста — дальше все идет на обсуждение команды.

en.wikipedia.org/...​wiki/Source_lines_of_code — (facepalm)(facepalm)

Давайте вместе постараемся это исправить.

В следующей статье покажу что это не так. Тернарник является оператором а не логической веткой. Во всяком случае если говорить про языки PHP/JS/Python/C#/C++/Java

Надо разбираться что не так. Надо принять во внимание что и тесты это тоже ПО — в них тоже бывают баги и опять же их тоже надо чинить. Тут именно надо разбираться что именно не работает — тест или обьект тестирования, поэтому и тесты должны писаться разрабами, что бы не было пин-понга кому что чинить

1) Подводные камни следующие — первое это как всегда лень и время. Ждать не любит никто. Во вторых это хрупкие тесты, опять же мало кто любит разбираться почему тесты упали, когда легче всего обвинить QA инженера, парней ответственных за окружение и т.д. Мое мнение что E2E тесты должны писать разрабы — тогда эти все вопросы и претензии автоматом уйдут.
2) Чинить тесты опять же должны разрабы — тут должен действовать закон — чинит тот кто поломал, в красную бранч мердж должен быть закрыт
3) Мое мнение что надо прогонять все тестовые наборы — потому как мерджи отнюдь не способствуют уменьшению багов :)

Вы продайте мне как вы не техническому заказчику. Если, конечно, с конечным заказчиком не общались и не рекомендуете бизнес с ограничеными бюджетами начинать, да еще и не техническим людям тоже начинать бизнес не рекомендуете, то больше вопросов не имею. И опять же что мешает вообще не копить тех долг даже без тестов. И еще одно, никогда не сталкивались с примерами, что при 100% покрытии тестами технический долг может быть больше тех долга фейсбука? Не?

Так что продайте мне тесты не входя в технические подробности. Допустим я заказчик. Хочу вложить в разработку, бюджет на полгода команды из 1 сеньйора и двух мидло/джунов, а теперь продайт мне тесты? В чем для меня выгода?

Тогда давайте уж называть прототипами, большую половину выходящих на рынок продуктов. Если так то ок.

Только вот, хочется вступить в дискуссию с адептами TDD. Вы утверждаете, что вы будете разрабатывать с той же скоростью с тестами, что и без тестов? Или все-таки поменьше? Потом, тесты также как и любой здоровый код требует времени на поддержку. Никто спорить не будет? Кто за это платить будет? Или же вы будете в оставаться в не оплачиваемый овертайм и педалить?

Я так понял вы о программировании не по наслышке знаете, так вот что тестировать будете? Какие тесты будете делать? Продайте мне тесты если у меня ограниченный бюджет и встает дилемма или тесты написать или +1 фича.

Тогда вы плохо — доносили. Разговаривайте про стоимость. Не пытайтесь оперировать техническими терминами — и вас обязательно поймут. Проверено годами опыта. Деньги помогут достучаться до мозгов любого

Оговаривай с заказчиком моменты. Всегда надо ставить его в известность что ты делаешь. Не порефакторишь — в геометрической прогрессии возрастет количество багов, возрастет количество багов меньше времени останется на новые фичи, следовательно за каждую новую фичу будешь платить в итоге дороже — это все джолжно быть донесено до клиента. Такие мессаджи понимают все

Ни кто не говорит про фейсбук за $100 — но и разработка замедленными темпами тоже не предполагается. Да — если есть время, работаем по Red-Green-Refactor логику тестируем полностью, делаем ревью от архитектурных до код ревью каждой строчки, поверьте, я знаю как делать все правильно — однако, если клиент прибегает говорит — чуваки, не сделаем функциональность инвестор уйдет, показать надо — делаем, абы ж работало. Никто не призывает нерабочую функциональность поставлять клиенту, однако, если на вылизывание нет времени — включается превосходство работающей функциональности над всем остальным

И опять я возвращаюсь к основной теме в статье — если заказчику надо все и сразу? Никогда не сталкивались с моментом — если в итерации Х не будет такой фичи то итерации Х + 1 просто не будет? В стартапах такие аргументы везде и всюду. Есть моменты когда можно и нужно говорить нет, а есть моменты когда говорить нет нельзя. Тогда приходится писать быстро.