установка среды разработки проекта

Из Вашей учетной записи StackOverflow я собираюсь предполагать, что Вы - магазин Python.

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

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

Возьмите регулярные резервные копии этого сервера.
Используйте rsnapshot для взятия происходящих снимков данных. Возможно, почасовые снимки, ночное удаленное резервное копирование (Amazon S3 является большим соотношением цены и качества для этого!). Сделайте еженедельное резервное копирование на офлайновый носитель (лента, DVD, внешний жесткий диск) и поверните их ежемесячно.

Не забывайте тестировать восстановление!

Если у Вас есть 2 сервера разработки, необходимо идеально создать их тождественно с чем-то как предварительное семя человечности, или RHEL/Centos Запускают. Затем создайте серверные среды с марионеткой. Это сэкономит Вам время в конечном счете, особенно когда Вы приедете в масштаб.

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

Выработайте привычку записи модульных тестов рано. Даже если это только для базовых модулей Ваших проектов. Интегрируйте их с бегуном Unit Test, скажите PyUnit. Заставьте анализатор покрытия кода помогать Вам разработать эффективные тесты. Интегрируйте свою тестовую среду с Вашим Управлением исходным кодом с чем-то как Гудзон или Buildbot. Теперь Вы можете быть уведомлены, с которым разработчик фиксировал код, который повредил сборку.

У Вас должен быть отдельный сервер тестирования, который зеркально отражает Вашу продуктивную среду. Идеально у Вас есть 2 из них, один в офисе для локального тестирования, и один в том же центре обработки данных, где Ваши общедоступные серверы.

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

После того как у Вас есть несколько установок серверов и работы, необходимо рассмотреть некоторую централизованную систему резервного копирования. Скопируйте все важные биты своих серверов к центральному расположению и затем копируйте те данные в отдельный сервер. Например, один в офисе, один в центре обработки данных.
А также еженедельные удаленные/в режиме офлайн резервные копии и Тесты аварийного восстановления.

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

Вам действительно нужно это много серверов для "нескольких приложений/проектов"? Это кажется waay излишеством мне.
Для предоставления небольшой перспективы я работаю на компанию приблизительно с 130 сотрудниками, и я забочусь о 11 серверах.

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