Ежедневные сборки, это реально? - PullRequest
8 голосов
/ 05 января 2009

Как в мире вы можете поддерживать ежедневную сборку в магазине с одним человеком или даже (особенно) в более крупных магазинах?

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

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

Является ли целью разработки обеспечение работоспособности сборки при каждом изменении?

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

Ответы [ 10 ]

10 голосов
/ 05 января 2009

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

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

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

8 голосов
/ 05 января 2009

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

Как в мире можно ожидать, что все будет вместе без одного? Цель состоит в том, чтобы каждая регистрация в хранилище могла генерировать чистую сборку. Если это невозможно, значит, вы не делаете все правильно.

Это особенно важно, когда в репозиторий исходного кода вносятся большие изменения.

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

Легко, только строить из репозитория. Только проверяйте вещи в репозитории, который работает.

Является ли целью развития обеспечение строить работы через каждый изменить?

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

4 голосов
/ 05 января 2009

Я использовал CruiseControl для реализации Continues Integration, которая даже создает новые сборки и развертывает их на при каждой регистрации SVN , поэтому ответ на этот вопрос является окончательным ДА ...;)

4 голосов
/ 05 января 2009

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

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

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

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

Затем вы можете объединить изменения из вашей ветки разработки с основной веткой.

3 голосов
/ 05 января 2009

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

На всех моих проектах мы строим ЧАСЫ. Для этого мы используем Luntbuild, и он отправит по почте всем участникам проекта, как только сборка закончится неудачей, и продолжит рассылку до тех пор, пока сборка не сработает. Сломанный код не регистрируется, и когда кто-то ломает сборку, он должен получить куки для всей команды (или другое подходящее «унижение» :-)).

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

Вы увидите, что это приведет к улучшению кода и возможности отправки проекта практически в любое время в течение проекта, потому что:

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

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

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

Надеюсь, это поможет. Держите их зелеными! (юнит-тесты, то есть)

edit: «Нажатие на кнопку», на которую вы ссылаетесь, это «пошаговая сборка». Это означает, что у вас есть скрипт, который выполняет сборку (или ant, или maven, или что-то еще), и вы используете этот скрипт для выполнения тестов aswel. Таким образом, когда ваш автоматизированный процесс сборки работает, вы знаете, что у вас есть готовый продукт. Вы просто запускаете скрипт и отправляете вывод клиенту. Наш скрипт сборки создает структуру каталогов, которая копируется 1-на-1 на компакт-диск, с которым мы поставляем программное обеспечение.

1 голос
/ 05 января 2009
1 голос
/ 05 января 2009

На моем нынешнем выступлении мы, по крайней мере, выполняем ежедневную сборку нашего приложения Java EE, используя CruiseControl, репозиторий Ivy, Ant & ClearCase. Мы большая команда, и мы можем позволить себе команду из 3 человек и собрать серверы.

Да, проблемы, которые вы называете, случаются, такие как ошибочные изменения БД, неправильные слияния, неправильные компиляции и тесты. Но в целом у нас не было бы другого пути.

1 голос
/ 05 января 2009

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

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

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

1 голос
/ 05 января 2009

Самый простой способ иметь ежедневные сборки - это работать в потоках.

Иметь поток разработки, поток QA (или тестовый) и, наконец, поток релиза.

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

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

1 голос
/ 05 января 2009

Короче ...

Автоматизировать.

Не регистрируйте его, пока оно не будет сделано.

Да.

...