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

Question

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

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

Answer 1

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

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

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

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

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

Получив CI, вы можете получить более высокое качество, если добавите немного юмора (и позора), введя сломанный токен сборки! http://ferventcoder.com/archive/2008/08/20/continuous-integration-enhancement--the-broken-build-token.aspx

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

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

Филиалы против магистрали для активной разработки

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

Answer 10

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

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

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