Как извиниться, если вы нарушили ночную сборку [закрыто]

181

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

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

раджан
источник
99
Если сборка никогда не ломалась, я начинал подозревать, что процесс сборки нарушен;)
Lazarus
6
Как вы узнали, что сборка была сломана?
65
Как насчет: «Мне очень жаль, что я сломал ночной строй. Если вы хотите удержать мою зарплату в качестве наказания, я не возьму компанию в суд по трудоустройству». Нет, просто шучу - не извиняйся, такого рода вещи случаются постоянно. Люди, которые «повсюду над вами», являются психами, которые не знают, как правильно восстановить систему до прежнего состояния.
Jas
14
Я сломал сборку в первые 10 коммитов! Не беспокойтесь об этом
Никто
135
Я просто хотел бы, чтобы у меня была ночная сборка, чтобы сломаться ..
Макс

Ответы:

306

Не извиняйся!

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

Кроме того, держу пари, что ваша команда не прошла «тест Джоэла» и не может сделать сборку за один шаг.

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

Джим Г.
источник
31
+1 Договорились! Не извиняйся. УЧИ, что ты сделал не так. Не делай этого снова, по крайней мере, не скоро. Будьте вежливы, когда люди «повсюду». Учитесь на том, что они говорят (даже если это просто кто укол, а кто в порядке).
Питер К.
12
Ну, вы все еще можете извиниться ... Но я немного удивлен, что люди повсюду вокруг вас. Если вы новичок в команде, это не должно быть таким сюрпризом, что вы допустили ошибку. По крайней мере, это показывает, что вы что-то сделали :)
Филипп
40
+1. Цель ночной сборки - поймать проблемы как можно раньше и до того, как они выйдут в релиз. 95% разработчиков сделали ошибки видимости во время их карьеры. Остальные 5% лгут.
Blrfl
26
Хотя я согласен с тем, что это не требует извинений за уровень «падение на мече», я думаю, что это требует извинений за уровень «упс, мой плохой». Не каждое «прости» должно быть презренным.
Мэтью Скотен
5
Я совершенно не согласен с этой предпосылкой, нет ничего плохого в простом извинении «извините», я понимаю, что облажался и сделаю все возможное, чтобы извлечь уроки из своей ошибки . Я согласен, что лучший способ «исправить» себя - это не делать это снова, но вы, если вам не все равно, вы, возможно, не захотите открыто показывать это, чтобы другие знали, не каждый раз, когда вы облажались, но он явно чувствовал себя плохо в этом и нет ничего плохого в извинениях.
Труфа
182

Сушки. Donuts. И т. Д. В одной компании, в которой я работал в прошлом, проверка неработающего кода или иным образом вызывающая сбои коллеги обычно разрешается путем принесения продуктов извинения на следующий день.

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

Я люблю извинения коллег. Вкусные, вкусные извинения.

Дэн Рэй
источник
83
+1 за «Я люблю извинения коллег. Вкусные, вкусные извинения».
Jas
32
Нарушение ночной сборки dev - это одно, а срыв производственной базы данных - на совершенно другом уровне. Если бы я когда-либо делал это, я хотел бы, чтобы жареные гамбургеры были худшим моим наказанием.
maple_shaft
20
Вы можете почти испытать чувство вины.
Майк Спид
40
«Сдува производственной базы данных» помещает в мою голову всевозможные веселые образы относительно того, что именно произошло с базой данных. Большинство из них включают всех, кто слышит громкий взрыв из серверной комнаты. «О боже, база данных достигает критического объема!» "Быстро! Опустите тяги!" «Уже слишком поздно, данные, она обречена!» БУМ
Карсон Майерс
7
drop database... О сила этих двух маленьких слов. Это было много лет назад, но я хорошо это помню;)
Ли
80

Две цитаты для вас:

Человек, который не делает ошибок, обычно не делает ничего .-- Уильям Коннор Мэги

Тот, кто не делает ошибок, не старается изо всех сил .-- Wess Roberts

Я согласен с Джимом Г. , не извиняйся, но учись у него и не повторяй ту же ошибку снова ... СУХОЙ;)

