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

Question

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

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

Я начал хранить в своих проектах папку «Ресурсы», которая содержит все необходимые ссылки на dll в системе контроля версий. Может ли кто-нибудь еще сделать некоторые предложения?

Answer 1

Найдите старый компьютер, который не используется, и настройте его на автоматическую "непрерывную сборку":

1. Подождите, пока кто-нибудь не внесет изменения
2. Обновление до последней версии всех файлов.
3. Очистите все контрольные файлы, не связанные с исходным кодом (make clean недостаточно - найдите и удалите мусор)
4. Сложение.
5. Запуск юнит-тестов.
6. Один раз в день сохраняйте двоичные файлы после успешного запуска. Назовите это «официальной сборкой» за день.

Если сборка или тесты не пройдены, отправьте письмо с ошибкой. Включите список изменений, которые были подобраны в # 2.

Если вы действительно не можете найти машину, сделайте это на виртуальной машине.

Answer 2

Предполагая, что вы находитесь в среде Visual Studio, вот некоторые вещи, которые вы могли бы найти полезными, YMMV, конечно, и обратите внимание, что мы используем Subversion, но любой инструмент VCS должен делать ...

• Поместите все (или как можно больше) зависимостей под контроль версий и укажите их в своих проектах. Мы используем Subversion externals для управления этим.
• Не управлять версиями стандартных выходных каталогов (bin, obj), т. Е. Использовать svn: ignore
• Аналогично, игнорируйте элементы управления версиями (* .user, * .suo)
• Также не используйте файлы конфигурации управления версиями (App | Web.config), вместо этого создайте App.default.config, и в ваших проектах задача BeforeBuild скопируйте этот файл в App.config. Это позволяет вам модно использовать RegEx и токены для настройки компиляций для каждого разработчика или сервера сборки, а также позволяет удалять любые существующие файлы App.config в сборках CI, чтобы гарантировать чистую сборку каждый раз. Это также позволяет разработчикам обходиться с конфигурациями, не мешая другим, пока они не будут готовы, то есть обновите App.default.config.
• Контроль версий всего остального:)
• Если в результате вашей компиляции вам понадобятся двоичные файлы управления версиями (MSI, DLL и т. Д.), В целевом проекте AfterBuild (wixproj и т. Д.) Скопируйте выходные данные в другой каталог, находящийся под управлением версией. Одним из советов по использованию Subversion является то, что вы можете добавить / зафиксировать в каталог svn: externals, который позволяет выталкивать библиотеки и т. Д. Для проецирования, которые ссылаются на них.

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

Answer 3

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

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

Сейчас 1 час ночи, и я звучу бессвязно, но две идеи являются центральными:

• Иметь виртуальную машину или каталог chroot, который может имитировать пустую систему. В наши дни виртуальная машина, вероятно, самая простая.

• Настраивайте вашу систему сборки до тех пор, пока она автоматически не проверит и не соберет на вашей виртуальной машине --- или не пожалуетесь на то, чего не хватает.

В этот момент вы можете сделать процесс частью автоматической ночной сборки, и вы станете счастливым туристом: -)

Answer 4

Может ли кто-нибудь еще сделать некоторые предложения?

1. Храните файлы, которые вам нужно собрать, в одном месте (один каталог и его подкаталоги) ... большинство систем контроля версий называют это вашим "рабочим каталогом"
2. В вашем программном обеспечении для управления версиями есть команда для перечисления различий между тем, что находится в вашем рабочем каталоге, и тем, что находится под контролем версий ... эта "разница" включает файлы, которые существуют в рабочем каталоге и которые не находятся под контролем версий
3. Настройте программное обеспечение для контроля версий, чтобы исключить (из списка, отображаемого на шаге 2.) файлы, тип которых вы не хотите хранить ... например, вы можете захотеть хранить только исходный код и исключить *.obj и так далее ... исключение этих типов файлов означает, что при выполнении шага 2 список различий не будет заполнен файлами, которые вы не собираетесь хранить
4. Подумайте о том, чтобы иметь машину для сборки, которая автоматически выполняет извлечение и сборку (и которая отправляет вам электронное письмо, если «сборка не работает»)

Answer 5

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

Инструменты непрерывной интеграции, такие как cruisecontrol , многократно извлекают и создают ваше приложение после каждой регистрации, которые могут предупреждать вас о проверках, которые нарушают сборку ... Кроме того, они могут запускать ваши юнит-тесты и, таким образом, предупреждает вас о любых регрессах, вызванных вашей регистрацией, тоже ...

Answer 6

SCons - это еще один инструмент, который работает кроссплатформенно и помогает управлять вашими зависимостями. Подобно gnu make в, у вас есть «файл / скрипт scons» - и тот факт, что он использует python, дает вам большую гибкость.

http://www.scons.org/

(мне нечего делать с SCons; мы просто используем это)

Answer 7

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

Вместо этого установите простой сервер непрерывной интеграции - CruiseControl.Net с открытым исходным кодом; TeamCity от JetBrains бесплатен - он проверяет работу сборок каждый раз, когда производится проверка.

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

Answer 8

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

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

В моей компании мы используем Rational ClearCase. Все проверяется в управлении исходным кодом, за исключением сгенерированных файлов исходного кода (например, файлов .cpp и .h, сгенерированных из компилятора MIDL). Из-за этого большинство сборок идут довольно гладко.

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