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

Question

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

Например:

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

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

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

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

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

Answer 7

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

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

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

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

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

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

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

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

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

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

Answer 8

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

Answer 9

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

Answer 10

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

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