Lazarus
источник
9
Или есть более общая цитата: «Пусть тот, кто без греха, бросит первый камень». Если кто-то, стонущий о сломанном строении, сломал здание раньше, они не должны стонать
Ричард
как второй !!
Суфенди
1
Цитируя себя каждому выпускнику, которого я когда-либо наставлял "I expect you to make lots of mistakes. Own up to them, accept them, and learn from them. If you never make mistakes, you'll never really learn anything".
С.Робинс
Хорошее использование принципа "СУХОЙ" ... :)
Дж. Аллан
53

Не извиняйся, просто исправь это как можно скорее. Это нормально, хотя все ломают сборку хотя бы один раз, в моей последней компании это было что-то вроде инициационного ритуала. Когда один из членов команды сломал сборку, мы ставили резинового даки на его стол утром утром, прежде чем он вошел, это дало ему знать, что он сломал сборку, и он исправит ее.

Мы назвали это Duckie Continuous Integration, и когда у вас было это в течение дня, люди будут дразнить вас, но все это было весело, ни один из них не должен был быть подлым.

Мы взяли что-то вроде сломанной сборки и превратили ее в упражнение по построению команды.

maple_shaft
источник
2
+1: не только то, что им важно - все, что им нужно . Вы не сделали ничего плохого, как таковой - просто сузили границы возможного слишком далеко;). Вы, вероятно, также человек, который может исправить это. Каждый делает это время от времени. Каждый загружает что-то, чтобы жить не должно было. Каждый раз в своей жизни предложение WHERE исключается из оператора UPDATE. Важно то, как вы реагируете. Там, где мы находимся, все разработчики, как правило, закрываются, отказываясь говорить о том, кто лично был виноват, если кто-то спросит, это просто исправлено.
Том Морган
Это кажется действительно отличный способ справиться ошибок.
Труфа
3
Непрерывная интеграция Даки , Хахахаха
AttackingHobo
43

"Извини, моя ошибка!" Я обычно извиняюсь, когда нарушаю сборку. Такое случается. Но, как говорили другие, это возможность улучшить ваши системы, чтобы один человек не мог так легко сломать сборку для всех остальных.

Я бы не стал делать извинения в этих обстоятельствах, но если вы действительно считаете, что более формальное извинение уместно, тогда ваши извинения должны сделать следующее:

  • Выразить сожаление.
  • Обозначить проблему.
  • Брать ответственность.
  • Делать поправки.
  • Сохранить лицо.

То есть: «Мне жаль [ЯВНО ВЫРАЖЕНО], что я доставил вам неудобства [ПРИНЯТЬ ОТВЕТСТВЕННОСТЬ] случайно [СОХРАНИТЬ ЛИЦО], нарушив сборку [СОСТОЯНИЕ ПРОБЛЕМЫ]. Пончики на мне завтра. [СДЕЛАТЬ ПОМОЩЬ]»

Каждая часть необходима в правильном извинении; если вы не заявите о проблеме, тогда это неясно. Если вы не выражаете сожаления, берете на себя ответственность и вносите поправки, тогда люди чувствуют себя неискренними. Сохраняющая лицо часть - самая игнорируемая часть извинения; спасительная черта лица - это то, что напоминает потерпевшей стороне, что вы ценный сотрудник, который иногда делает ошибки, а не идиот (или диверсант!)

Наконец, несколько мыслей о нарушении сборки:

Я работаю в команде компилятора C # / Visual Basic. Конечно, сегодня Visual Studio - это настолько масштабный проект, что у него есть собственная команда, которая занимается только управлением инфраструктурой сборки, и огромная комната с собственной выделенной системой кондиционирования воздуха. Еще в середине 1990-х годов, когда я начинал в качестве стажера, команда по сборке Visual Basic была одним стажером - мной - и шкафом, полным машин. Времена изменились!

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

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

Эрик Липперт
источник
15

Не извиняйся Именно ваши коллеги виноваты в том, что не просмотрели ваш первый коммит и не имеют системы быстрой обратной связи для сборок, подобных серверу непрерывной интеграции.

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

В любом случае, официальное письмо с извинениями, вероятно, слишком много.

guillaume31
источник
Отличная точка зрения - экспертная оценка должна была это уловить. Потому что вы делаете рецензирование изменений до того, как они будут применены к master / HEAD / default, верно?
Фрэнк Шиарар
11

