Как убедиться, что мы публикуем продукцию на сервере prod и тестируем на тестовом сервере - PullRequest
0 голосов
/ 16 марта 2009

У меня есть запись в моем файле Web.Config, которая указывает, в какой среде я нахожусь для строк подключения и мусора:

<add key="AppEnv" value ="2" /> <!--(0 = Dev, 1 = test, 2 = prod)--> 

Я ищу способ предупредить разработчика во время публикации, чтобы убедиться, что он проверил этот ключ / значение, чтобы они не публиковали 'test' на сервере 'prod' и наоборот .

Спасибо

Ответы [ 8 ]

1 голос
/ 21 мая 2009

Я придумал собственное (возможно, нетрадиционное) решение этой проблемы. Мы разрабатываем много разных веб-проектов для множества разных клиентов и перенесли все из них на этот метод из-за всех проблем, которые у нас были с несколькими файлами web.config, или из-за необходимых изменений перед публикацией.

По сути, мы позволяем нашему приложению сообщать нам, в какой среде оно работает, на основе входящего URL. Мы инициализируем это по первому запросу и сохраняем в памяти на всю жизнь приложения. Таким образом, мы можем хранить каждое из значений конфигурации, специфичных для нашей среды, в одном и том же файле конфигурации и просто квалифицировать их как «Разработка», «Подготовка», «Производство» и т.д.

Сначала образец web.config:

<appSettings>
    <add key="DevelopmentHost" value="dev.trackmyhours.com" />
    <add key="StagingHost" value="staging.trackmyhours.com" />
    <add key="ProductionHost" value="www.trackmyhours.com" />
  </appSettings>

  <connectionStrings>
    <clear />
    <add name="DevelopmentConnectionString" connectionString="your dev conn string" providerName="System.Data.SqlClient" />
    <add name="StagingConnectionString" connectionString="your staging conn string (mine is typically same as staging)" providerName="System.Data.SqlClient" />
    <add name="ProductionConnectionString" connectionString="your production conn string" providerName="System.Data.SqlClient" />
  </connectionStrings>

Далее у нас есть класс «App», который дает нам доступ к нашему классу «Site», но вы можете создавать свои классы так, как считаете нужным.

Public Class App

    Private Shared _Site As New Site
    Public Shared ReadOnly Property Site() As Site
        Get
            Return _Site
        End Get
    End Property

End Class

Imports System.Configuration
Imports System.Web

Public Class Site

    Public Enum EnvironmentType
        Development
        Staging
        Production
    End Enum

    Friend Sub New()

        If HttpContext.Current IsNot Nothing Then

            Dim URL = HttpContext.Current.Request.Url.DnsSafeHost

            Select Case URL
                Case ConfigurationManager.AppSettings("DevelopmentHost"), "localhost"
                    _Environment = EnvironmentType.Development
                Case ConfigurationManager.AppSettings("StagingHost")
                    _Environment = EnvironmentType.Staging
                Case ConfigurationManager.AppSettings("ProductionHost")
                    _Environment = EnvironmentType.Production
            End Select

        Else
            'probably getting called from a winforms/console app, or unit tests
            _Environment = EnvironmentType.Staging

        End If

        _ConnectionString = ConfigurationManager.ConnectionStrings(_Environment.ToString & "ConnectionString").ConnectionString

    End Sub


    Private _Environment As EnvironmentType
    Public Property Environment() As EnvironmentType
        Get
            Return _Environment
        End Get
        Set(ByVal value As EnvironmentType)
            _Environment = value

            _ConnectionString = ConfigurationManager.ConnectionStrings(_Environment.ToString & "ConnectionString").ConnectionString

        End Set
    End Property

    Private _ConnectionString As String
    Public ReadOnly Property ConnectionString() As String
        Get
            Return _ConnectionString
        End Get
    End Property

End Class

