Настройка проекта Orchard с нуля для работы в команде и с другими настройками среды
Мне нужно создать новый проект Orchard Project для работы в команде, и я чувствую себя потерянным. Мои основные вопросы сейчас:
- Как использовать три разные строки подключения SQL в зависимости от среды развертывания (локальная, разработка, производство)
- Как только у нас появятся определения контента и контент, которым мы довольны на местном уровне, как мы перенесем его в разработку или производство? Как вы контролируете версию базы данных?
- Это хороший путь? Мы готовы работать с VisualStudio вместо WebMatrix, потому что в конечном итоге нам придется создавать наши собственные модули, и все учебные пособия из Lombiq используют VS. Я создал ветку с именем Orchard.SourceCode, содержащую исходный код 1.9.1-v и ветку разработки. Каждый раз, когда у Orchard выходит новая версия, я заменяю файлы в Orchard.SourceCode новым кодом выпуска, фиксирую и объединяю в Development.
Я уже погуглил, но если вы найдете действительно полезную ссылку, которую я, возможно, пропустил, не стесняйтесь поделиться.
Примечание: мы используем Mercurial в качестве CVS
3 ответа
На этих компьютерах (локальные, производственные,development1,development2) должны быть собственные файлы в этих папках Orchard.Web\App_Data\Sites, Orchard.Web\App_Data\RecipeQueue, Orchard.Web\App_Data\Logs, src\Orchard.Web\Media\, поэтому эти папки не должны быть в хранилище. Потому что, как объясняет @NetWave, здесь есть строка подключения и другие локальные данные.
Рекомендуется использовать функцию импорта-экспорта для импорта-экспорта рецептов. Альтернативным вариантом является использование механизма миграции Orchard Data Access Layer. Дело в том, что если вам не нужно добавлять или изменять таблицы в БД для ваших пользовательских частей, вы должны использовать рецепты. В нашем случае у нас есть один модуль с одним рецептом с именем upgrade-recipe.xml. Там мы добавляем все новые вещи, чтобы добавить к следующему обновлению. Когда обновление выполнено, мы очищаем этот файл. Это помогает нам поддерживать небольшие файлы миграции. Фактически для таких операций, как удаление элемента содержимого или всех элементов содержимого типа, мы создали команды, которые также могут быть выполнены из рецепта.
Для меня это нормально, что конфигурация. Мне нравится иметь код в репозитории, потому что иногда я исправляю ошибки Orchard и не могу дождаться, когда они примут мой запрос на извлечение. Может быть, вы можете улучшить его, используя источник Orchard в качестве форка исходного хранилища. Это облегчит вам отправку запросов на получение доступа к ним.
Что я всегда делаю, так это:
Исходный код Orchard с использованием Visual Studio для разработки собственных модулей на местном уровне.
Сайт Azure Orchard для моей тестовой среды.
Определения типов контента можно экспортировать из тестовой среды в рабочую среду с помощью модуля "Экспорт / импорт". Или вы можете создать свои собственные определения типов контента через файл миграции в своем собственном модуле.
Я бы не включил полное решение исходного кода Orchard в ваш контроль версий, а просто включил модуль, который вы разрабатываете. После обновления Orchard до новой версии создайте новую среду.
Надеюсь, это поможет.
С уважением
Строка подключения находится в App_Data\Sites\Default\Settings.txt.
Мы всегда используем полный исходный код Orchard для разработки нового сайта в Visual Studio. В отличие от Рамона, мы храним полное решение в TFS. Таким образом, у каждого сайта есть отдельная копия полного исходного кода. Некоторые из них 1.8.x, некоторые 1.9.x и т. Д. Хранение дешево, верно?;)
Наличие источника и ветки разработчика - это то, что я также делал в прошлом. Легко применить исходные изменения к вашей ветке разработчика. Я сделал это для ветки 1.9, когда она еще находилась в разработке (1.x), но я хотел использовать новые возможности макета. Но в большинстве случаев стабильная версия Orchard выбирается, когда мы запускаем новый сайт (например, 1.9.1), а источник почти не обновляется (только небольшие исправления).
Что касается базы данных... В первый раз, когда сайт помещается в preprod, мы просто копируем всю базу данных. После этого миграции являются наиболее распространенным способом синхронизации типов. Импорт / экспорт может использоваться для синхронизации данных (но это то, что мы вряд ли используем).
Надеюсь, это поможет.