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

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

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

Непрерывная Интеграция-Автоматизация Сборки

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

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

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

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

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

ветви против ствола для активного развития

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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