Какие артефакты сохранить для ночной сборки?

Question

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

Например:

• Исходный код
• выходные двоичные файлы

Кроме того, как долго я должен их сохранять и где?

Изменится ли ваш ответ, если я сделаю непрерывную интеграцию?

Answer 1

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

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

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

Answer 2

Вот некоторые артефакты / информация, которую я использую для каждой сборки:

• Имя тега создаваемого снимка (отметьте и выполните чистую проверку до создания )
• Сценарии сборки сами или их номер версии (если вы рассматриваете их как отдельный проект с собственным контролем версий)
• Вывод скрипта сборки: журналы и конечный продукт
• Снимок вашей среды:
  • версия компилятора
  • версия инструмента сборки
  • библиотеки и версии dll / libs
  • версия базы данных (клиент и сервер)
  • ide version
  • версия интерпретатора сценария
  • версия ОС
  • версия контроля версий (клиент и сервер)
  • версии других инструментов, используемых в процессе, и все остальное, что может повлиять на содержимое ваших сборочных продуктов. Я обычно делаю это с помощью скрипта, который запрашивает всю эту информацию и записывает ее в текстовый файл, который должен быть сохранен с другими артефактами сборки.

Задайте себе вопрос: «Если что-то полностью разрушит мою среду сборки / разработки, какая информация мне понадобится для создания новой, чтобы я мог повторить сборку # 6547 и получить точно такой же результат, который получил в первый раз? «

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

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

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

И нет, я не думаю, что это изменится, если вы продолжите непрерывную интеграцию.

Answer 3

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

Answer 4

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

Answer 5

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

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

Кроме того, как долго их сохранять и где их сохранять?

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

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

Answer 6

Мы сохраняем двоичные файлы, раздетые и распакованные (поэтому мы имеем точно такой же двоичный файл, один раз с символами отладки и один раз без них). Далее мы строим все дважды, один раз с включенным отладочным выводом и один раз без (опять же, раздетые и разорванные, поэтому каждая сборка приводит к 4 двоичным файлам). Сборка хранится в каталоге в соответствии с номером редакции SVN. Таким образом, мы всегда можем сохранить источник из репозитория SVN, просто проверив эту самую ревизию (таким образом, источник также будет заархивирован).

Answer 7

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

Answer 8

Мы делаем что-то похожее на «встроенную» разработку, и я могу сказать вам, что мы экономим:

• номер версии SVN и метка времени, а также машина, на которой он был создан и кем (также записанный в двоичные файлы сборки)
• полный журнал сборки, показывающий, была ли это полная / инкрементная сборка, любой интересный (STDERR) вывод созданных инструментов для выпечки данных, список скомпилированных файлов и любые предупреждения компилятора (это сжимается очень хорошо, будучи текстовым)
• фактические двоичные файлы (для 1-8 конфигураций сборки)
• файлов, создаваемых как побочный эффект компоновки: командный файл компоновщика, карта адресов и своего рода файл "манифеста", указывающий, что было записано в конечные двоичные файлы (CRC и размер для каждого), а также базу данных отладки. (эквивалент .pdb)

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

• общее и дельта размера файловой системы, с разбивкой по типу файла и / или каталогу
• общее и дельта размеров разделов кода (.text, .data, .rodata, .bss, .sinit и т. Д.)

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

Мы еще ничего не выбросили - учитывая, что наши целевые сборки обычно заканчиваются на ~ 16 или 32 МБ на конфигурацию, и они довольно сжимаемы.

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

В среднем в день может быть от дюжины до двух сборок на проект ... Сервер сборки включается примерно каждые 5 минут, чтобы проверить наличие соответствующих различий и сборок. Полный .7z на большом очень активном проекте в течение одного месяца может быть 7-10 ГБ, но это, безусловно, доступно.

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

Нам еще не приходилось взламывать архивы .7z. Но у нас там есть информация, и у меня есть несколько интересных идей о том, как извлечь из нее кусочки полезных данных.

Answer 9

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

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

Answer 10

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