Здравствуйте, Aikin, Вы писали:

A>Но "всплыл" тестовый сервер на котором заказчику показываются сделанные нами изменения, одобряются (или нет ), тестируются, ... Который как-то выпал из моего внимания.
A>Возник вопрос: какой код на него деплоить?
A>Понятно, что не транк, так как код который неодобрен в транк попасть не должен.

Это снова я

Вот смотри. Заказчик уже юзает какую-то задеплоенную версию. Задеплоена она у тебя с транка. Тебе надо показать какой-то функционал, который будет одновременно иметь все фичи, которые заказчик уже видит + что-то новое, не обязательно стабильное.
Задача сводится к тому, чтобы показать транк + какую-то дельту поверх него. Соответственно, для деплоймента отращивается отдельный бранч от транка, туда мержатся все изменения с фичей — и всё это деплоится на сервер. Бранч можно отращивать каждый раз новый, чтобы иметь возможность при необходимости "переключать" тестовый сервер с одной демонстрации на другую.
Твой варинт не подходит тем, чтоу тебя на тестовом бранче находится код, который в общем случае не будет up-to-date с кодом на транке, т.е. заказчик может не видеть каких-то фич, задеплоенных на рабочий сервер. Отращивание изменений для тестового сервера каждый раз от транка решит эту проблему.

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