Продвижение кода: Build или Binary?

Question

Учитывая довольно базовую древовидную структуру, подобную следующей:

trunk ------- 
   QA  |--------
     Stage |-------
        Prod  |------

И среда, которая отражает это (серверы Dev, QA, Staging и Production) - как вы все управляете автоматизированным или ручным продвижением кода? Используете ли вы CI-сервер для создания и продвижения на всех этапах? CI в Dev, чтобы построить двоичные файлы, которые используются во всем? Какой-нибудь другой гибрид?

Я разбирался с парой мыслей. Во-первых, каждое продвижение будет получать последнюю версию, собирать, а затем отправлять выходные данные сборки на правильный сервер. Вторым является то, что в какой-то момент - QA или Staging - двоичные файлы, которые были продвинуты, будут точно такими же, которые копируются на другие этапы. Третий - это сохранение вторичного дерева исходных текстов для развернутых двоичных файлов, которые будут автоматически перемещаться по стопам при продвижении кода. Любые другие мысли или идеи?

Answer 1

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

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

Answer 2

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