Как мне узнать, как создать / развернуть / администрировать веб-сайт?

Question

Я привык писать настольные приложения на C # .NET.Где у меня есть хорошая маленькая папка решения, которая также находится под контролем версий.Поэтому в любое время на любом компьютере я могу проверить любую версию моего программного обеспечения, которую я хочу, запустить компилятор и получить рабочую копию моей программы.

Теперь я занимаюсь разработкой веб-сайтов, где файлы иданные намного более рассредоточены.Я использую ASP.NET, но на самом деле мой вопрос носит более общий характер и может относиться к любой структуре веб-сайта.

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

Диаграмма ниже показывает мою текущую идею.Все исходные файлы для сайта будут храниться на сервере Subversion, который я проверял на своем локальном компьютере.Мой локальный компьютер будет иметь локальную базу данных, которую я буду использовать для разработки сайта.Затем я опубликую тестовую версию на моем размещенном сервере, которая будет указывать на отдельную тестовую базу данных.Эта тестовая база данных может периодически заменяться копией действующей базы данных.

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

Имеет ли это смысл?У кого-нибудь есть комментарии о том, как это можно улучшить?Существуют ли хорошие книги или онлайн-учебники по разработке таких рабочих процессов?

Также одна вещь, в которой я действительно не уверен, это то, как управлять изменениями в реальной схеме базы данных.Я полагаю, что с каждой версией я могу создать сценарий SQL, который можно использовать для обновления баз данных Test и Live на хосте.Тем не менее, я также хотел бы иметь возможность легко настроить новую базу данных для любой версии моего сайта без необходимости запускать каждый скрипт SQL для каждой версии до нужной версии.Является ли лучшее решение для использования ORM, например, NHibernate или Subsonic, чтобы я всегда мог генерировать схему базы данных непосредственно из своего кода?

Answer 1

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

Там, где я работаю, у нас есть мощный веб-сервер. Наши репозитории Subversion также живут на этом сервере. Для себя, как разработчика LAMP, я делаю все свои разработки на моей локальной машине Linux (или ВМ) с локальной базой данных MySQL, работая на локальной рабочей копии.

Я всегда поддерживаю две основные ветви приложения: ветку Dev (транк) и ветку Live (которая отражает текущую производственную версию). Мой репо выглядит так:

/repo/trunk/        [My current active development version]
/repo/archive/      [All other versions not in active development live here]
/repo/archive/2010.12/  [This happens to be the current production version]

На веб-сервере мы поддерживаем три отдельных экземпляра программного обеспечения: Live (или Production), Beta и Dev. Следующее должно иллюстрировать, как мы используем эти версии для

• Dev - всегда указывает на нашу версию для разработки в `/ repo / trunk '. Использует неконфигурированный файл конфигурации для указания на базу данных разработки. Однако развитие здесь никогда не происходит физически; вместо этого мы работаем на наших локальных машинах, где наши рабочие копии указывают на магистраль, и проводим все наши тесты разработки на наших локальных машинах. Однако после нескольких коммитов от нескольких разработчиков важно протестировать на сервере Dev, чтобы убедиться, что мы на правильном пути, и никто не нарушает чужие изменения.

• Live - всегда указывает на самую последнюю стабильную производственную версию. В этом случае он указывает на /repo/archive/2010.12/. Эта версия общедоступна.

• Бета - В большинстве случаев Бета будет зеркалом того, что есть в Live, и указывает на ту же производственную версию в нашем репозитории (/repo/archive/2010.12). Каждый раз, когда нам нужны исправления ошибок в Live, мы делаем их здесь, тестируем их, а затем фиксируем и обновляем live. (Мы также объединяем их в магистраль, если необходимо.)

Когда версия в Trunk считается завершенной и готовой к тестированию, я создаю новую ветвь архива в репозитории для предстоящего нового выпуска (т.е. 2011.01), svn copy используя существующую производственную ветвь. Затем я объединяю версию Trunk с новой веткой и фиксирую, поэтому у нас есть версия, которая отражает то, что в данный момент находится на Dev. Конечно, теперь активная разработка для следующего релиза может продолжаться на Dev, пока мы бета-тестируем эту новую архивную версию на бета-версии. После завершения бета-тестирования мы фиксируем все исправления и переключаем Live на новую версию (/repo/archive/2011.01).

Теперь вы, наверное, поняли, что объединение базы данных немного сложнее. Мы используем MySQL и, насколько мне известно, не существует подходящей системы управления версиями для MySQL. Таким образом, с каждой миграцией (VM на Dev, Dev на Beta, Beta to Live) я сначала делаю резервную копию текущей базы данных, затем вносю необходимые изменения. Лично я использую коммерческую версию SQLYog, которая позволяет синхронизировать схему базы данных (очень удобно).