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

Ответ 1

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

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

Ответ 2

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

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

Непрерывная интеграция - автоматизация ваших построек

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

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

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

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

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

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

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

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

Ответ 11

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

Что касается точки Branch/Trunk: каждый должен всегда работать с туловищем, ветвью для пиков и POC, тег. релизы

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