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

Question

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

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

Я использую eclipse и subversion (php code). Я знаю, что задал много вопросов, но, надеюсь, вы поняли, что я пытаюсь сделать ... и я предполагаю, что он довольно распространен. Благодарю.

Answer 1

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

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

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

Answer 2

Похоже, что вы не создали никаких ветвей или тегов и, вероятно, имеете «багажник», который не помечен как таковой. Лучшие практики будут диктовать, что у вас есть багажник для текущего стабильного кода, ветви, против которых вы работаете, и теги, которые фактически используются на производственном сайте. Существует short description and diagram on Wikipedia.

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

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

Answer 3

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

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