Лучший способ использования svn для веб-разработки

Ответ 1

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

Вам следует рассмотреть возможность использования развертывания script (Ant, Rake, Perl) для автоматического SCP/FTP ваших изменений с вашей машины разработки вместо проверки из Subversion на сервере.

Вы должны обновить все, что вам нужно, чтобы заново создать свой сайт и что-то важное для сайта - это будет изображение сайта, CSS, JavaScript

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

Ответ 2

• Помните, что Subversion предназначена не только для резервного копирования файлов, но и для записи моментального снимка среды в разные моменты времени, поэтому при необходимости вы можете вернуться к предыдущему состоянию. Поэтому, если вам это нужно, и он когда-либо изменяется, то он должен быть в Subversion (если только он не был создан из других файлов в Subversion).

• Для обычного программного проекта он обычно имеет/trunk/и/релизы/каталоги. Для веб-проектов мне нравится иметь директории/devel/и a/live/с каталогом/docroot/под каждым, содержащим содержимое веб-сервера DocumentRoot. Все файлы, не предназначенные для публикации (рабочие файлы, исходный код, программы и т.д.), Выходят за пределы /docroot/.

• Чтобы опубликовать работу с Subversion на веб-сервере, используйте команду "svn export http://url/live/docroot/path/to/web/docroot", который сбрасывает все файлы (без каталогов .svn).

• Вся работа выполняется в каталоге /devel/. Когда вы довольны изменениями (надеюсь, у вас есть место, чтобы публично опубликовать сайт разработки для тестирования), используйте "svn merge", чтобы скопировать изменения из репозитория devel в live-репозиторий.

Ответ 3

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

Однако это не задано в камне - вы можете поместить все, что захотите. Он предназначен только для хранения версий кода, так что если вы хотите вернуться и восстановить более раннюю копию файла (любого типа), вы можете.

Надеюсь, что вы получите общую идею,

Ответ 4

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

• Импортируйте файлы проекта в репозиторий subversion.
• Оформить рабочую копию на вашей машине разработки
• Внесите изменения и зафиксируйте их
• У вас есть рабочая копия (svn checkout) на вашем сервере. В идеале у вас есть ssh-доступ к вашему серверу, поэтому вы можете выпустить эти команды на сервере. Для этого ваш репозиторий svn должен быть доступен с вашего сервера (например, установите svn-сервер через протокол http или svn). Если у вас нет доступа ssh, просто загрузите экспорт svn через ftp.
• Обновите файлы на своем сервере (обновление svn или загрузка ftp)

Что касается соединительных линий, ветвей и тегов: это только папки в вашем репозитории svn, которые необходимо создать, если вы хотите следовать соглашениям:

• trunk: версия для разработки
• ветки: релизы, например STABLE-1.0. Обычно ваш рабочий сервер работает на рабочей копии ветки релиза.
• теги: определенные вехи в история развития

Например, вы можете создать стабильную версию release branche vor version 1, создав папку STABLE-1.0 внутри ветвей и скопировав в нее файлы.

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

Существует очень хорошая книга о подрывной деятельности и концепциях, лежащих в ее основе, от прагматичных программистов под названием "Прагматическое управление версиями с использованием Subversion" (http://www.pragprog.com/titles/svn/pragmatic-version-control-using-subversion).

Ответ 5

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

Также включают двоичные файлы (например, изображения), которые являются зависимостями и которые вы не хотите или не можете легко восстановить из руки. Например, не ставьте сто PSD, потому что может потребоваться много времени для восстановления точного индексированного GIF. Но вы, вероятно, захотите включить свой PSD в дополнение к GIF. Включите DLL купленных патентованных библиотек и т.д. Наконец, я бы сказал, чтобы также добавить любые файлы конфигурации, которые заставляют приложение вести себя так, как есть: Apache vhost,.htaccess, php.ini и т.д.

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

Ответ 6

Я поместил все в управление версиями, которое понадобится программисту. Теперь ваш случай, который может потребовать слова docs и psd файлы. По моему опыту слова docs обычно создаются (и для) управления проектами, и я фактически запустил создание репозитория документов для этого (мы использовали Дерево знаний). Для графических исходных файлов я бы рекомендовал либо отдельный репозиторий, либо, по крайней мере, другой проект, поэтому вам не нужно включать anthying, что не нужно для разработки/развертывания вашего приложения.

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

Самой большой помощью для нашего развертывания стала установка полностью автоматизированной системы для развертывания наших серверов. Для рельсов мы используем фантастический Capistrano, а для окон мы катировали наши собственные, используя svn и python. Я действительно не рекомендую кататься самостоятельно, это требует много времени и времени. Однако в конце концов это спасло нас.

Даже если вы не используете Rails, я бы предложил сделать некоторые исследования в как работает Capistrano, он работает хорошо и решил много о проблемах, с которыми мы имели дело.

Ответ 7

Существует несколько проблем для веб-разработки, для которых svn является хорошим универсальным решением:

1: versioning: svn поддерживает прошлые версии в качестве наборов для сохранения, то есть каждый коммит получает свой собственный идентификатор ссылки, который охватывает все файлы, обновленные в этой фиксации. Используемый тщательно, это позволяет вам контролировать все файлы, которые затронуты исправлением ошибок, например, что-то, что потеряло cvs.

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

3: не путайте управление версиями svn с архивированием. Они очень разные. Включите репозиторий svn в стандартный режим архивирования/резервного копирования.

4: svn знает, как хранить дельта для двоичных файлов, в отличие от старых систем, таких как cvs, поэтому стоит держать все в вашем проекте под svn. Храните дерево svn так же, как и поставку вашего продукта, а развертывание - это просто вопрос ssh на сервере вашего сайта и запуск обновления svn в папках html и cgi-bin (убедитесь, что Apache настроен на отказ всем в папках управления .svn).

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

6: теперь, когда вам нужно воссоздать прошлое состояние, по какой-то причине все необходимые инструменты и другие файлы должны помочь это сделать. Обратите внимание, что svn по сути не решает проблему фрагментированного репозитория: html/, cgi-bin-/и db-состояния, не пересекаются и нуждаются в ручной корреляции, если вы не держите их вместе под зонтичной папкой.

7: вам понадобятся apache2 и openSSL и действительный сертификат для перехода на svn на вашем svn-сервере. Возможно, у вас уже есть этот sionce, который вы уже установили.

Если у вас был даже один плохой клиентский опыт от работы в файлах прогресса, выходящих на живой сайт, тогда хороший режим svn мог бы заплатить за это, чтобы предотвратить это. Большинство IDE и редакторов также включают инструменты управления svn, поэтому вам необязательно выходить из командной строки. Также есть плагины OS X Finder и Windows Explorer из http://www.tigris.org/ (среди многих других отличных инструментов).

Ответ 8

I версия управляет всем, что может измениться. Для меня это включает в себя:

• Код
• веб-контент (html и изображения)
• Сторонние библиотеки (импортированные .jar файлы)
• Документы
• Файлы конфигурации сервера
• Даже сами скрипты развертывания (ANT и .bat)

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

Используйте любую структуру, которая работает для вас, но не потеряйте запись изменений, поскольку она может сохранить ваш @$$, чтобы иметь возможность отменить изменение или воскресить документ, который, по вашему мнению, больше не использовался.