KT
и если ты думаешь что это редкие кейсы, то у тебя ашипка выжившего
Size: a a a
2020 July 17
i
и им надо понимать разницу
Им надо знать, что конкретно изменится если выполнить вот это. Как раз план умеет анализировать и результат рисовать даже гитлаб при MR, и менеджер перед принятием его смотрит. Есть вопросы - смотрит в changes в MR
KT
Им надо знать, что конкретно изменится если выполнить вот это. Как раз план умеет анализировать и результат рисовать даже гитлаб при MR, и менеджер перед принятием его смотрит. Есть вопросы - смотрит в changes в MR
Им надо знать это изменение является результатом работы или результатом возврата к compliance
i
тебе нужно понимать если он че-то наделал руками или че он там налабал в шаблоне
Ну, первое правило - нет в коде, нет в проде, второе - то что я выше описал. Я все равно буду просматривать MR со всему ресурсами
KT
говорить манагеру "тебе надо - иди в код" тупиковый шаг
KT
Ну, первое правило - нет в коде, нет в проде, второе - то что я выше описал. Я все равно буду просматривать MR со всему ресурсами
первое правило бьется об реальность чаще чем ты думаешь
i
говорить манагеру "тебе надо - иди в код" тупиковый шаг
Ну погоди, мы или про технических специалистов или нет. Если он не технический - он и дрифты смотреть не будет, а если будет - то не поймет
KT
релиз менеджер больше менеджер
KT
и ты за дискурсом про "тф план покажет все" упускаешь деталь, что целофан - инструмент который подойдет как тем кто катит кубы в ексе, так и махровым ITIL конторам
KT
а для хипстеров, которые не хотят лезть в низкоуровневое завезли CDK и SAM
i
Причем по-хорошему все такие изменения, что из кода, что нет должны помечаться, откуда они. Как автоматика навесить тег, так руками навестить тег, так и через tf. В итоге я по смене тегов пойму откуда это. Даже если руками я забыл повесить - сам факт того, что тег "source = terraform" появляется свидетельствует о том, что это было создано не через него
i
релиз менеджер больше менеджер
Релиз менеджер может быть когда как. У нас есть как и люди, которые и девопсы и релиз менеджеры одновременно - так и те, кто на твой дрифт будет смотреть как баран на новые ворота, он вообще о ресурсах aws знает только то, что они есть
ФТ
Ну, первое правило - нет в коде, нет в проде, второе - то что я выше описал. Я все равно буду просматривать MR со всему ресурсами
это если ты фуллтайм на проекте работаешь
а если ты поработал на проекте, а потом в сл раз вернулся на него через 1 год?
и помимо тебя у клиента есть еще и свои ребятки
а если ты поработал на проекте, а потом в сл раз вернулся на него через 1 год?
и помимо тебя у клиента есть еще и свои ребятки
i
это если ты фуллтайм на проекте работаешь
а если ты поработал на проекте, а потом в сл раз вернулся на него через 1 год?
и помимо тебя у клиента есть еще и свои ребятки
а если ты поработал на проекте, а потом в сл раз вернулся на него через 1 год?
и помимо тебя у клиента есть еще и свои ребятки
Ну так это у меня я тебе больше скажу, не редкость
ФТ
на которых ты влиять никак не можешь, и все твои практики для них носят рекомендательный характер
KT
Релиз менеджер может быть когда как. У нас есть как и люди, которые и девопсы и релиз менеджеры одновременно - так и те, кто на твой дрифт будет смотреть как баран на новые ворота, он вообще о ресурсах aws знает только то, что они есть
еще раз, у тебя манагер который хочет сравнить два пункта 1) измнение приходящее как часть производства 2) несанкционированное изменение. Плевать, баран он или кто, зачем смешивать ему данные в одном выхлопе?
KT
опять меня засосали на иакный холивар,
KT
i
еще раз, у тебя манагер который хочет сравнить два пункта 1) измнение приходящее как часть производства 2) несанкционированное изменение. Плевать, баран он или кто, зачем смешивать ему данные в одном выхлопе?
Хорошо, допустим мы смотрим дрифт. Как мы определим санкционированность изменения и источник?