Любая проверка контрагента на "вменяемость" начинается с чтения его бумажек и если их нет, то хер вам, а не контракт. И вопросы про разработку, методики, и т.д. сейчас в каждом опроснике.
Тут товарищ спрашивал про документацию процессов в DevOps. Я рассуждаю так. Процес сборки кода задокументрован в gitlab.yml идёшь и смотришь. Процесс выкатки софта на сервера задокументрован в плейбуках идёшь и читаешь. Подобным образом со всем остальным. В идеале никакой доп. документация нет.
Тут товарищ спрашивал про документацию процессов в DevOps. Я рассуждаю так. Процес сборки кода задокументрован в gitlab.yml идёшь и смотришь. Процесс выкатки софта на сервера задокументрован в плейбуках идёшь и читаешь. Подобным образом со всем остальным. В идеале никакой доп. документация нет.
Не все аудиторы такие продвинутые, это раз. Два, есть много организационных моментов, которые в коде не отражаются
Я могу множество примеров привести. Например есть страничка в вики, где списком написаны какие команды нужно выполнить чтобы получить какой-то результат. Вот по мне эти команды надо в скрипте написать и запускалку удобную сделать, а не в вики.
Я не совсем понимаю при чём тут аудитор. Может я вопрос не правильно понял?
Ты спросил, зачем вести документацию, если можно просто показывать репы с кодом. Я тебе привел одну из причин - докуменатция может понадобиться аудитору или при M&A или для business review
Тут товарищ спрашивал про документацию процессов в DevOps. Я рассуждаю так. Процес сборки кода задокументрован в gitlab.yml идёшь и смотришь. Процесс выкатки софта на сервера задокументрован в плейбуках идёшь и читаешь. Подобным образом со всем остальным. В идеале никакой доп. документация нет.
Я могу множество примеров привести. Например есть страничка в вики, где списком написаны какие команды нужно выполнить чтобы получить какой-то результат. Вот по мне эти команды надо в скрипте написать и запускалку удобную сделать, а не в вики.