Настройка ссылок на сервер разработки

Question

Что вы, ребята, порекомендовали бы в качестве хороших ссылок для настройки тестового сервера (xampp на xp pro), промежуточного сервера и рабочего сервера, в то же время имея svn? Я новичок в «хардкорном» развитии, но хочу начать с правой ноги и настроить свою среду, как это делают профессионалы. У меня есть несколько проектов, и я хочу сделать два шага вперед вместо одного шага вперед и двух назад.

Моими основными областями наименьшего понимания являются ... поддержание правильных путей к файлам между всеми серверами и базами данных (работа с localhost / site.com / file.html vs www.site.com/file.com), продвижение обновлений к следующий сервер - тестирование, подготовка к производству, а также использование SVN (у нас будет несколько человек, работающих над одними и теми же проектами одновременно).

В каждом проекте будет один сервер, поэтому информация о балансировке нагрузки и настройке нескольких серверов не требуется. Мы также планируем использовать NetBeans или Eclipse для SVN, если не указано иное.

Производственные и промежуточные серверы будут LAMP, а тестирование - xampp на xp pro. Спасибо за помощь!

Answer 1

В ответ на запрос Чада о дополнительных примерах папок среды и файлов конфигурации, здесь дополнительная информация:

У нас есть любые настройки, используемые проектом, разбитые на файлы конфигурации; мы создаем веб-сайты, поэтому ссылки на эти файлы конфигурации приведены в файле web.config.

Например, в нашей папке конфигурации у нас есть файл ConnectionStrings.config с этим внутри (заполняет вашу информацию вместо [], конечно):

<connectionStrings>
    <add name="APP"
         connectionString="Data Source=[];Initial Catalog=[];uid=[];password=[]"
         providerName="System.Data.SqlClient" />
</connectionStrings>

Путь к нему:

Site root
|--> Configuration

Таким образом, на него ссылаются в веб-конфигурации следующим образом:

<connectionStrings configSource="Configuration\ConnectionStrings.config" />

Итак, в нашей папке с решением будет такая структура:

Solution folder
|--> Environments
  |--> Development
    |-->Configuration
      |--> ConnectionStrings.config
  |--> Production
    |-->Configuration
      |--> ConnectionStrings.config
  |--> Staging
    |-->Configuration
      |--> ConnectionStrings.config
|--> Src
  |--> Project folder (site root)
    |--> Configuration
      |--> ConnectionStrings.config

То же самое с любыми другими настройками, обычно помещаемыми в наш AppSettings.config. Так что такие вещи, как пути к файлам или любые другие настройки, которые могут измениться.

<appSettings>
    <add key="FilePath" value="C:\FileStorage"/>
</appSettings>

Answer 2

3 части к вашему вопросу:

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

Так как:

Solution folder
    |--> Environment
      |--> Development
      |--> Staging
      |--> Production
    |--> Src
      |--> Project folders

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

2) Передача изменений кода на серверы среды - в SVN мы настраиваем филиалы для среды для каждого проекта. Так как:

SVN Root
|--> Project
  |--> Branches
    |--> RB-Development
    |--> RB-Staging
  |--> Trunk

Магистраль - наш производственный код.

Мы также создаем новую ветвь для каждого набора функций, над которым мы работаем. Затем, когда все готово к развертыванию, мы объединяем его с соответствующей веткой среды; инструмент компоновки отслеживает эти ветви среды и автоматически развертывается в правильную ветвь, когда код фиксируется.

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

Answer 3

Хорошо. Подготовьте свой магазин приложений для разработки и настройки производства. Такие вещи, как доступ к базе данных и пути. Нет причин хранить одинаковые пути для разных серверов (особенно если вы смешиваете Unix и Windows)