Детская непосредственность

[vitus_wagner]

Тестер пишет:

- Скажите, а куда делась история в jenkins

Отвечаю:

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

Он:

- Там была история не только сборок, но и тестирования. Очень жаль, что у
нас взаимодействие построено так, что люди, занимающиеся тестированием,
просто оказываются перед фактом.

Так кто кого, спрашивается перед фактом ставит? По-моему он меня, что эта история представляла для кого-то какую-то ценность.

Comments

[filin]

Ответь ему, что обнаружение таких фактов и является его работой. Может попросить бонус у своего начальника.

[vitus_wagner]

Не, обнаружение таких фактов его работой не является. Равно как моей работой не является организация резервного копирования сборочных серверов.

[filin]

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

[filin]

И нет, он тебе излагает не факт, а мнение. Факт в историческом аспекте — это событие, своевременно зафиксированное в документе. Нет летописного свидетельства (или культурного слоя) — нет факта.

[vitus_wagner]

Факт сдыхания сервера и переноса хостнейма jenkins в локальной сети на другой в соответствующей служебной записке зафиксирован. Так что это факт.

[filin]

Сдыхание — да. А вот то, что история представляла ценность — нет.

[livelight]

Дык, "культурный слой" -- это и есть история. Она как раз и пропала :)

[filin]

Раз пропала — значит, нет факта :)

[sergey_cheban]

А если бы это был не jenkins, а git? Или, лучше, cvs: в гите-то история обычно легко восстанавливается.

[vitus_wagner]

К счастью, git те, в чьи обязанности у нас в конторе входит организация бэкапов, все-таки бэкапят.

[straktor]

Девопсы, то есть админы, которые убивают проектную инфу -- гондоны с точки зрения и разрабов, и менеджеров. Вам копировать историю ничего не стоит, но баре не желают озаботиться. И доступ другим вы не даете.
Даже тупо номера билдов не могут восстановить, опять с 1 по третьему кругу. Охуели вконец.

[vitus_wagner]

Вот забанить за оскорбление что-ли? Ты кого девопсом обозвал?

У нас не вебсайт какой, а честный, к тому же многоплатформный, программный продукт.

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

[livelight]

Вообще, по определению, девопс - это тот, кто создаёт, настраивает и поддержиавет всю эту инфраструктуру для билдов.
Программист - это тот, кто код пишет, который будет потом там билдиться.
А так-то один человек может и ту, и другую, и ещё 10 ролей выполнять.

[straktor]

Разрабам в вашем конкретно проекте не нужно, а другим ролям и другим проектам часто бывает нужно.

Даже менеджеры могут например для обоснуя инвесторам спросить:
- мы тут 100500 нефти за все ваши дженкинсы заплатили, а сколько вообще было билдов и сколько из них было зафэйленных? как бля нету? я уже обещал дать инфу! так вы чо, бабло спионерили штоли и мне тут фуфло гоните? показывайте ваш дженкинс! что за хня, 10 билдов со вчерашнего дня? вчера бля поставили? всех на мороз @#%@#$%^*#^^**$!!! без зарплаты!


сами артифакты складировать, ок, надо в репо
логи билд процесса -- тоже нафиг
но тупо -- дату-номер-гитинфо-статус-отчёт-шаги-время шага -- крайне полезно и дёшево

проблема тут технологическая, дженкинс из коробки бэкапы не даёт -- тупо не в курсе какие файлы надо
дженкинсы к тому же деплоят в говнооблаках, где виртуалка выключается и все диски дропаются, с3 никто не маунитит
а в тимсити например всё культурно в БД и там бэкап-рестор всеми дб тулами в любой момент

[ex0_planet]

Там явно "в который раз" пропущено. Когда люди такое высказывают, значит у них уже накипело.

[vitus_wagner]

Ну по-моему если тестеры не встают по стойке смирно по команде релиз-менеджера, то мало им еще.

[ex0_planet]

Тестеры или QA-инженеры? В любом случае, я бы попытался разобраться чо им нехватат, что им понадобилась эта история.

[vitus_wagner]

По-моему им всего хватает, а кое-чего даже избыток.
Увы, они пытаются решать более амбициозные задачи чем стоило бы при текущем состоянии проекта и материальной базы фирмы.

[ex0_planet]

По идее им бы должен был это объяснить не раз и не два ваш техдир.

А в той базе у них скорее всего какой-то "кэш" их внутреннего состояния, который по первичным данным восстанавливать долго или неудобно. И если товарищи тестеры намекают что из за этого будет какая-то значимая потеря эффективности, то это таки повод для разборок.

[vitus_wagner]

Ага. А поддержанием работоспособности и резервным копированием серверов по идее должен заниматься сисадмин.

[filin]

Это повод для постановки такой задачи, причем до того, как пришлось что-то восстанавливать с бэкапа, а не после.

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

[livelight]

Я вижу здесь претензию к процессам и менеджменту: "у нас взаимодействие построено так, что ...."
И раз дженкинсовым пастухам никто не сообщил, что история эта для представляет ценность для тестировщиков или кого-то ещё - то это косяк именно там.

[vladimir000]

Да, поддерживаю.

[ramendik]

+1. Читать буквально, заявлена проблема во взаимодействии - вот её и искать, и кто уж там за это взаимодействие отвечает. Project manager? Program manager?