Зачем мне делать Nightly Builds?
Ночные сборки: зачем мне это делать?
Ответ 1
Вы должны делать ночные сборки, чтобы ваша кодовая база оставалась здоровой.
Побочным эффектом ночных сборок является то, что он заставляет команду создавать и поддерживать полностью автоматизированную сборку script. Это помогает убедиться, что процесс сборки документирован и повторяется.
Автоматизированные сборки хороши при поиске следующих проблем:
- Кто-то проверял что-то, что ломает материал.
- Кто-то забыл проверить файл или изменить его.
- Сценарии сборки больше не работают.
- Ваша машина сборки повреждена.
Выполнение этой ночи гарантирует, что вы поймаете такие проблемы в течение 24 часов после их возникновения. Это предпочтительнее, чтобы найти все проблемы за 24 часа до того, как вы должны доставить программное обеспечение.
Вы также должны, конечно, иметь автоматические модульные тесты, которые запускаются для каждой ночной сборки.
Ответ 2
Я лично нашел непрерывную интеграцию лучше, чем ночные сборки:
http://en.wikipedia.org/wiki/Continuous_integration
Я даже использую его в проектах одного человека, это удивительно, как быстро вы можете выявлять проблемы и заботиться о них прямо там.
Ответ 3
Я занимаюсь строительной инженерией (между прочим) в течение 16 лет. Я твердо убежден в том, что вы строите-рано, строите, часто, непрерывную интеграцию. Итак, первое, что я делаю с проектом, - установить, как он будет построен (Java: Ant или Maven;.NET: NAnt или MSBuild) и как он будет управляться (Subversion или какой-либо другой контроль версии). Затем я добавлю непрерывную интеграцию (CruiseControl или CruiseControl.NET) в зависимости от платформы, а затем пусть остальные разработчики освободятся.
По мере того, как проект растет, а потребность в отчетах и документации растет, в конечном итоге сборка займет больше времени. В этот момент я разбиваю сборки на непрерывные сборки (запускается на checkin), которые только компилируют и запускают модульные тесты и ежедневные сборки, которые строят все, запускают все отчеты и строят любую сгенерированную документацию. Я также могу добавить сборку, которая помещает репозиторий и делает любую дополнительную упаковку для доставки клиента. Я буду использовать мелкомасштабные цели сборки для управления деталями, чтобы любой разработчик мог создавать любую часть системы - сервер непрерывной интеграции использует те же самые шаги сборки, что и любой разработчик. Самое главное, мы никогда не поставляем сборку для тестирования или клиент, который не был построен с использованием сервера сборки.
Что я делаю - вот почему я это делаю (и почему вы тоже должны):
Предположим, у вас есть типичное приложение с несколькими проектами и несколькими разработчиками. Хотя разработчики могут начать с общей, последовательной среды разработки (той же ОС, одинаковых патчей, одних и тех же инструментов, одних и тех же компиляторов), со временем их среда будет расходиться. Некоторые разработчики будут религиозно применять все исправления безопасности и обновления, другие - нет. Некоторые разработчики добавят новые (возможно, лучшие) инструменты, другие - нет. Некоторым не забудьте обновить свое полное рабочее пространство до его сборки; другие будут только обновлять часть проекта, который они разрабатывают. Некоторые разработчики добавят исходный код и файлы данных в проект, но забудьте добавить их в исходный контроль. Другие будут писать модульные тесты, которые зависят от конкретных особенностей их среды. Как следствие, вы быстро увидите все популярные "Ну, это строит/работает на моей машине" оправдания.
Имея отдельный, стабильный, последовательный, хорошо известный сервер для создания вашего приложения, вы легко обнаружите эти проблемы и запустив сборку из каждой фиксации, вы сможете точно определить, когда возникла проблема в систему. Что еще более важно, поскольку вы используете отдельный сервер для создания и упаковки вашего приложения, он всегда будет упаковывать все одинаково, каждый раз. Нет ничего хуже, чем наличие у разработчика корабля пользовательской сборки для клиента, его работа, а затем не знаю, как воспроизвести настройки.
Ответ 4
Когда я увидел этот вопрос, сначала я искал ответ Joel Spolsky. Немного разочарован, поэтому я планировал добавить его здесь.
Надеюсь, что все знают о Тест Джоэл по карьере.
Из своего блога на Тест Joel: 12 шагов к улучшению кода
3. Делаете ли вы ежедневные сборки?
Когда вы используете источник управления, иногда один программист случайно проверяет что-то, что нарушает сборку. Например, они добавили новый исходный файл, и все прекрасно компилируется на их машины, но они забыли добавить исходный файл в код репозиторий. Поэтому они запирают свою машину и идут домой, забывая и счастливый. Но никто не может работать, поэтому им тоже нужно идти домой, несчастный.
Нарушение сборки настолько плохо (и так часто), что помогает ежедневно строит, чтобы гарантировать, что поломка не останется незамеченной. На больших команды, один хороший способ гарантировать, что поломки фиксируются сразу ежедневно делать ежедневный сбор, например, в обеденное время. Все делает как можно больше проверок до обеда. Когда они вернутся, сборка выполнена. Если это сработало, отлично! Все проверяют последней версии источника и продолжает работать. Если сборка не удалась, вы исправляете это, но каждый может продолжать работать с предварительной сборкой, Непрерывная версия источника.
В команде Excel у нас было правило, что кто бы ни сломал сборку, как их "наказание", отвечало за няню строит, пока кто-то иначе это сломало. Это был хороший стимул не нарушать сборку, а хороший способ повернуть всех через процесс сборки, чтобы все узнал, как это работает.
Хотя у меня нет возможности делать ежедневные сборки, я очень люблю его.
Все еще не убежден? Прочтите краткое описание здесь, в Ежедневные сборки - ваш друг!!
Ответ 5
На самом деле вы не хотите, чтобы вам хотелось, чтобы это была непрерывная интеграция и автоматическое тестирование (это шаг вперед, чем ночные сборки).
Если у вас есть какие-либо сомнения, вы должны прочитать эту статью Мартина Фаулера о непрерывной интеграции.
Подводя итог, вы хотите как можно быстрее и чаще создавать и тестировать ошибки, чтобы сразу выявлять ошибки, чтобы они могли быть исправлены, а то, что вы пытались достичь, когда вы их вызвали, все еще свежо в вашем уме.
Ответ 6
Я бы рекомендовал делать сборки каждый раз, когда вы регистрируетесь. Другими словами, я бы рекомендовал настроить систему непрерывной интеграции.
Преимущества такой системы и другие детали можно найти в статье Фаулера и в записи Wikipedia среди других мест.
В моем личном опыте это вопрос контроля качества: каждый раз код (или тесты, которые можно рассматривать как форму требований) изменяются, могут возникать ошибки. Чтобы обеспечить качество, вы должны сделать новую сборку продукта, поскольку он будет отправлен и выполнить все доступные тесты. Чем чаще это делается, тем менее вероятным ошибкам будет позволено сформировать колонию. Поэтому предпочтительны ежедневные (ночные) или непрерывные циклы.
Кроме того, независимо от того, ограничиваете ли вы доступ к проекту вашим разработчикам или большей группе пользователей, ночная сборка позволяет каждому быть в "последней версии", сводя к минимуму боль от слияния собственных вкладов обратно в код.
Ответ 7
Вы хотите делать сборки на регулярном графике, чтобы уловить проблемы с интеграцией кода между разработчиками. Причина, по которой вы хотите сделать это в ночное время, в отличие от еженедельного или в каком-то более продолжительном графике, заключается в том, что чем дольше вы будете ждать, чтобы обнаружить эти проблемы, тем труднее будет их разрешить. Практика построения сборки при каждой проверке (непрерывная интеграция) просто приводит к процессу ночной сборки к логическому пределу.
В долгосрочной перспективе важно также иметь повторяющийся процесс сборки. Если вы работаете в команде, где происходит несколько проектов, то в какой-то момент вам нужно будет легко воссоздать старую сборку, возможно, для создания патча.: (
Чем больше вы можете автоматизировать процесс сборки, тем больше времени вы сохраните для каждой последующей сборки. Он также берет сам процесс сборки от критического пути доставки конечного продукта, что должно сделать вашего менеджера счастливым.:)
Ответ 8
Это также зависит от размера и структуры команды (ов), работающих над вашим проектом. Если существуют разные команды, полагающиеся на API друг друга, может возникнуть большой смысл иметь ночные сборки для частой интеграции. Если вы взламываете только одного или двух товарищей по команде, это может быть или не стоить того.
Ответ 9
В зависимости от сложности вашего продукта непрерывная интеграция может или не сможет запустить полный набор тестов.
Представьте, что Cisco тестирует маршрутизатор с буквально 1000 различных тестов для тестирования. Для запуска полного набора тестов на некоторые продукты требуется время. Иногда недели. Поэтому вам нужны сборки для разных целей. Ночная сборка может стать основой для более тщательного набора тестов.
Ответ 10
Ну... Думаю, это сильно зависит от вашего проекта, конечно. Если это только ваш проект хобби, без релизов, никаких зависимостей и никого, кроме того, что вы отправляете код, это может быть излишним.
Если, с другой стороны, команда разработчиков, отправляющая код, автоматическая ночная сборка, поможет вам обеспечить качество кода в репозитории. Если кто-то делает что-то, что "ломает сборку" для всех остальных, это будет быстро замечено. Можно разбить сборку, не заметив, например, забыв добавить новый файл в репозиторий, а ночные сборки в централизованном месте обнаружат их довольно быстро.
Есть, конечно, другие возможные преимущества, я уверен, что другие будут их снабжать.:)
Ответ 11
Я думаю, что они очень важны, особенно для проектов с более чем 1 человеком. Команда должна знать как можно скорее, если кто-то:
- проверит в плохом файле
- не проверяет файл
- ...
Ответ 12
Любая автоматизация сборки лучше, чем автоматизация сборки: -)
Лично я предпочитаю ежедневные сборки - таким образом, если сборка не работает, все вокруг исправляются.
Фактически, если это возможно, то сборка непрерывной интеграции - это способ пойти (т.е. построить на каждой регистрации), поскольку это минимизирует количество изменений между сборкой и поэтому позволяет легко определить, кто нарушил сборку а также легко исправить сборку.
Ответ 13
Ночные сборки необходимы только для значительных крупных проектов (когда требуется слишком много времени, чтобы строить его часто в течение дня). Если у вас есть небольшой проект, который не займет много времени, вы можете его построить, когда вы получите функциональные фрагменты кода, чтобы вы знали, что ничего не делали в процедурах. Однако с большими проектами это невозможно, поэтому важно построить проект именно так, чтобы вы знали, что все еще в рабочем состоянии.
Ответ 14
Есть несколько причин, некоторые из них будут более применимы, чем другие.
- Если ваш проект обрабатывается двумя или более людьми
- Это хороший способ захватить последнюю версию кода, с которой вы не работаете.
- Ночная сборка обеспечивает срез во время текущего состояния кода
- Ночная сборка даст вам стабильную сборку, если вам нужно отправить код людям
Ответ 15
Ночные сборки не всегда нужны - я думаю, что они действительно полезны только для крупных проектов. Но если вы находитесь в большом проекте, ночная сборка - это хороший способ проверить, что все работает - вы можете запускать все свои тесты (модульные тесты, интеграционные тесты), построить весь свой код - словом, убедитесь, что ничего нет в вашем проекте.
Если у вас есть меньший проект, время сборки и тестирования будет короче, поэтому вы можете позволить себе делать более регулярные сборки.
Ответ 16
Ночные сборки идеально подходят для выполнения статического анализа кода (см. qalab и проекты, с которых он собирает статистику, если вы находитесь в мире java). К сожалению, это редко делается.