Фундаментальное правило - когда вы ошибаетесь, ОБРАЩАЙТЕСЬ: Вы не должны впадать в извинения. Все совершают ошибки. Профи это признают. Это командная работа. Другие члены команды должны собраться вместе, чтобы помочь вам в этом. Если нет, обратитесь за помощью. Самое большее, что нужно сказать потом, - что мы можем из этого извлечь?

Говорят, что успешный брак основан на трех маленьких словах: «Я был неправ».

Если кто-то не делает случайную ошибку, он не работает, но ошибка, на которой он не учится - две ошибки.

Майк Данлавей
источник
Я думаю, что это отличный ответ и намного лучше, чем тот, «Не извиняйся», который имеет самые высокие голоса. Вы можете извиниться перед всеми за нарушение сборки, но они также должны показать вам немного изящества. Они также должны сказать: «Не волнуйся, мы все сломали это раньше, в конце концов, для этого оно и есть». До тех пор, пока вы пытаетесь не сломать это снова, они должны быть крутыми с этим. Если вы игнорируете всех и идете и делаете одну и ту же ошибку, то это уже другая история.
Rocklan
6

Самое лучшее извинение - это быстрое исправление разрыва

JaredPar
источник
5

Если у вашей компании уже есть способ протестировать изменения в вашей сборке, то (A) ваши изменения либо не удалось (но вы все равно их проверили), либо (B) они прошли успешно (и вам нужно создать новый тестовый пример).

Если ваши коллеги осторожно тестируют свои изменения и ожидают найти разрывы в ночной сборке, то (C) у вас хрупкий процесс (и вам нужно ввести тестирование, подобное тому, которое можно найти в Extreme Programming).

Вполне возможно, что (D) Ваши изменения привели к непредвиденным изменениям в коде Билла, которые были либо ранее, либо изменены в той же сборке, что и ваша.

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

  • (A) Я не прошел тест сборки, но проверил мои изменения. Извините, я изменяю свой процесс, поэтому я не буду делать это снова.
  • (B) Я прошел тест сборки и добавил тест JUnit XYZtest.java, чтобы уменьшить вероятность повторного появления.
  • (C) Поскольку у нас нет процесса тестирования сборки, я создаю его для своих изменений. Я хотел бы поделиться с вами, как мы можем улучшить наш процесс сборки.
  • (D) Я буду работать с Биллом над написанием теста JUnit XYZtest.java, чтобы уменьшить вероятность повторного появления.

Я уверен, что есть (E), о котором я не думал.

Обратите внимание, что я говорю «чтобы уменьшить вероятность повторного появления», а не «чтобы это больше не повторилось». Это случится снова. Но вы можете улучшить свой процесс, чтобы уменьшить эту возможность. Это, я думаю, является одним из признаков успешного программиста.

rajah9
источник
2

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

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

Corv1nus
источник
2

Как подойти к этому, зависит от атмосферы в вашей группе. Если это культура вины, я бы очень внимательно отнесся к извинениям и как ты это делаешь. Если это совместная позитивная атмосфера, то да, что-то вроде: «Я все испортил, извините. Как мы можем избежать этого в будущем?» это, наверное, хорошая идея.

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

Я не знаком с вашей структурой (я работаю в совершенно другой среде), но в конечном итоге реальность такова, что иногда люди делают ошибки, и что-то нарушается. Вы учитесь на опыте и идете дальше.

temptar
источник
2

В моем окружении, если вы сломаете сборку, вы получите добродушного ребра и несколько остроумных комет. Я не уверен, в какой стране вы говорите по-английски, но, возможно, вы не являетесь носителем английского языка, подчеркивая природу комментариев.

Будучи с другой стороны старшим разработчиком, я однажды прокомментировал обзор кода, что какой-то способ выполнения x «отстой» не потому, что код был плохим, а в структуре проекта. Для меня было больше комментариев, что мне нужно исправить структурную проблему. Только позже я обнаружил, что младший Дэв, хотя я был очень зол на него из-за моей неточной легкомысленной речи.

повторный показ
источник
2

Um. Вы получаете сломанный токен сборки . Передайте бешенство следующему счастливчику. Бывает все время. Качество важно, но ошибки неизбежны. Исправь их. Двигаться дальше. Позор следующему бедному парню.

