Отдельные сборки 'debug' и 'release'?

Question

Я думаю, что лучше выпустить версию программного обеспечения, которую на самом деле тестировали ваши разработчики; Поэтому я стремлюсь удалить цель 'debug' из проекта / make-файла, чтобы можно было собрать только одну версию (и протестировать, и отладить, и выпустить).

По той же причине я не использую «утверждения» (см. Также Всегда ли утверждения плохие? ...).

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

Кто-то еще сказал, что "это такая плохая идея"; это политика, которую я выработал несколько лет назад, будучи сожженной:

• Некоторые разработчики тестируют свои отладочные, но не релизные версии
• Некоторые ошибки в написании некоторых разработчиков, которые появляются только в релизной версии
• Компания выпускает версию релиза после неадекватного тестирования (это когда-либо полностью адекватно?)
• Вызывается для отладки версии выпуска

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

Какова ваша политика?

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

Наша политика заключается в том, чтобы разработчики работали над сборками Debug, но КАЖДЫЙ (QA, BA, продажи и т. Д.) Запускает релизную версию. Вчера мне пришлось исправить ошибку, которая обнаруживалась только в релизной сборке, было очевидно, что происходило просто, ПОТОМУ ЧТО она появилась только в релизе

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

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

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

С положительной стороны, используя отладочные версии:

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

Answer 7

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

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

Answer 8

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

Answer 9

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

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

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

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

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

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

Answer 10

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

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