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

Question

Я установил SVN на свой сервер, и мне интересно, как лучше его использовать. Например, у меня есть папки apache htdocs и cgi-bin. Должен ли я положить обе папки в SVN? когда я работаю над проектом, у меня обычно есть имя_проекта как папка в каждом - htdocs / projname и cgi-bin / projname? Должен ли я svn оба? Является ли хорошей идеей присваивать мои изображения и другие материалы из htdocs или я должен присваивать только свой код?

Кроме того, стоит ли писать svning-документы, psd-файлы (которые обычно огромны, например, 100 МБ или около того)? Или я должен избегать их?

Я уже делаю ежедневное добавочное резервное копирование всех своих данных.

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

Большое спасибо за ваше время.

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

1. Импорт файлов вашего проекта в хранилище Subversion
2. Оформление рабочей копии на компьютере разработчика
3. Вносить изменения и фиксировать их
4. На вашем сервере есть рабочая копия (svn checkout). В идеале у вас есть доступ по ssh к вашему серверу, поэтому вы можете выполнять эти команды на сервере. Чтобы это работало, ваш svn-репозиторий должен быть доступен с вашего сервера (например, настроить svn-сервер по протоколу http или svn). Если у вас нет доступа по SSH, просто загрузите экспорт SVN через FTP.
5. Обновление файлов на вашем сервере (svn update или загрузка по ftp)

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

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

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

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

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

Answer 4

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

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

Надеюсь, что это дает вам общее представление,

Answer 5

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

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

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

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

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

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

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

Answer 8

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

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

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

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