Какие артефакты сохранить для ночной сборки?
В транзакциях это может быть так же просто, как получить значение ввода из поля, например:
transactions: [{
amount: {
total: document.getElementById("paymentInput").value,
currency: 'USD'
}
}]
Хотя я бы также немного проделал санитарную обработку ввода, прежде чем слепо принять ввод с клавиатуры. [116 ]
Вот рабочий пример:
document.getElementById("submitButton").addEventListener("click", handleSubmit);
function handleSubmit() {
let payment = function(data, actions) {
return {
transactions: [{
amount: {
total: document.getElementById("paymentInput").value,
currency: 'USD'
}
}]
}
}
console.log(`payment of ${payment().transactions[0].amount.total} submitted`)
}<input id="paymentInput" />
<button id="submitButton">Submit</button>10 ответов
Вот некоторые артефакты/информация, которые я используюсь для хранения в каждой сборке:
- Имя тега снимка, который Вы создаете (отмечают и делают чистый контроль перед созданием),
- Сценарии сборки themselfs или их номер версии (если Вы рассматриваете их как отдельный проект с его собственным управлением версиями),
- Вывод сценария сборки: журналы и конечный продукт
- Снимок Вашей среды:
- версия компилятора
- версия инструмента сборки
- библиотеки и dll/libs версии
- версия базы данных (клиент и сервер)
- версия язя
- версия интерпретатора сценария
- Версия ОС
- версия управления исходным кодом (клиент и сервер)
- версии других инструментов использовали в процессе и всем остальном, что могло бы влиять на содержание Ваших продуктов сборки. Я обычно делаю это со сценарием, который запрашивает всю эту информацию и регистрирует ее к текстовому файлу, который должен быть снабжен другими артефактами сборки.
Задайте себе этот вопрос: "если бы что-то уничтожает полностью мою сборку/среду разработки, какая информация я должен был бы создать новую, таким образом, я могу восстановить свою сборку № 6547 и закончить с тем же самым результатом, который я получил в первый раз?"
Ваш ответ - то, что необходимо сохранить в каждой сборке, и это будет подмножество или надмножество вещей, которые я уже упомянул.
Можно сохранить все в SCM (я рекомендовал бы отдельный репозиторий), но в этом случае вопрос на том, сколько времени необходимо сохранить объекты, освобождает смысл. Или необходимо сохранить его к заархивированным папкам или записать cd/dvd с результатом сборки и артефактами. Независимо от того, что Вы выбираете, имеете резервную копию.
Необходимо сохранить их, пока Вам, возможно, понадобились бы они. Сколько времени, будет зависеть от Вашего темпа группы разработчиков и Вашего цикла выпуска.
И не, я не думаю, что это изменяется, если Вы делаете непрерывную интеграцию.
Вы ничего не должны сохранять ради сохранения его. необходимо сохранить его, потому что Вам нужен он (т.е. QA использует ночные сборки для тестирования). В котором точка, "сколько времени можно сохранить его", становится однако длинным QA, хочет их.
я не "сохранил" бы исходный код так как тег/маркировку это. Я не знаю, какое управление исходным кодом Вы используете, но отмечаете, тривиально (производительность и дисковое пространство) для любой качественной системы управления исходным кодом. После того как Ваша сборка отмечена, если Вам не нужны двоичные файлы, действительно нет никакого преимущества для просто наличия их вокруг, потому что можно просто перекомпилировать при необходимости из источника.
Инструменты Most CI позволяют Вам наклеить каждую успешную сборку. Это может стать проблематичным для некоторых систем, как Вы можете легко иметь 100 +, отмечает день. Для таких случаев я рекомендую все еще выполнить ночную сборку и только отметить это.
Это не прямой ответ на Ваш вопрос, но не забывайте к управлению версиями саму ночную установку сборки. Когда структура проекта изменяется, Вам, вероятно, придется изменить процесс сборки, который повредит более старые сборки от той точки на.
В дополнение к двоичным файлам, поскольку все остальные упомянули, что я рекомендовал бы настроить сервер символов и исходный сервер и удостовериться, что Вы получаете корректную информацию и в тех. Это поможет в отладке чрезвычайно.
Мы сохраняем двоичные файлы, разделенные и неразделенные (таким образом, у нас есть точно тот же двоичный файл, однажды с и однажды без отладочных символов). Далее мы создаем все дважды, однажды с включенным выводом отладки и однажды без (снова, разделенный и неразделенный, таким образом, каждый результат сборки в 4 двоичных файлах). Сборка хранится к каталогу согласно числу пересмотра SVN. Тем путем мы можем всегда сохранять источник от репозитория SVN путем простой проверки этого самого пересмотра (тот способ, которым источник заархивирован также).
Удивительный я узнал о недавно: Если Вы будете в среде, которая могла бы контролироваться, то Вы захотите сохранить весь вывод своей сборки, вывод сценария, выход компилятора, и т.д.
Это - единственный способ, которым можно проверить параметры компилятора, шаги сборки, и т.д.
Кроме того, сколько времени сохранить их для, и где сохранить их?
Сохраните их, пока Вы не знаете, что сборка не будет идти в производство, iow, пока у Вас есть скомпилированные биты вокруг.
Одно логическое место для сохранения их является системой SCM. Другая опция состоит в том, чтобы использовать инструмент, который автоматически сохранит их для Вас, как AnthillPro и его род.
Я сохранил бы Ваши созданные двоичные файлы для точно, пока у них есть шанс войти в производство или использоваться некоторой другой командой (как группа QA). После того как что-то оставило производство, что Вы делаете с ним, может варьироваться много. Для большого количества команд они сохранят просто свою новую предшествующую сборку вокруг (для отката) и иначе отбросят их сборки.
У других есть нормативные требования для хранения чего-либо, что вошло в производство вокруг столько, сколько семь лет (банки). Если бы Вы - производственная компания, я имел бы в наличии любой двоичный файл, который, возможно, установил клиент в случае, если парень технической поддержки хочет установить ту же версию.
Мы делаем что-то близко к "встроенной" разработке здесь, и я могу сказать Вам, что мы сохраняем:
- число пересмотра SVN и метка времени, а также машина, на которой это было основано и кого (также врезался в двоичные файлы сборки),
- журнал полной сборки, показывая, было ли это полной/возрастающей сборкой, какое-либо интересное (STDERR), произвел произведенные инструменты выпекания данных, список скомпилированных файлов и любые предупреждения компилятора (это сжимается очень хорошо, будучи текстом),
- фактические двоичные файлы (для где угодно от 1-8 конфигураций сборки)
- файлы, произведенные как побочный эффект соединения: командный файл компоновщика, таблица адресов и своего рода "явный" файл, указывающий, что врезались в заключительные двоичные файлы (CRC и размер для каждого), а также база данных отладки (.pdb эквивалентный)
Мы также почта результат выполнения некоторых инструментов по файлам "побочного эффекта" заинтересованным пользователям. Мы на самом деле не архивируем их, так как мы можем воспроизвести их позже, но эти доклады включают в себя:
- общее количество и дельта размера файловой системы, сломанного типом файла и/или каталогом
- общее количество и дельта размеров секции кода (.text, .data, .rodata, .bss, .sinit, и т.д.)
Когда у нас есть модульные тесты или функциональные испытания (например, испытания с помощью дыма) выполнение, те результаты обнаруживаются в журнале сборки.
Мы ничего еще не вывели - данный, наши целевые сборки обычно заканчиваются в ~16 или 32 мебибайт за конфигурацию, и они довольно сжимаемы.
Мы действительно имеем в наличии несжатые копии двоичных файлов в течение 1 недели для простоты доступа; после этого мы сохраняем только слегка сжатую версию. Об один раз в месяц у нас есть сценарий, который извлекает каждый .zip, который процесс сборки производит и 7 zip целый месяц выводов сборки вместе (который использует в своих интересах только наличие небольших различий на сборку).
Средний день мог бы иметь дюжину или две сборки на проект... buildserver просыпается о каждых 5 минутах для проверки на соответствующие различия и сборки. Полный.7z на большом очень активном проекте в течение одного месяца мог бы быть 7-10GiB, но это, конечно, доступно.
По большей части мы смогли диагностировать все этот путь. Иногда существует отклонение на buildsystem, и файл не является на самом деле пересмотром, который это, как предполагается, - когда сборка происходит, но обычно существует достаточно доказательства этого в журналах. Иногда мы должны откопать инструмент, который понимает формат базы данных отладки, и подайте его несколько адресов для диагностирования катастрофического отказа (нам встроили автоматический stackdumps в продукт). Но обычно вся необходимая информация там.
Мы еще не должны были взламывать архивы.7z, для упоминания. Но у нас есть информация там, и у меня есть некоторые интересные идеи о том, как взорвать биты полезных данных из нее.
Сохранить как под контролем в к управлению исходным кодом или только на диске? Ничего не сохраните к управлению исходным кодом. Все полученные файлы должны быть видимы в файловой системе и доступны разработчикам. Не делайте двоичных файлов регистрации, код, сгенерированный от XML-файлов, дайджесты сообщения и т.д. Отдельный упаковочный шаг сделает эти конечные продукты доступными. Поскольку у Вас есть число изменения, можно всегда воспроизводить сборку, если необходимое принятие, конечно, все, необходимо сделать сборку, находится полностью в дереве и доступно всем сборкам путем синхронизации.
Save what can't be reproduced easily. I work on FPGAs where only the FPGA team have the tools and some cores (libraries) of the design are licensed to compile on only one machine. So we save the output bitstreams. But try to check them over one another rather than with a date/time/version stamp.