Единый тестовый сервер и SVN для веб-разработки

Question

Меня немного смущает правильное использование svn в случае использования одного тестового сервера для веб-разработки.

Мы стараемся избегать создания локального тестового сервера для каждого разработчика, поскольку система довольносложный и, следовательно, сложный в настройке и тяжелый для запуска.Таким образом, мы подумываем об использовании одного тестового сервера, где все разработчики (на самом деле только несколько одновременно) могут протестировать свои изменения.

Предполагая, что мы используем SVN для управления версиями, как нам действовать??Мы рассмотрели эти варианты:

• Все модификации проходят через SVN.Когда я хочу изменить файл, я изменяю локальную копию, и они фиксируют.Однако, поскольку я не могу выполнять какие-либо локальные тесты, у нас часто будет неработающий код и отмененные изменения в SVN.Насколько это плохо?

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

• Модификации выполняются в нескольких «локальных» копияхкод на сервере, и мы можем переключаться с одной копии на другую или запускать их одновременно для проведения тестирования.Для этого потребуется специальная конфигурация и много места на сервере.

Есть ли лучший вариант, который нам не хватает, или какой вариант наименее худший?Спасибо.

Answer 1

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

Answer 2

Насколько сложна среда, в которой изменения не могут быть протестированы локально? Если среда слишком велика и сложна для работы на рабочей станции разработчика, вы действительно хотите заняться макетом и модульным тестированием. У вас действительно есть две противоборствующие силы:

• Каждое изменение кода настолько интегрировано, что для проверки требуется полный сквозной тест.
• Разработчики не могут иметь сквозную среду.

Модульное тестирование (которое, конечно, требует написания / поддержки кода в дискретных тестируемых блоках), и имитация не является окончательным решением этой проблемы, но это поможет. Много.

Если вы выберете первый вариант, критически важны непрерывная интеграция и непрерывное развертывание в вашей тестовой среде. Ошибки должны быть идентифицированы немедленно , иначе ваши разработчики будут создавать ошибки при ошибках, и вся система быстро запутается.

Ваш второй вариант - нет. Если у вас есть неконтролируемый шаг между разработчиками и системой контроля версий, тогда вы полностью подрываете «контрольную» часть системы контроля версий. Можно также просто хранить код на общем ресурсе FTP.

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

Answer 3

Если бы не было проблем с пространством, я бы предложил использовать несколько копий SVN на одном сервере.У вас должен быть основной каталог, который вы svn update получаете, когда достигаете вехи, а затем несколько папок разработчика, которые являются вашими рабочими копиями.

Если пространство слишком много, у вас действительно нет другого выбора, кромеработать непосредственно с живым кодом или запускать его на персональных компьютерах.

Answer 4

Ветви могут быть полезны для поиска (http://svnbook.red -bean.com / ru / 1.1 / ch04.html ). Вы могли бы создать ветку для каждого разработчика, и они могли бы выдвинуть к стволу, когда они определяют, что их изменения не вредны.

Answer 5

Поскольку ваша система достаточно сложна в настройке, я бы дал каждому разработчику «песочницу» на центральном тестовом сервере, еще +1 для «стабильной», с которой они все объединятся после завершения.

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

Answer 6

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

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

Как примечание: может, вам здесь помогут виртуальные машины?