Управление разработкой и производственной средой для веб-приложения?

Question

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

Это мой вопрос: я все еще хочу иметь возможность проверять любые изменения локально, прежде чем публиковать в производство. Как мне справиться с этим с помощью репозитория без необходимости поддерживать 2 версии моего кода (которые мне нужно синхронизировать вручную)? С одной стороны, производственный код имеет несколько отличий (например, константы базы данных и т. Д.). Я хотел бы иметь возможность изменить свой код в моем локальном репозитории, протестировать его на моем локальном сервере Apache, а затем проверить код непосредственно в рабочей среде (возможно ли это даже при использовании eclipse)?

Я использую Eclipse и Subversion (код PHP). Я знаю, что задавал много вопросов, но, надеюсь, вы поймете, что я пытаюсь сделать ... и я предполагаю, что это довольно часто. Спасибо.

Answer 1

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

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

Answer 2

Я бы предложил несколько вещей

1. Используйте теги / ветки в SVN. Когда код будет готов к работе, пометьте его уникальным именем.
2. Настройка промежуточной зоны для интеграционного тестирования. После того, как релиз помечен для подготовки, выдерните его из своего vcs и скопируйте в область подготовки. Это может быть так же просто, как другое дерево каталогов или вторая установка вашего сервера.
3. Поместите константы в отдельные файлы, которые можно скопировать / объединить в каталогах размещения и развертывания.
4. Протестируйте поэтапную версию с dev, чтобы убедиться, что все работает как в вашей среде dev. Я бы указал на постановку производственных баз данных, когда я уверен, что они работают и готовы к продвижению. Проверьте, что это также работает против продукта.
5. Как только все будет готово, обновите рабочую копию. Я бы посоветовал вам создать чистый каталог развертывания, а затем скопировать все это развертывание на рабочий сервер после копирования / объединения настроек конфигурации.

Этот мой подход имел дело с perl / cgi много лет назад, и он работал довольно хорошо. SVN гораздо лучше справляется с тегами / ветвлениями, поэтому с ними легче работать. У нас было очень мало производственных проблем, когда мы начали готовить файлы перед тем, как нажать на prod.

Answer 3

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

Конечно, это просто лучшая практика. Ваш проект звучит достаточно маленьким, чтобы вы могли с легкостью разбить код на каталог разработки / и каталог производства / в своем хранилище кода. Верните код в каталог разработки и, после того как изменение полностью протестировано, объедините его с рабочим каталогом.

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