Блог

Главная - Вопросы по программированию - Внесение изменений в действующий сайт (Codeigniter, но не специфичный для него)

Внесение изменений в действующий сайт (Codeigniter, но не специфичный для него)

#php #mysql #codeigniter

#php #mysql #codeigniter

Вопрос:

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

Или вы копируете базу данных и файлы на локальный сервер (MAMP / WAMP / XAMMP) и работаете над этим там, затем, если это работает, обновите действующий сайт с изменениями. Для этого второго метода есть ли возможность проверить, какие файлы были изменены, и загрузить только их? Что, если это работает на локальном сервере, но после обновления действующего сайта это не работает?

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

Ответ №1:

Не работайте непосредственно на живом сайте. Вместо этого создайте среду разработки (используя, скажем, vmware или virtualbox на вашем компьютере) и клонируйте живую среду. Получите свой код в системе управления версиями (я повторю это еще раз: ПОЛУЧИТЕ СВОЙ КОД В СИСТЕМЕ УПРАВЛЕНИЯ ВЕРСИЯМИ), выполните свою разработку на компьютере разработчика, используя ветку dev в системе управления версиями. После того, как вы закончите тестирование и будете довольны изменениями, зафиксируйте их в «deployments» или «live» ветке и оттуда выполните развертывание на действующем сайте. Обязательно сделайте резервную копию базы данных перед развертыванием нового кода.

Редактировать: используйте символические ссылки для размещения вашей новой кодовой базы на действующем сайте. Если это не сработает, просто переключите его обратно в старый каталог. Вы экономите много времени!

Комментарии:

1. Использование символических ссылок для переключения на другие ветки / новые основные версии действительно очень хороший совет.

2. Допустим, мой веб-хост является общим хостом. Означает ли это, что я не могу использовать vmware / virtualization на нем?

3. Вы используете виртуализацию на своем компьютере — том, на котором вы печатаете прямо сейчас. Среда разработки должна быть полностью отделена от живой среды.

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

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

Ответ №2:

  1. Прочитайте о контроле версий (svn, git и др.).).
  2. Никогда не работайте на действующем сайте, предпочтительно на другом сервере (для предотвращения while(1){..} сбоев и т.д.), Но на том же сервере, по крайней мере, в другом documentroot / домене, предпочтительно с ограниченным доступом только к вашему IP.
  3. Обычно я копирую только определения таблиц ( mysqldump -t это хорошо для этого) и у меня есть совсем другая база данных, если вам нужны самые последние и качественные данные, вы можете скопировать свою основную базу данных в тестовую базу данных, что также дает вам преимущество дешевой резервной копии, если у вас ее еще нет.
  4. Обычно я устанавливаю переключатель в конфигурации Apache / Vhost ( SetEnv DEV=1 ), чтобы в коде я мог использовать if(getenv('DEV')==1) для проверки, могу ли я просто сбрасывать переменные в условиях ошибки, и которые ограничивают возможность случайной фиксации / загрузки кода с включенным по случайности «переключателем разработки».

Ответ №3:

Типичным ответом на этот вопрос будет выполнять свою работу в тестовой среде, а не в производственной. И я согласен, что это часто лучший способ обработки изменений. Если у вас есть роскошь тестовой среды, воспользуйтесь ею в полной мере. В конце концов, для этого он и существует — для тестирования.

Однако это не означает, что работа в производственной среде полностью запрещена. Ваше решение должно основываться на нескольких факторах:

  • Важна ли работа вашего веб-сайта для потребностей вашего бизнеса?

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

  • Будут ли изменения, которые вы собираетесь внести, сильно влиять на остальную часть веб-сайта?

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

  • Сколько времени займет реализация ваших изменений?

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