Одна из методик, изложенных в « Непрерывной доставке» Jez Humble, заключается в том, что вы должны собрать один пакет, а затем выпустить его для каждой среды, в которой вы развертываете, так что развертывание и артефакты сами по себе несколько раз тестировались перед отправкой в производство.
Я полностью поддерживаю эту идею.
С другой стороны, сборки в режиме отладки, которые дают вам трассировки стека с номерами строк, невероятно полезны в тестовых средах, как и возможность удаленной отладки. Но вы хотите отправить сборку релиза в производство.
Итак, для людей, следующих первому принципу, в какой момент вы переключаетесь с отладочных версий на выпускные?
Прежде чем приступить к первому развертыванию в тестовой среде, стоит оценить стоимость потери режима отладки, чтобы убедиться, что вы тестируете фактического кандидата на выпуск на ранней стадии? Или вы снова строите что-то в процессе продвижения, полагая, что будете доверять процессу сборки, а не программному обеспечению? Или вы просто привинчиваете все это и внедряете отладочные версии в производство?
Примечание: я знаю, что это не относится к интерпретируемым языкам, потому что обычно вы можете переключать конфигурацию вместо того, чтобы делать это во время сборки.
источник
Ответы:
Мы переключаемся рано, когда исходный код получил номер версии и был помещен в очередь сборки Debian. Однако нам повезло в создании научного программного обеспечения с четко определенными входами и выходами и небольшим взаимодействием с системой, поэтому стоимость воспроизведения ситуации с ошибками довольно низкая.
Это также мой общий ответ: точка изменения сборок зависит в основном от затрат на воспроизведение ошибок. Если они очень высокие, я бы даже отправлял отладочные сборки для тестирования клиентов. Хотя это несет в себе риск сбоев сборки для сборки производства, это может быть дешевле, чем потратить недели на воспроизведение тестового примера.
источник
Как только мы переходим в QA, мы переключаемся на выпуск сборок. Но когда мы собираем релизную сборку, наш процесс сборки также создает отладочную версию DLL. Это позволяет нам быстро перенести отладочные библиотеки в среду QA и получить дополнительную информацию, если это необходимо.
Обе версии и отладочные версии dll сохраняются в течение нескольких лет.
источник
В нашей среде код развертывается на многих сайтах. И, следовательно, должен быть разный контекст, применяемый к каждому экземпляру развертывания. Обычно мы разворачиваем его в ключевых «менее рискованных» местах и видим опыт.
Это развертывание все еще находится в производстве, следовательно, это не режим «отладки». Но это также предполагает, что тестирование выполнено хорошо.
Конечно, при отключенном режиме отладки быстрая отладка кода (на сайте) может быть затруднена. Но если выпуск не удался, производство переключается обратно на резервный выпуск.
Тем не менее, мы пытаемся сохранить или создать идентичное окружение, которое может воспроизвести такое окружение для повторного тестирования. (Я знаю, что это не всегда тривиально), но все, что нам иногда нужно, это воспроизводить транзакции / входные данные.
Дело в том, сколько бы ни было соблазнов, выпуск режима отладки не должен быть в производстве. Хотя я не скажу, что это правило.
Другое дело, что релиз по-прежнему называется пробным, пока он не установит (запустив в течение значительного времени) другие помещения, пока его не принимают.
Есть несколько других методов, которые гарантируют, что сам процесс сборки не будет полностью неисправным. Смотрите это: простые способы улучшить качество релизов в среде RAD
источник
У нас есть машины разработчика, настроенные для сборки отладочных сборок. Но как только код коммитов разработчика, пакет развертывания создается в нашей среде непрерывной интеграции (TeamCity), и он создается для выпуска. Поэтому всякий раз, когда мы решаем выполнить развертывание в QA, мы берем последний пакет развертывания с сервера CI и выгружаем его, поэтому он всегда выпускается, если он не находится на компьютере разработчика.
Кстати, для некоторых языков, даже при сборке для выпуска, вы все равно можете создавать символы отладки. Например, в .NET есть параметр «только для pdb», который позволяет оптимизировать, но по-прежнему создает файлы отладки. Очевидно, что отладка в версии выпуска сложнее, так как она не эквивалентна строке за строкой, но все же может быть полезна в крайнем случае.
источник