Мы помещаем наши классы в нашу библиотеку классов Biz Object. Мы просто решили, что нет необходимости определять среду для каждого отдельного запроса, так как она действительно не может измениться за время существования приложения. Кроме того, это позволяет нам ссылаться на App.Site.Environment из ЛЮБОГО ГОДА в коде в библиотеке или коде позади. Это также полезно, если вам нужно добавить в ваш код некоторую условную логику - например, не отправлять электронные письма реальным людям при работе в dev / staging.

И последнее: для наших Linq2SQL или EF Data / ObjectContexts мы не храним строку подключения в файле, а вместо этого перегружаем конструктор, чтобы мы могли предоставить нашу правильную строку подключения к среде, например:

Partial Class SampleDataContext
    Sub New()
        MyBase.New(App.Site.ConnectionString)
    End Sub
End Class
0 голосов
/ 29 мая 2009

Установите для вашего Web.Config значение «Только чтение», поэтому оно не будет перезаписываться при публикации на этих серверах.

Компромисс заключается в том, что вам придется вручную поддерживать свои web.configs на каждом сервере, и ваша публикация будет утверждаться, что она потерпит неудачу, поскольку она не может перезаписать web.config на удаленном сервере; но имхо это предпочтительнее, чем модифицировать конфиг каждый раз, когда вы делаете загрузку

0 голосов
/ 09 мая 2009

Я считаю плохой практикой хранить строки подключения в web.config, вместо этого я создаю отдельный конфигурационный файл вне моих сайтов в общеизвестном месте, например

C: \ xxxx \ config.xml

Затем я сохраняю все зависящие от машины настройки. Таким образом, на моем работающем сервере у меня есть текущие настройки, на строках подключения тестового сервера к тестовой БД и на моей машине Dev я получил свои локальные настройки. Затем эти параметры можно также восстановить на всех веб-сайтах и ​​приложениях .net на этом сервере. Только одно место для обновления при изменении БД.

Отлично!

0 голосов
/ 17 марта 2009

Я беру любые ключи, которые будут отличаться в тестовой и рабочей среде, и помещаю их в совершенно новый файл .config. Я ставлю тестовые настройки на тестирование и производственные настройки на производство и никогда не копирую этот файл из теста в производство. Затем в своем обычном файле web.config вы можете указать этот новый файл .config следующим образом:

<appSettings file="ExternalWeb.config>
    .... common keys go here
</appSettings>

на тестовом сервере, "external.config" будет содержать значения, специфичные для этого сервера, а в рабочей среде он будет иметь значения prod. Это позволяет вам копировать весь файл web.config между двумя серверами, не изменяя файл вручную.

0 голосов
/ 17 марта 2009

Вечный вопрос, который постоянно всплывает! Я предполагаю, что любой серьезный разработчик ASP.NET каким-то образом ударился об этом.

Для ASP.NET 4.0 есть некоторая помощь - улучшенные параметры веб-развертывания будут предлагать функцию, называемую «преобразования web.config».

Ознакомьтесь с этим каналом 9 видео по теме - пока не нашли достойной письменной ссылки ...

Марк

0 голосов
/ 16 марта 2009

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

Существует множество полезных задач, поставляемых в комплекте с MSBuild, таких как AspNetCompiler task , который выглядит как одношаговое действие компиляции / публикации.

Есть также несколько проектов, которые объединяют большое количество «пользовательских» задач MSBuild для различных целей. В проекте Задачи сообщества MSBuild есть задача XmlMassUpdate, которая полезна для внесения нескольких изменений в файл в формате xml. Другими словами, идеально подходит для обновления файлов web.config.

Я нашел пример использования задачи XmlMassUpdate совместно с проектом веб-развертывания здесь .

0 голосов
/ 16 марта 2009

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

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

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

0 голосов
/ 16 марта 2009

Вот решение: сохраните этот файл как "Web.Config.in" под контролем исходного кода.

На каждом сервере (dev, test, staging, production) скопируйте Web.Config.in в Web.Config и тщательно отредактируйте значение AppEnv.

При каждом последующем перемещении из одной среды в другую исключайте Web.Config файлы. То есть не перезаписывайте этот конкретный файл. Напишите сценарии развертывания, которые запускают, например, rsync --exclude WebConfig.

...