М. Тиббитс
источник
1
Я видел это много. Другой - вы можете «присматривать» за ночной сборкой, пока кто-то другой не сломает ее. Это не значит исправить это, но выяснить, почему и кто должен это исправить.
Стивен Дарлингтон
1

Как правило, я бы сказал:

Если ваша проверка вызывает ошибку компилятора, вы бы поймали себя, если бы перед проверкой вы сделали «получить последнюю версию», просто «упс, мой плохой». (особенно если вы заходите в 10 утра следующего дня, пока все решают, к какому набору изменений откатиться)

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

Морган Херлокер
источник
1

КОМАНДА не удалась.

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

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

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

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

JeffO
источник
0

Я не понимаю, почему люди повсюду. Если система настроена правильно, они должны быть в состоянии выявить ваши изменения / исправить их очень быстро.

Но опять же, если вы один из тех парней, которые сломали сборку окон, тогда ... Я не могу помочь. (Это невероятно трудно сделать, между прочим, прежде чем кто-либо задает вопросы о том, как MS строит философию, но время от времени кто-то делает это - и весь контроль качества компании останавливается на день)

И да - не извиняйся. Просто поговорите с вашим менеджером и дайте ему понять, что вы узнали из того, что вы сделали.

Субу Шанкара Субраманян
источник
0

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

Если нарушение сборки является настолько серьезной проблемой, это означает, что ваш процесс нарушен.

Вы должны делать непрерывные сборки, а не ночные.

Христоффер Хаммарстрём
источник
+1 за то, что «если ломать сборку - это большая сделка, значит, ваш процесс нарушен». С другой стороны, вам все равно придется иметь дело с нарушенным процессом, а это значит делать все возможное, чтобы избежать нарушения ночной сборки до тех пор, пока процесс не улучшится.
Калеб
0

Лучше поздний ответ, чем никогда ...

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

Лично я вижу сломанную сборку как возможность.

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

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

S.Robins
источник
-1

Скажите им, что им нужна сборка CI при регистрации. Таким образом, вам не придется ждать до вечера, чтобы узнать, что он сломан. YEA !!! Скажите им, что это неправильный процесс, больше ничего. Вы только что определили пробел в их системе.

Но да, не забудьте исправить это. Не ахти какое дело. Это не в производстве. Просто бесполезная ночь.

Исса Фрам
источник
-2

Обычная практика в моей компании:

  • Кричать "это был не я!" (обычно CVS / SVN доказательства в противном случае)
  • Носить футболку с надписью "my-userlogin ist Schuld!" (да, у 50% наших разработчиков такая рубашка)
  • Утверждая, что он работает в локальном sendbox и все тесты пройдены просто отлично

У моей компании также есть хороший способ справиться с таким «инцидентом»:

Роберт Гейне
источник
-2
  • Я бы не стал извиняться.

  • Я бы обвинял CI-лидера в том, что он позволил мне совершить неправильную сборку.

  • Должен существовать процесс CI, чтобы мешать разработчикам фиксировать испорченный код.

  • Если локальная сборка завершается неудачно, то не следует разрешать вход на сервер сборки

CodeART
источник
1) Не все проекты настроены на непрерывную интеграцию. Это приятно иметь и может помочь в таких ситуациях, как ОП, но это далеко не так. 2) Никогда не бывает больно извиняться, даже если это не имеет большого значения, даже когда есть инструменты, которые могли бы предотвратить проблему. 3) Обвинять кого-то в проблеме, которую вы вызвали, действительно ли это ваша вина, - паршивая идея.
Калеб
Здесь есть две проблемы: 1 - неработающий код на локальной машине. 2 - неработающий код на сервере сборки. Первая проблема очень мала, так как все разработчики делают ошибки. Изменения могут быть отменены, и это не повлияет на систему или отдел. Вторая проблема, вероятно, окажет гораздо большее негативное влияние на систему и отдел.
CodeART
-2

Хотя я думаю, что могут быть какие-то извинения, пожалуйста, не говорите: «Я сделаю так, чтобы это больше не повторилось». Потому что так и будет. И если это произойдет, это укусит вас.

Питер Б
источник
-2

Если вы работаете над проектом с открытым исходным кодом,

просто скажите "Извините, я сломал сборку. Может быть, я был слишком сонный!"

и добавьте его в качестве комментария github.

Это потому, что многие разработчики с открытым исходным кодом пишут код в полночь.

linquize
источник