Раздельные сборки для отладки и выпуска?

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

Хотя, по крайней мере, в одном случае мы выпустили что-то, что еще содержало отладочный код. Единственным последствием было то, что он работал немного медленнее, а файлы журналов были чертовски большими.

Наша политика заключается в том, чтобы разработчики работали над сборками отладки, но ВСЕ остальные (QA, BAs, продажи и т. д.) Запускают версию выпуска. Вчера мне пришлось исправить ошибку, которая обнаружилась только в сборке релиза, было очевидно, что происходит, просто ПОТОМУ ЧТО она появилась только в выпуске.

Он первый в этом магазине, и я здесь около 18 месяцев.

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

Я не вижу причин, почему бы не использовать и то, и другое, если единственная разница между конфигурациями - символы отладки и оптимизации.

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

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

здесь мы разрабатываем в режиме отладки и проводим все модульное тестирование в режиме выпуска. мы - небольшой магазин с несколькими (до 12) приложениями для поддержки, начиная от Classic ASP, ASP.Net, VB.Net и C#. У нас также есть специальный человек, который занимается всем тестированием, отлаженные проблемы возвращаются разработчикам.

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

Но отладочные сборки должны быть предназначены только для разработки, а не для тестирования. Вы тестируете только релизные сборки. И вы не используете разработчиков для тестирования этих сборок, вы используете тестировщиков.

Это простая политика, которая дает лучшее из обоих миров, ИМО.

Редактировать: В ответ на комментарий, я думаю, очевидно, что отладочные и выпускающие сборки (могут) генерировать разный код. Подумайте: «-DDEBUG» против «-DNDEBUG», «#if defined (DEBUG)» и т. д.

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

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

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

В моей компании есть и отладка, и выпуск. - Разработчики используют отладочную версию для правильного поиска и исправления ошибок. - Мы используем TDD, поэтому у нас есть большой набор тестов, который мы запускаем на нашем сервере, который тестирует как отладочную, так и выпускную конфигурации сборки, а также 64/32 сборки, которые у нас есть.

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

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

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

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

Это компромисс. Учитывая, что циклы ЦП дешевы и дешевеют, в то время как человеческие циклы остаются дорогими, имеет большой смысл поддерживать только одну версию большой сложной программы - отладочную (двускатную) версию.

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

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

К тому же отладка релизной сборки не так уж и сложна. И если вы получите аварийный дамп, вы все равно должны это сделать.

Согласно моему ответу в связанной теме, мы также используем ту же сборку для отладки и выпуска по очень похожим причинам. Прирост производительности от 10% до 20% от оптимизатора, как правило, очень незначителен по сравнению с оптимизацией вручную на уровне алгоритма. Одна сборка устраняет множество потенциальных ошибок. Конкретно;

• Неинициализированные переменные и небольшие переполнения буфера могут привести к очень разным результатам в отладочных и оптимизированных сборках выпуска.

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

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

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

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

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

Я всегда подписывался на подход «Отправляйте то, что вы отлаживаете, чтобы вы могли отлаживать то, что отправляете», по всем причинам, которые вы указываете в своем вопросе.

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

Положительный момент при использовании отладочных версий:

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

so you need to build a release which you can if necessary debug ... this may mean enabling debug symbols, and disabling some optimizations, even in the 'release' build.

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

Часть, в которой вы ошиблись, - это следующее утверждение:

I think it's better to release the version of the software which your developers actually tested

Разработчики не тестируют код. Проверяет тестовый код.

Модульные тесты должны тестировать конфигурации сборки ВСЕ. Не заставляйте своих разработчиков работать с одной рукой, связанной за спиной - позвольте им использовать все инструменты отладки, которые у них есть. Сборка отладки - одна из них.

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

Разработчики работают с отладочными сборками, QA и все остальные используют версию выпуска, которую мы называем «производственной». Основное преимущество этого заключается в том, что в отладочную сборку мы можем добавить много дополнительного кода и утверждений. Некоторые объекты содержат дополнительную информацию, которая не используется, кроме как при просмотре кода в отладчике. Некоторые объекты периодически проверяют себя, чтобы убедиться, что вся информация о состоянии согласована. Эти вещи делают отладочную версию намного медленнее, но они помогли нам найти бесконечное количество ошибок, которые было бы чертовски трудно найти в производственной сборке.

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

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

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

Смотрите это Какое ваше самое противоречивое мнение о программировании?

Цитировать:

Opinion: Never ever have different code between "debug" and "release" builds

The main reason being that release code almost never gets tested. Better to have the same code running in test as it is in the wild.

На мой взгляд, в этом обсуждении упущен очень важный момент:

Это действительно зависит от того, что это за проект!

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

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

Хотя нативный проект C++ и веб-приложение PHP, очевидно, не являются всеми видами проектов, я надеюсь, что моя точка зрения дошла до меня.

P.S .: При разработке для C# вы сталкиваетесь с пограничным случаем, поскольку, хотя использование отладочной сборки отключает оптимизацию компилятора, по моему опыту вы не столкнетесь почти с такими различиями, как с C++

Удаляя «цель отладки», вы заставляете разработчиков выполнять отладку окончательной версии программного обеспечения. На практике это, вероятно, означает две вещи:

1) "Релизные сборки" будут иметь отключенную оптимизацию (сторонние разработчики не могут использовать отладчик)

2) Никакие сборки не будут иметь специальных макросов PREPROCESSOR, изменяющих их выполнение.

Так что на самом деле вы будете объединять конфигурации выпуска и отладки, а не устранять только режим «отладки».

Я лично сделал это с разработкой для iOS без каких-либо негативных последствий. Время, потраченное на наш написанный код, составляет менее 1% от того, что действительно происходит, поэтому оптимизации не внесли значительного вклада. В этом случае они действительно, похоже, вызвали увеличение количества ошибок, но даже если они этого не сделали, идея тестирования одним способом, а затем предоставления QA с другим кодом представляет собой еще один фактор, который следует учитывать при проблемах.

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