Политика для фиксации, поврежденной ночью, создает [закрытый]

В вашем случае я бы порекомендовал того, кто отвечает за CM. Если у менеджера или технического руководителя слишком много обязанностей, почему бы не передать их младшему разработчику? Я бы хотел, чтобы кто-то заставил меня в начале моей карьеры более тщательно изучить систему управления версиями. Не только это, но и изучение кода других людей для выявления источника ошибки - это реальное упражнение для развития навыков или изучения знаний. Говорят, вы извлекаете максимальную пользу из кода других людей, и я твердо верю в это.

Обычно я делаю (я делал это для команды от 8 до 10 человек) - это два человека, у которых один парень проверяет сборку, в первую очередь он делает это утром - некоторые сказали бы, что он отвечает за QA, я полагаю.

Если есть проблема, он отвечает за выяснение, что / как - конечно, он может попросить помощи у других членов команда, если необходимо.

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

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

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

Почему бы не позволить всем в команде проверять сборку каждое утро?

• Ну, во-первых, не каждый хочет - и это будет лучше, если тому, кто это делает, нравится то, что он делает
• И вы не хотите, чтобы 10 человек тратили на это полчаса каждый день ^^

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

setName()
setType()
setOption()

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

Иногда эстетика одного шаблона подходит лучше, чем эстетика. другого.

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

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

Это имеет смысл, так как

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

Пара, переживаемая с неизвестной

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

Дайте команде выбор вашего назначенного решения или одного из их собственного состава

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

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

Либо:

• Никто не регистрируется после 17:00

, либо

• Никто не регистрируется после 17:00, если только не готов остаться на работе до тех пор, пока сборка не пройдёт как зелёная - даже если это означает работу над ошибкой, фиксацию и ожидание сборки.

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

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

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

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

У нас нет формального механизма для присвоения задачи: мы небольшая команда (обычно шесть человек, как правило), и иметь собственность коллективного кода, поэтому мы просто работаем между собой. Если мы думаем, что одна конкретная паре Checkin нарушила сборку, это обычно было бы их, кто его исправит. Если нет, это может быть кем-то; Обычно решается, увидев, кто в настоящее время не в середине какой-либо другой задачи.