У меня вопрос, как мне правильно контролировать версию рабочей среды?
Это наша текущая среда:
- (Внутренний сервер) Разработка - Исходный код с управлением версиями
- (Клиентский сервер) Среда приемочных испытаний
- (Клиентский сервер) Промежуточная среда
- (Клиентский сервер) Производственная среда
Когда мы выпускаем новую функциональность для приемочного тестирования, мы публикуем в Visual Studio, архивируем изменения и применяем их на тестовом сервере. Там мы создаем резервную копию папки (чтобы мы могли отменить изменения) и создаем папку выпуска, чтобы мы могли переместить эти изменения в промежуточную, когда они будут утверждены.
Это много ручного труда, создающего резервные папки, освобождающего папки, воссоздающего структуру каталогов и пытающегося отследить, какая функциональность входит в какой выпуск. Это утомительно, и всегда есть проблема с каким-то разработчиком, не выполняющим процедуру выпуска.
Теоретически я мог бы создать репозиторий для тестовой среды. (забудьте исходный код, речь идет об опубликованном приложении). В каждом выпуске разработчик делает коммит и комментирует его функциональность.
Когда функциональность должна быть перемещена из Test в Staging, мы экспортируем изменения, сделанные с момента последнего обновления среды Staging, и копируем их в приложение Staging. Там мы делаем коммит, который позже можно извлечь для выпуска в производственную среду.
Недостатки этого метода в том, что использование subversion загромождает приложение этими каталогами .svn. Это может быть исправлено путем запрета доступа к этим каталогам в IIS или web.config. Другим решением было бы использование Git в каталоге над корневым каталогом приложения. Но с Git труднее работать неопытному разработчику в среде Windows.
У кого-нибудь есть опыт решения этой проблемы? Как вы управляете версией вашей производственной среды? Что если вам нужно отменить выпуск, у вас есть папка резервной копии, созданная до выпуска?
Я обсуждал это с нашими разработчиками, и они не видят никаких проблем с использованием Subversion для управления версиями и резервного копирования среды тестирования / подготовки / производства. Наоборот, они были бы рады не создавать папки выпуска / резервного копирования каждый раз, когда им нужно было выпустить новые функции.
В то же время в этом есть некоторая неуверенность. Никто не слышал об этом раньше, имея приложение в системе контроля версий, и мы не уверены, какие будут недостатки.
Если у вас есть опыт такого сценария, я был бы рад услышать об этом.
Микаэль Лундин