Раздельные сборки 'debug' и 'release'?

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

Сначала он здесь, в этом магазине, и я здесь уже 18 месяцев.

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

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

Ответ 4

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

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

Часть, где вы поступили не так, это утверждение:

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

По моему мнению, в этом обсуждении отсутствует очень важный момент:

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

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

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

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

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

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

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

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

Ответ 14

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

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

Ответ 15

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

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

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

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

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

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

Ответ 16

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

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

Ответ 17

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

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

Ответ 18

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

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

Ответ 19

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

цитата:

Мнение: никогда не бывает разных код между "debug" и "release" строит

Основная причина заключается в том, что релиз код почти никогда не тестируется. Лучше иметь тот же код, что и в тесте как в дикой природе.