Ночные Сборки: Почему я должен сделать это? [закрытый]

Необходимо сделать ночные сборки, чтобы гарантировать, что кодовая база остается здоровой.

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

Автоматизированные сборки способны находить следующие проблемы:

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

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

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

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

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

Существует несколько причин, некоторые будут более применимыми, чем другие

• , Если Ваш проект будет работаться на двумя или больше людьми
• , Это - хороший способ захватить последнюю версию кода, что Вы не работаете над
• А, который ночная сборка обеспечивает части во время текущего состояния кода
• А, ночная сборка даст Вам стабильную сборку, если необходимо отправить код людям

Ночные сборки только необходимы для значительно крупных проектов (когда занимает слишком много времени создавать его часто в течение дня). Если у Вас есть маленький проект, который не занимает много времени создавать Вас, может создать его, поскольку Вы получаете функциональные части кода, сделанного так, чтобы Вы знали, что ничего не испортили в procees. Однако с большими проектами это не возможно, таким образом, важно разработать проект именно так, что Вы знаете, что все все еще в рабочем состоянии

Любая автоматизация сборки не лучше, чем никакая автоматизация сборки:-)

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

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

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

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

существуют, конечно, другие возможные преимущества, я уверен, что другие предоставят их.:)

Я думаю, что они очень важны особенно на проектах больше чем с 1 человеком. Команда должна знать как можно скорее если кто-то:

• регистрации плохого файла
• не регистрируется в файле
• ...

Ночные сборки идеальны для выполнения статического анализа кода (см. qalab и проекты, это собирает статистику из того, если Вы находитесь в мире Java). К сожалению, это - что-то, что это редко делается.

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

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

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

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

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

Я на самом деле рекомендовал бы сделать сборки каждый раз, когда Вы регистрируетесь. Другими словами, я рекомендовал бы настроить Непрерывную систему Интеграции.

преимущества такой системы и других деталей могут быть найдены в статье и Fowler о статье в Википедии среди других мест.

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

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

Вы не делаете на самом деле, что необходимо желать, Непрерывная Интеграция и автоматическое тестирование (который является шагом вперед, чем ночные сборки).

, Если Вы находитесь в сомнении, необходимо читать эта статья Martin Fowler о Непрерывной Интеграции .

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

Я лично нашел, что непрерывная интеграция лучше, чем ночные сборки:
http://en.wikipedia.org/wiki/Continuous_integration

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

Я делал разработку сборки (среди прочего) в течение 16 лет. Я твердо уверенным в сборке рано, сборке часто, непрерывной интеграции. Таким образом, первая вещь, которую я делаю с проектом, устанавливают, как она будет создана (Java: Муравей или Знаток ;.NET: NAnt или MSBuild) и как этим будут управлять ( Подрывная деятельность или некоторое другое управление версиями). Тогда я добавлю Непрерывную Интеграцию ( CruiseControl или CruiseControl.NET ) в зависимости от платформы, затем выпущу других разработчиков.

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

Это - то, что я делаю - вот то, почему я делаю это (и почему Вы должны также):

предположим у Вас есть типовое приложение с несколькими проектами и несколькими разработчиками. В то время как разработчики могут запустить с общей, последовательной среды разработки (та же ОС, те же патчи, те же инструменты, те же компиляторы), со временем их среды будут отличаться. Некоторые разработчики неукоснительно применят все патчи безопасности и обновления, другие не будут. Некоторые разработчики добавят новый (возможно, лучше) инструменты, другие не будут. Некоторые не забудут обновлять их полную рабочую область перед зданием; другие только обновят часть проекта, который они разрабатывают. Некоторые разработчики добавят файлы исходного кода и файлы данных к проекту, но забудут добавлять их к управлению исходным кодом. Другие запишут модульные тесты, которые зависят от определенных причуд их среды. Как следствие Вы будете быстро видеть когда-либо популярное "ну, Это создает/работает на моей машине" оправдания.

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

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