Я пытаюсь спланировать, как 5 разработчиков смогут использовать Visual Studio 2005/2008 для совместной разработки веб-приложения ASP.NET на веб-сервере разработки для базы данных Oracle 8i (скоро будет 10g).
Разработчики находятся либо в локальной сети, либо через vpn (не очень быстрое соединение),
Я оценил последнюю версию Visual SourceSafe, но столкнулся со следующими проблемами:
1) Мы не можем использовать децентрализованную разработку, потому что мы не можем реплицировать базу данных оракула разработки на все компьютеры разработчиков. Кроме того, vpn слишком медленный, чтобы позволить своим локальным экземплярам приложения подключаться к серверу базы данных.
2) Поскольку исходный код VSS не находится в файловой системе, единственный способ отладить его - это создать приложение и запустить отладчик, что может делать только один разработчик одновременно на централизованном сервере разработки. Это неприемлемо. Мы пробовали использовать теневые папки, чтобы каждый раз при проверке файла он публиковался в экземпляре приложения на сервере разработки, но это не удалось для удаленных разработчиков на vpn.
3) Поскольку разработчики создают много веб-кода, по соображениям производительности важно, чтобы при СОХРАНЕНИИ файла они могли сразу увидеть изменения, работающие на сервере разработки.
4) Нет простого способа реализовать контролируемый процесс отправки файлов на рабочий сервер.
Есть ли предложения по решению системы управления версиями, которое будет работать при этих ограничениях?
Обновлять: Я полагаю, поскольку разработка принудительно ведется на сервере, нам нужно использовать модель «Lock and Check In». Итак, какое решение для управления версиями лучше всего подойдет для сценариев «Блокировка и возврат»?
Обновлять: Поддерживает ли Visual SVN централизованную разработку на сервере разработки? То есть разработчик может сразу увидеть свое обновление на сервере разработки после сохранения в VS?
Я использовал Subversion и TortoiseSVN и остался очень доволен.
Если вы можете потратить деньги, то Team Foundation Server лучше всего работает в среде разработки Visual Studio.
И, судя по личному опыту, он прекрасно работает через VPN-соединения. И, конечно, вы можете использовать автоматические сборки.
Я бы сказал SVN по цене (бесплатно), Волей-неволей по простоте интеграции.
Вы, несомненно, слышите о GIT и CVS, и есть веские причины взглянуть на них.
Visual Source Safe - порождение сатаны.
Посмотрите на Subversion и Visual SVN (с Tortise SVN). Конечно, Visual SVN стоит немного - 49 долларов за рабочее место, но это отличный инструмент. У нас есть команда разработчиков из 6 программистов, и это было для нас большим благом.
Лучшее решение, которое я нашел до сих пор. И я посмотрел совсем немного.
Интересно - похоже, вы работаете над проектом веб-сайта на сервере, и все работают с одними и теми же физическими файлами. Я согласен с тем, что SVN намного превосходит VSS и с ним действительно хорошо работать, но, по моему опыту, он действительно ориентирован на разработчиков, работающих над копией кода локально.
VSS - это тип управления версиями «заблокировать и вернуть», в то время как SVN, TFS и большинство других - «редактировать и объединять» - все разработчики получают копии источника, редактируют файлы по мере необходимости, а затем объединяют свои изменения в исходный контроль, и если кто-то другой редактировал файл тем временем, они объединяют изменения вместе.
С точки зрения базы данных, я предполагаю, что вы проверяете свои сценарии базы данных, а затем имеете некоторую автоматическую упаковку сборки и запускаете их (или, может быть, просто разработчик или администратор базы данных запускает их вручную время от времени). В этом случае имеет смысл иметь у разработчиков локальную копию скриптов, которую они могут редактировать и объединять с помощью SVN или TFS.
Однако для команды, работающей над общей копией исходного кода на сервере разработки, вы можете столкнуться с проблемами при использовании редактирования и слияния - модель управления версиями «заблокировать и вернуть» может работать лучше для вас. Только не VSS с точки зрения коррупции и стабильности.
Правильный. «Заблокировать и зарегистрировать» - единственный выход для нас, поскольку база данных Oracle доступна только с сервера разработки. Какие-либо решения для управления версиями, специализирующиеся на «Блокировке и возвращении»?
Точка 1 связана с проблемой схемы (или данных) вашей базы данных?
- We can't use decentralized development because we can't replicate a development oracle database to all developers computers.
Если нет, я настоятельно рекомендую, чтобы каждый разработчик имел свою собственную среду (Visual Studio, Oracle ...) и использовал ваш сервер разработка для целей интеграции. Может быть, вы могли бы просто дать им подмножество данных или, может быть, только сценарии схемы.
Мне очень жаль, если вы уже представляли себе эти решения и сочли их непригодными для вашей ситуации, но я действительно почувствовал желание выразить их на всякий случай ...
Вы не думаете, что TFS - это перебор для команды из пяти разработчиков?