Subversion на сервере общей разработки

Question

Я подумываю об использовании контроля версий на моей работе. В идеале я хотел использовать Subversion, так как теперь это инструмент выбора. Однако, похоже, я столкнулся с кирпичной стеной, поскольку для всех наших разработчиков не так просто работать в локальной среде. Мы делаем веб-разработку с Coldfusion и используем общий сервер разработки. Изменения, внесенные в файлы, могут быть быстро обновлены в браузере.

Наша компания обслуживает более 100 сайтов, и наш сервер разработки отражает все эти сайты на производстве. Нам часто приходится быстро настраивать 1 из этих 100, протестировать их и быстро загрузить в производство. Если бы нам пришлось загружать данный сайт локально, настройте его на нашем локальном веб-сервере, эти небольшие изменения станут более трудоемкими задачами. Кроме того, часто копирайтеры и менее технические люди захотят перейти на html-страницу и изменить копию. Это прямо в нашей текущей настройке общего сервера.

Давным-давно мы использовали источник управления NGSource, когда вы проверили проект в репозитории, он изменил права доступа к файлу только для чтения. Мы проверили бы файл на общий dev-сервер и изменили бы разрешение на чтение и запись. Мы все проверили бы репозиторий, чтобы убедиться, что кто-то не работает над файлом, над которым мы думали работать. Это сработало хорошо и объяснимо для копирайтеров. Проблема заключалась в том, что клиент NGSource был медленным, и, насколько мне известно, они могут оказаться вне бизнеса.

Итак, есть способ реализовать это изменение прав доступа к файлам при регистрации и проверке с помощью Subversion? Если нет, есть ли лучшее решение с открытым исходным кодом? Разве так плохо развиваться в общей среде и пропустить развитие на местном уровне?

Answer 1

Вы можете использовать 'svn lock' [1], чтобы никто не мог редактировать файл, в котором вы сейчас работаете.

[1] http://svnbook.red-bean.com/en/1.2/svn.ref.svn.c.lock.html

Answer 2

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

Answer 3

Я менеджер по управлению версиями для компании-разработчика, которая производит и поддерживает веб-приложения и веб-сайты, хотя и не так много, как ваша. Я понимаю сложность в том, что 100+ сайтов работают правильно (если вообще) на n локальных ящиках разработчика/копирайтера и считаю, что это законная причина не проверять локально для каждого.

о процессе

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

1. Файловая система накладные расходы: SVN хранит что-то эквивалентное удвоенному информации в извлеченным каталоге. Вот почему вы можете развернуть и вернуться без подключения к серверу.
2. Безопасность: Наличие дополнительных .svn-каталогов - это еще один вектор атаки. Это можно компенсировать, но выгодно ли перевесить стоимость? Для нас нет.

Вместо этого мы используем такой инструмент, как RepliWEb, чтобы скопировать кодовую базу с этапа на производство.

О Вашей Возможный процесс

Будет ли это работать, если у вас один промежуточной среды со всеми 100+ сайтов, настроенных, работает, и в системе управления версиями? Это среда, которую разработчики и правообладатели будут использовать для внесения изменений, а затем они будут совершать. Когда изменения были признаны хорошими, такой инструмент, как RepliWeb, мог передать версию в Staging (без каталогов .svn) в Production. Если накладные расходы на файловую систему и риски безопасности незначительны для вашей компании, то RepliWeb будет заменен простым выполнением чистой проверки сайта в Production (убедитесь, что удалены любые предыдущие артефакты).

Надеюсь, это поможет.

Спасибо,
Закарей

Answer 4

Я могу представить себе вашу боль, но вы не сказали нам, что случилось с вашей текущей процедурой;). В конце концов, «не исправить, если он не сломан». И только потому, что каждый использует SVN/GIT и т. Д., Нет гаруанти, что это для вас.

У нас есть аналогичные требования, но, к счастью, все еще удается иметь локальные проверки и локальные веб-серверы, которые некоторые люди используют перед совершением. Это рекомендуемый способ. Существует общая среда разработки для других, которые монтируют через samba или nfs. Но все-таки у всех есть свое СОБСТВЕННОЕ рабочее пространство, припаркованное на нем. Люди, которые работают над внешним интерфейсом и проверяют некритические изменения, используют веб-интерфейс для вызова обновлений svn в основной системе промежуточного размещения в центре обработки данных или в целевой (клиентской) системе. Его усмотрение и их вина, когда что-то ломается. Конечно, этапы могут быть полностью автоматизированы с помощью svn hooks.

Наши результаты приемлемы до сих пор.

Если вы считаете, что накладные расходы для личных рабочих пространств слишком высоки для вашего бизнес-кейса, то ни один источник-контроль, который, как я знаю, не поможет вам. Вы все еще можете заблокировать файлы в svn, чтобы люди не могли проверять изменения до тех пор, пока они не разблокированы, но это так очень 1990 ...

В конце концов, каковы цели контроля источника? Некоторые я могу думать:

• развитие Paralell со многими людьми
• Выделение стабильного и нестабильного кода
• Прозрачность и откатить-способность

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

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

Если возможно, вам нужно сначала выйти из привычки «мы редактируем на сервере», а затем подумать об управлении источником.Наоборот будет сложно;)

C

Answer 5

В нашей компании мы в очень похожую ситуацию - больше проектов, чем разработчики. Таким образом, все проекты находятся на dev-сервере, где разработчики могут легко работать над ними. Обычно только один разработчик работает в одном проекте в данный момент времени. Но разработчики приходят и уходят, каникулы, палки и т. Д., Поэтому нам нужно быстро переключать проекты. Но в идеале с контролем версий, чтобы избавиться от страха изменить что-то, и все хорошие вещи, которые приносит верность.

Централизованные элементы управления версиями, такие как svn, csv, p4 и другие, не подходят для такого решения. Можно использовать только распределенное управление версиями.

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

Но поскольку для разработчиков нет личного пространства, мы не сможем использовать все аспекты управления версиями. Разработчикам необходимо будет указать свое имя int checkin note. Но по крайней мере что-то, чем ничего.

Я сделал некоторые исследования, вот некоторые интересные ссылки, которые я нашел:

How to use version control on a remote development server?

Version control has me stumped

https://www.mercurial-scm.org/wiki/TortoiseHg

http://git-scm.com/