Предположим, что я установил automatic nightly build. Какие артефакты сборки я должен сохранить?Какие артефакты сохраняются для ночной сборки?
Например:
Кроме того, как долго я должен спасти их, и где?
Выполняют ли ваши ответы, если я выполняю непрерывную интеграцию?
Вот некоторые артефакты/информация, которую я привык держать в каждой сборке:
Задайте себе этот вопрос: «если что-то разрушает полностью мое окружение/развития сборки, какую информацию мне нужно, чтобы создать новую, так что я могу повторить мою сборку # 6547 и в конечном итоге с точно таким же результатом У меня есть первый раз?
Ваш ответ - это то, что вы должны соблюдать при каждой сборке, и это будет подмножество или надмножество вещей, о которых я уже упоминал.
Вы можете хранить все в своем SCM (я бы рекомендовал отдельный репозиторий), но в этом случае ваш вопрос о том, как долго вы должны держать предметы, теряет смысл. Или вы должны сохранить его в zip-папках или записать cd/dvd с результатом сборки и артефактами. Что бы вы ни выбрали, сделайте резервную копию.
Вы должны хранить их до тех пор, пока они вам могут понадобиться. Как долго это будет зависеть от темпов вашей команды разработчиков и вашего цикла выпуска.
И нет, я не думаю, что это изменится, если вы продолжаете интеграцию.
Мы сохраняем двоичные файлы, разделенные и несвязанные (так что у нас есть точно такой же двоичный код, один раз с и один раз без символов отладки). Далее мы создаем все два раза, один раз с включенным отладочным выходом и один раз без него (опять же, разделенный и unstripped, поэтому каждая сборка приводит к 4 бинарным файлам). Строка хранится в каталоге в соответствии с номером ревизии SVN. Таким образом, мы всегда можем сохранить источник из репозитория SVN, просто проверив эту самую ревизию (таким образом, архив также архивируется).
Вы не должны ничего спасать ради сохранения. вы должны сохранить его, потому что он вам нужен (т. е. QA использует ночные сборки для тестирования). В этот момент, «как долго его сохранить», становится все же длиннее QA.
Я бы не «сохранил» исходный код так же, как тег/метку. Я не знаю, какой источник управления вы используете, но тегирование тривиально (производительность & дискового пространства) для любой системы управления качеством. Как только ваша сборка будет помечена, если вам не нужны бинарные файлы, действительно нет никакой пользы от их простого использования, потому что вы можете просто перекомпилировать, когда это необходимо, из источника.
Большинство инструментов CI позволяют отмечать каждую успешную сборку. Это может стать проблемой для некоторых систем, так как вы можете легко иметь более 100 тегов в день. Для таких случаев я рекомендую по-прежнему запускать ночную сборку и только тегирование.
Сохраните, как в режиме проверки исходного кода или просто на диске? Не сохраняйте ничего для управления исходным кодом. Все производные файлы должны быть видны в файловой системе и доступны разработчикам. Не проверяйте двоичные файлы, код, сгенерированный из файлов XML, дайджесты сообщений и т. Д. Отдельный этап упаковки сделает эти конечные продукты доступными. Поскольку у вас есть номер изменения, вы всегда можете воспроизвести сборку, если необходимо, если, конечно, все, что вам нужно для сборки, полностью находится в дереве и доступно для всех построений путем синхронизации.
Я тоже думал об этом, но после работы с клиентом, который сохранил все двоичные файлы и другие сгенерированные артефакты в системе контроля версий, я рекомендую все это в системе контроля версий. Это действительно легко захватить * все * для конкретного выпуска и отладить его с минимальной суматохой. – 2009-03-19 17:25:58
В дополнение к двоичным файлам, как упомянуто всеми остальными, я рекомендовал бы установить symbol server и source server и убедиться, что вы получите правильную информацию и в нее. Это поможет в отладке чрезвычайно.
Это не прямой ответ на ваш вопрос, но не забывайте управлять версиями самой ночной сборки. Когда структура проекта изменится, вам, возможно, придется изменить процесс сборки, который сломает старые сборки с этого момента.
Я бы сэкономил ваши встроенные двоичные файлы в течение всего времени, пока у них есть шанс вступить в производство или использоваться какой-либо другой командой (например, группой QA). Когда-то что-то покинуло производство, то, что вы делаете с ним, может сильно различаться. Для многих команд они будут поддерживать только их недавнюю предварительную сборку (для отката) и в противном случае отказаться от своих сборок.
Другие имеют нормативные требования, чтобы сохранить все, что входило в производство, в течение семи лет (банков).Если вы являетесь компанией-производителем, я бы обошел любые бинарные файлы, которые мог бы установить клиент, если тот, кто ищет техническую поддержку, хочет установить ту же версию.
Удивительные один я узнал о недавно: Если вы находитесь в среде, которая может быть проверяемой вы хотите сохранить все результаты вашего билда, выход сценария, выход компилятора и т.д.
Это единственный способ проверить ваши настройки компилятора, шаги сборки и т. Д.
Также, как долго их сохранить и где их можно сохранить?
Сохраните их, пока не узнаете, что сборка не будет производиться, до тех пор, пока у вас есть скомпилированные биты.
Одним из логических мест для их сохранения является ваша система SCM. Другой вариант - использовать инструмент, который автоматически сохранит их для вас, например AnthillPro и его аналоги.
Мы делаем что-то близкое к «вкладывается» развитие здесь, и я могу вам сказать, что мы экономим:
Мы также отправляем по электронной почте результат запуска некоторых инструментов над «побочными эффектами» для заинтересованных пользователей. Мы на самом деле не архивировать их, так как мы можем воспроизвести их позже, но эти отчеты включают в себя:
Когда мы проводим модульные тесты или функциональные тесты (например, тесты на дым), эти результаты отображаются в журнале сборки.
Мы еще ничего не выбрасываем - данные, наши целевые сборки обычно заканчиваются на ~ 16 или 32 MiB для каждой конфигурации, и они довольно сжимаются.
Мы сохраняем несжатые копии двоичных файлов в течение 1 недели для удобства доступа; после этого мы сохраняем только слегка сжатую версию. Примерно раз в месяц у нас есть скрипт, который извлекает каждый .zip, который производит процесс сборки, и 7-zip целый месяц сборок сборки (что позволяет использовать только небольшие различия для каждой сборки).
Средний день может иметь дюжину или две сборки в каждом проекте ... Каждый раз, каждые 5 минут, каждый раз каждые 5 минут каждый раз просыпается строительный сервер, чтобы проверить наличие соответствующих различий и сборок. Полный .7z на большом очень активном проекте в течение месяца может быть 7-10GiB, но это, безусловно, доступно.
По большей части мы смогли диагностировать все таким образом. Иногда в сборке есть икота, и файл на самом деле не является ревизией, которую он должен делать, когда происходит сборка, но в журналах обычно достаточно доказательств. Иногда нам приходится выкапывать инструмент, который понимает формат отладочной базы данных и подает ему несколько адресов для диагностики сбоя (у нас есть автоматические стеки, встроенные в продукт). Но обычно нужна вся необходимая информация.
Нам еще не пришлось взломать архивы .7z, чтобы упомянуть. Но у нас есть информация, и у меня есть несколько интересных идей о том, как добывать из нее полезные ископаемые данные.
Мне понравился ваш ответ; спасибо, что написал. – 2009-03-22 05:36:14
Сохраните то, что нельзя воспроизвести легко. Я работаю над FPGA, где есть только команда FPGA, а некоторые ядра (библиотеки) проекта лицензированы для компиляции только на одной машине. Таким образом, мы сохраняем выходные битовые потоки. Но попробуйте проверить их друг над другом, а не с печатью даты/времени/версии.
Вам нужно только надежно идентифицировать ваш исходный код. В зависимости от вашего VCS это может означать использование копий, но спецификация исходного кода может быть адекватной. Кроме того, в те дни, когда вы можете купить 2 ТБ дискового накопителя за 200 долларов, возможно, вы сохранили источник (сжатый, даже сейчас). – 2009-03-17 02:55:02
2TB диска за 200 долларов? Вы имеете в виду покупку двух приводов 1TB по цене $ 100 ea, или вы думаете, что можете получить 30% скидку на newegg? http://www.newegg.com/Product/Product.aspx?Item=N82E16822136344 – 2009-03-18 15:25:34