Ежедневная сборка противНулевой Дефект

Question

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

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

Answer 1

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

Итак, как моя компания ведет ежедневную сборку и стремится к отсутствию дефектов? Мы запускаем наш набор тестов, прежде чем мы проверяем наш код. Единственная проблема для нас состоит в том, что полный цикл нашего набора тестов занимает более 72 часов, поэтому перед проверкой кода мы запускаем ограниченный набор модульных тестов. Для наших ночных сборок мы запускаем набор тестов, который занимает около 8 часов. Затем по выходным мы запускаем полный набор тестов. С каждым этапом возникает все больше и больше проблем, но более 90% попадают на 5-минутные тесты для разработчиков и, вероятно, более 98% на ночные тесты. Это все еще предупреждает нас о проблемах еще до того, как они обращаются к нашим клиентам и стоят больших затрат на их устранение.

Answer 2

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

Мы всегда интегрируемся локально, запускаем наши тесты для кода, и когда все проходит, мы регистрируемся. Я проверяю примерно 20-30 раз в день, когда работаю. Сервер сборки принимает изменения и запускает сборки для системы. Непрерывная интеграция (CI) - это хорошо. : D

Непрерывная интеграция - автоматизируйте сборку

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

Я также согласен с ответом Чедмайера: что бы вы ни решили, оно должно быть автоматическим и автоматизированным. Лучшая вещь в автоматизации инструментов, чтобы делать такие вещи для вас, это то, что вам больше не нужно думать об этом или не забывать делать это. Или, как сказал Чад, ты не прекратишь это делать. Я мог бы рекомендовать дать рекомендацию для инструментов CI, но посмотрите здесь: Какие инструменты вы используете для автоматизированных сборок / автоматизированных развертываний? Почему?

Если у вас есть CI, вы можете получить более высокое качество, если сможете добавить немного юмора (и позора), введя сломанный токен сборки! http: // ferventcoder .com / Архив / 2008/08/20 / непрерывная интеграция, повышение - заместитель разбитым встроенного token.aspx

Используйте хороший инструмент для автоматизированных сборок

Большинство людей в .NET land используют сценарии NAnt или MSBuild для автоматизированных сборок, которые впоследствии они могут подключить к своему CI-серверу. Если вы только начинаете, я бы предложил использовать UppercuT , это безумно простой в использовании каркас сборки, который использует NAnt. Вот вторая ссылка с более подробными объяснениями: UppercuT .

Ветви и магистраль для активной разработки

Вам не придется переходить, если вы не оставляете транк открытым только для выпусков (что означает, что все остальные работают в той же ветке, что и вы). Но у меня был бы CI как на стволе, так и на активной ветке разработки.

Процесс разработки программного обеспечения

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

Answer 3

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

Answer 4

Интеграция на ранней стадии, частая интеграция, быстрая интеграция. Вместо «ежедневной сборки», сборка производится каждый раз, когда кто-то фиксирует и делает коммит часто (по крайней мере, один раз в день, предпочтительно более 2).

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

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

Не могу сказать достаточно: быстрый цикл обратной связи об изменениях чрезвычайно важен!

Answer 5

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

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

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

Answer 6

Если вы не пойдете домой, пока все ваши недостатки не исчезнут, вы никогда не пойдете домой.

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

Answer 7

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

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

Answer 8

Просматривая ответы, я удивляюсь, что никто не упомянул Test Driven Development. Если ваша цель - отсутствие дефектов, это лучшее место для начала.

После этого я настоятельно рекомендую парное программирование.

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

Answer 9

О стратегии отсутствия дефектов: Вы можете вернуться домой, если в вашем коде есть известные ошибки. Более того, дефекты должны быть исправлены до того, как будут внедрены новые функции.

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

Answer 10

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

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

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

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

Answer 11

Я бы пошел с @feverentcoder на аргументы CI. CI твой друг, пусть он тебе поможет!

Что касается точки ветвления / магистрали - все должны всегда работать над стволом , а ветвь предназначены для шипов и POC, тег всех релизы

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