Рекомендации по разработке и внедрению веб-приложений php с использованием общего кода проекта

Question

Мне интересно, как лучше (для одинокого разработчика)

1. разработать проект, который зависит от кода других проектов
2. развернуть получившийся проект на сервере

Я планирую поместить свой код в svn и разделить код в качестве отдельного проекта. Есть проблемы с svn: externals, которые я не могу полностью оценить.

Я прочитал

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

но есть одна особенность php-проектов (и другого интерпретируемого исходного кода): нет конечного исполняемого файла, получаемого из ваших библиотек. Внешние зависимости, таким образом, всегда находятся в необработанном исходном коде.

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

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

1. Когда вы хотите развернуть проект, вы можете заморозить его зависимости, верно?

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

   * (обновление 1: я также предполагаю, что svn: ignore создаст проблемы, если я не смогу использовать символические ссылки, см. мой комментарий )

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

Это подводит меня к последней части вопроса (поскольку одна влияет на другую): Как вы развертываете приложения с такими зависимостями? Я посмотрел BuildOut для Python, но, похоже, он тесно связан с экосистемой Python (поиск и загрузка модулей Python из Интернета и т. Д.).

Я очень хочу узнать о ваших лучших практиках.

Answer 1

Один из подходов может быть:

• один репозиторий на зависимость
• файл конфигурации требований для вашего проекта, в котором документируются зависимости и их версии (возможно, даже ваши собственные версии зависимостей)
• сценарии автоматизации, которые обрабатывают настройку сред разработки, тестирования и развертывания (могут быть простыми, например, документировать процедуру установки один раз и сделать ее настраиваемой и выполнимой)

Это имеет несколько преимуществ:

• вы можете легко (или даже автоматически) проверить, устарели ли ваши зависимости (доступна другая лучшая библиотека) или известны уязвимости безопасности.
• больше осведомленности о зависимостях
• проще отлаживать / исправлять / исправлять проблемы, вызванные зависимостями
• игнорирование svn: externals также может облегчить боль при переходе к распределенному управлению версиями, таким как git, bzr, hg в будущем.
• если вы хотите настроить свою среду на другом компьютере (или, в конце концов, другой разработчик вступит во владение или присоединится), это сэкономит вам массу времени

Некоторые инструменты автоматизации KISS, популярные в веб-разработке и администрировании серверов:

• ткань (питон)
• buildout (python)
• capistrano (рубин)

Резюме:

Документируйте ваши требования (желательно машиночитаемые -> yaml, ini, json, xml) и обрабатывайте зависимости вне вашего проекта. Это дает вам некоторую косвенность, которая делает автоматическую настройку и развертывание более простой и менее зависимой от вашей системы контроля версий (разделение задач, лучший инструмент для работы и т. Д.).

Answer 2

Это может звучать дешево, но я думаю, что у меня есть ответ для вас в этой ветке вопросов: Структура папок SVN

Пока вы находитесь в своем собственном хранилище, я не буду считать svn: externals вредным, как указано. Только не переусердствуйте.

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

Направляя внешние теги (и делая теги доступными только для чтения на сервере SVN), вы можете быть на 100% уверены, что получите нужную библиотеку.