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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

Наша политика заключается в том, чтобы разработчики работали над отладочными сборками, но ВСЕ остальные (QA, BAs, отдел продаж и т.д.) запускали релизную версию.Вчера мне пришлось исправить ошибку, которая появилась только в выпуске build it, было очевидно, что происходит просто потому, что она появилась только в выпуске

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

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

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

Answer 4

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

Уммм...для меня это звучит так, как будто вы делаете отладочную сборку...верно?

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

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

Answer 10

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

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

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

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

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

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

Answer 11

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

Answer 12

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

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

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

Answer 13

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

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

Answer 14

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

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

Answer 15

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

Цитата:

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

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

Answer 16

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

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

2) Ни в одной сборке не будут использоваться специальные макросы ПРЕПРОЦЕССОРА, изменяющие их выполнение.

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

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

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

Answer 17

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

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

Answer 18

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

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

Answer 19

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

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