Версия контролируемой производственной среды

Question

Вопрос в том, как мне лучше управлять производственной средой?

Это наша текущая среда:

• (внутренний сервер) Разработка - версия под контролем исходного кода
• (сервер клиента) приемочного испытания среды
• (Клиент-сервер) Подмости среда
• (Заказчик сервер) Производственная среда

Когда мы выпускаем новые функции для принятия ance, мы публикуем в Visual Studio, обновляем изменения и применяем их на тестовом сервере. Там мы создаем резервную папку (чтобы мы могли отменить изменения), и мы создаем папку выпуска, чтобы мы могли перенести эти изменения в Staging, когда они были одобрены.

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

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

Когда функциональность должна быть перенесена из Test to Staging, мы экспортируем изменения, сделанные с последней даты. Обновленная среда была обновлена ​​и скопирована в приложение Staging. Там мы делаем фиксацию, которую позже можно извлечь для выпуска в производственную среду.

Недостатки этого в том, что использование subversion будет загромождать приложение этими каталогами .svn. Это можно исправить, запретив доступ к этим каталогам в IIS или web.config. Другим решением будет использование Git в каталоге над корневым каталогом приложения. Но Git труднее работать с неопытным разработчиком в среде Windows.

У кого-нибудь есть опыт в этой проблеме? Как вы контролируете свою производственную среду? Что делать, если вам нужно отменить выпуск, есть ли резервная папка, созданная до выпуска?

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

В то же время существует определенная неуверенность в этом. Никто не слышал об этом раньше, имея приложение в системе контроля версий, и мы не уверены в том, какими будут недостатки.

Если у вас есть опыт подобного сценария, я был бы рад услышать об этом.

Микаэль Лундин

Answer 1

Я использую mercurial (Hg) в качестве производственной системы управления версиями. (Не код, а фактически развернутые двоичные файлы). Это работает очень хорошо. Subversion не совсем подходит для использования в моем сценарии, потому что я хочу иметь возможность синхронизировать производственные изменения (например, файлы конфигурации), вернуться к тестированию и, возможно, даже к разработке. subversion сложнее синхронизировать/объединять между различными репозиториями (много ручного копирования). И с обновлением hg и hg обновляется ветерок, чтобы вернуться к стабильному (или нестабильному) тегу.

О, и я полностью согласен, вы должны использовать buildserver (cruisecontrol.net) или что-то еще и хранить все свои вещи там. В моем сценарии этого недостаточно, потому что конфигурация системы производства клиентов - это, конечно, индивидуальная и даже с обширным тестированием, и что не может быть какой-то конфигурации, которая больше не делает то же самое между двумя версиями (или входящие данные значительно изменились)

Answer 2

Другой способ сделать это - использовать сервер сборки. Каждый раз, когда вы проверяете код, сервер сборки строит и упаковывает новую сборку внутри среды разработки. Затем проверяет в развертываемом пакете код.

Затем вы можете развернуть упакованную сборку в другие среды. Таким образом, вам не нужно резервировать версии там, потому что у вас уже есть все встроенные версии в вашем основном репозитории. Если вы убедитесь, что развертывание полностью автоматизировано и может быть выполнено с помощью одной команды (powershell?), Нет необходимости хранить резервные копии на серверах.

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

Answer 3

Благодарим вас за ответы и предложения.

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

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

Может быть, я ищу серебряной пули :)

Answer 4

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

С помощью такого типа системы вы можете использовать теги subversion для быстрого обновления/отката к конкретным версиям развертывания.