Каковы наилучшие практики для передачи веб-приложения от стадии разработки к производству?

Question

Наша среда разработки имеет много уровней и сложна для эффективной репликации или даже резервного копирования. В основном, файловая система (т.е. / usr / appdir / webapp ...) содержит другие приложения, обслуживающие наше веб-приложение, те приложения, которые мы обновляем, выполняют обновления svn из своего репозитория.

Использование самого веб-приложения (как пользователя) повлияет как на файловую систему, так и на базу данных. Поэтому резервное копирование системы - это вопрос наличия копии файловой системы и базы данных (mysqldump) в один и тот же момент времени. Одно из двух само по себе не будет полной резервной копией, поскольку само приложение очень динамично.

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

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

Я задаюсь вопросом, является ли их наилучшей практикой способ создания эффективного процесса перехода от dev -> staging -> production? Или, если у вас есть несколько указателей.

Answer 1

Судя по всему, ваша проблема усложняется характером вашего приложения.

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

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

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

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

Answer 2

Я обычно не делаю никаких изменений в среде QA / staging. Любые изменения вносятся в среду разработки и затем передаются как в QA / staging, так и в производство. Обычно я не использую живые данные в QA / staging, если я могу избежать этого. В тех случаях, когда у меня есть текущие данные в QA / staging, я буду использовать что-то вроде SQL Data Compare (из Red Gate) для управления миграцией новых данных из среды QA / staging в рабочую среду.

Кроме того, я поддерживаю отдельные конфигурации для dev / QA / production в управлении исходным кодом. Немного тяжело помнить, что нужно вносить изменения во все конфиги, когда изменения затрагивают их все, но есть достаточно различий, чтобы сделать это проще, чем обновить конфигурацию для QA / production, когда приложение будет опубликовано / установлен.