skyANAАлексей К, вообще-то ТС спросил о том, как лучше, а не как проще.

И если ты писал batch файл, что выкладывает релиз в ветку tags (svn) и публикует на ftp, то может поделишься скриптом?

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

Сейчас переходим на тфс и будем смотреть что там с ALM и нужен ли нам еще свой лисапед.

skyANAgpuЧисло систем перевалило за 10.
А что такое число систем? Это сколько веток в разработке? Сколько различных сервисов в рамках каждой системы? Сколько тестовых сред?
1. текущая ветка
процессы>
1. разработка
2. сборка и публикация каждый час
3. Юнит/тесты ежедневно
4. Code Coverage сборка по выходным

2. стабильная ветка
процессы:
1. bug-fixing
2. сборка и публикация ежедневно
3. QA
4. сборка и публикация ревью раз в спринт
5. подготовка продуктов для сетапа.

3. Ветка хотфиксов для предыдущего релиза
процессы:
1. bug-fixing
2. сборка и публикация по требованию
3. QA
4. подготовка продуктов для сетапа.

4. Ветка специального релиза для вип заказчика для разработчиков 2 шт.
процессы:
1. разработка
2. сборка и публикация по требованию
3. QA
4. подготовка продуктов для сетапа.

5. Ветка специального релиза для вип заказчика для заказчика 2 шт.
процессы:
1. сборка и публикация по из ветки разрабов в Citrix
2. QA заказчика

Ну и все умножить на 2 потому как для двух продуктов.

насчет сервисов не очень понял контекст.
Своих доморощенных 2 в одном продукте и 2 в другом.

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