Предположим, я установил автоматическую ночную сборку. Какие артефакты сборки нужно сохранить?
Например:
Кроме того, как долго я должен их хранить и где?
Меняются ли ваши ответы, если я использую непрерывную интеграцию?
Вот некоторые артефакты / информация, которые я привык хранить при каждой сборке:
Задайте себе вопрос: «Если что-то полностью разрушит мою среду сборки / разработки, какая информация мне понадобится для создания новой, чтобы я мог повторить свою сборку № 6547 и получить тот же результат, что и в первый раз?»
Ваш ответ - то, что вы должны сохранять при каждой сборке, и это будет подмножество или надмножество того, что я уже упоминал.
Вы можете хранить все в своем SCM (я бы рекомендовал отдельный репозиторий), но в этом случае ваш вопрос о том, как долго вы должны хранить элементы, теряет смысл. Или вы должны сохранить его в заархивированных папках или записать компакт-диск / DVD с результатом сборки и артефактами. Что бы вы ни выбрали, имейте резервную копию.
Вы должны хранить их столько, сколько они вам могут понадобиться. Как долго будет зависеть от темпа вашей команды разработчиков и цикла выпуска.
И нет, я не думаю, что это изменится, если вы сделаете непрерывную интеграцию.
Не нужно ничего сохранять ради сохранения. вы должны сохранить его, потому что он вам нужен (т.е. QA использует ночные сборки для тестирования). В этот момент «как долго хранить» становится столько, сколько нужно QA.
я бы не стал «сохранять» исходный код настолько, чтобы пометить его. Я не знаю, какой исходный код вы используете, но тегирование тривиально (производительность и дисковое пространство) для любой качественной системы контроля версий. После того, как ваша сборка помечена, если вам не нужны двоичные файлы, на самом деле нет никакой пользы в том, чтобы просто иметь их, потому что вы можете просто перекомпилировать, когда это необходимо, из исходного кода.
Большинство инструментов CI позволяют отмечать каждую успешную сборку. Это может стать проблемой для некоторых систем, так как вы легко можете иметь более 100 тегов в день. В таких случаях я рекомендую по-прежнему запускать ночную сборку и только отмечать ее.
Это не прямой ответ на ваш вопрос, но не забывайте контролировать версию самой ночной настройки сборки. Когда структура проекта изменится, вам, возможно, придется изменить процесс сборки, что с этого момента приведет к поломке старых сборок.
В дополнение к двоичным файлам, как уже упоминалось всеми, я бы порекомендовал настроить сервер символов и исходный сервер и убедитесь, что вы получаете правильную информацию и в них. Это очень поможет в отладке.
Мы сохраняем двоичные файлы, разделенные и не разделенные (так что у нас есть один и тот же двоичный файл, один раз с символами отладки и один раз без них). Далее мы собираем все дважды: один раз с включенным отладочным выводом и один раз без него (снова с разделением и без разделения, поэтому каждая сборка приводит к 4 двоичным файлам). Сборка сохраняется в каталоге в соответствии с номером версии SVN. Таким образом, мы всегда можем сохранить исходный код из репозитория SVN, просто проверив эту самую ревизию (таким образом, источник также будет заархивирован).
Удивительный момент, о котором я узнал недавно: если вы находитесь в среде, которая может быть подвергнута аудиту, вы захотите сохранить весь вывод вашей сборки, вывод скрипта, вывод компилятора и т. Д.
Это единственный способ проверить настройки компилятора, шаги сборки и т. Д.
Кроме того, как долго их хранить и где их хранить?
Сохраняйте их, пока не узнаете, что сборка не будет запущена в производство, пока у вас есть скомпилированные биты.
Логичное место для их сохранения - ваша система SCM. Другой вариант - использовать инструмент, который автоматически сохранит их для вас, например AnthillPro и ему подобные.
Здесь мы делаем что-то близкое к «встроенной» разработке, и я могу сказать вам, что мы экономим:
Мы также рассылаем заинтересованным пользователям результаты запуска некоторых инструментов над файлами «побочных эффектов». На самом деле мы не архивируем их, поскольку мы можем воспроизвести их позже, но эти отчеты включают:
Когда у нас запущены модульные или функциональные тесты (например, дымовые тесты), эти результаты отображаются в журнале сборки.
Мы еще ничего не выбросили - учитывая, что наши целевые сборки обычно составляют ~ 16 или 32 МБ на конфигурацию, и они довольно сжимаемы.
Мы храним несжатые копии двоичных файлов около 1 недели для облегчения доступа; после этого остается только слегка сжатая версия. Примерно раз в месяц у нас есть сценарий, который извлекает каждый .zip, созданный в процессе сборки, и 7-zip-архивирует результаты сборки за месяц (что позволяет использовать только небольшие различия для каждой сборки).
В среднем в день может быть дюжина или две сборки на проект ... Сервер сборки просыпается каждые 5 минут, чтобы проверить наличие соответствующих различий и сборок. Полный .7z для большого и очень активного проекта в течение одного месяца может составлять 7–10 ГБ, но это, безусловно, доступно.
По большей части таким образом мы смогли все диагностировать. Иногда возникает сбой в системе сборки, и файл на самом деле не является той ревизией, которой должен быть, когда происходит сборка, но обычно в журналах достаточно свидетельств этого. Иногда нам нужно откопать инструмент, который понимает формат отладочной базы данных, и скормить ему несколько адресов для диагностики сбоя (у нас есть автоматические дампы стека, встроенные в продукт). Но обычно вся необходимая информация есть.
Следует упомянуть, что нам еще не пришлось взламывать архивы .7z. Но у нас есть информация, и у меня есть несколько интересных идей о том, как извлечь из нее полезные данные.
Сохраняйте то, что невозможно легко воспроизвести. Я работаю над ПЛИС, где инструменты есть только у команды ПЛИС, а некоторые ядра (библиотеки) проекта лицензированы для компиляции только на одной машине. Итак, мы сохраняем выходные битовые потоки. Но попробуйте сравнить их друг с другом, а не с отметкой даты / времени / версии.
Сохранить как в контроле исходного кода или просто на диске? Ничего не сохраняйте в исходном коде. Все производные файлы должны быть видны в файловой системе и доступны разработчикам. Не возвращайте двоичные файлы, код, сгенерированный из файлов XML, дайджесты сообщений и т. Д. Эти конечные продукты будут доступны на отдельном этапе упаковки. Поскольку у вас есть номер изменения, вы всегда можете воспроизвести сборку, если необходимо, при условии, конечно, что все, что вам нужно для сборки, полностью находится в дереве и доступно для всех сборок путем синхронизации.
Я бы сохранил ваши созданные двоичные файлы ровно до тех пор, пока у них есть шанс пойти в производство или использоваться какой-либо другой командой (например, группой контроля качества). После того, как что-то вышло из производства, ваши действия могут сильно отличаться. Многие команды сохраняют только самую последнюю предыдущую сборку (для отката) и в противном случае сбрасывают свои сборки.
У других есть нормативные требования о хранении всего, что было запущено в производство, в течение семи лет (банки). Если вы производственная компания, я бы сохранил любой двоичный файл, который мог установить клиент, на случай, если специалист службы технической поддержки захочет установить ту же версию.
