Как я могу улучшить свою стратегию разработки и развертывания?

Я работаю над веб-приложением, которое работает в стеке LAMP (Linux Apache Mysql PHP), и хотел бы получить рекомендации по улучшению моего рабочего процесса.

У меня есть 3 окружения:

  1. Моя локальная машина ИНАЧЕ моя среда разработки.
  2. промежуточная учетная запись на моем выделенном сервере, чтобы я мог протестировать веб-приложение.
  3. рабочая учетная запись на моем выделенном сервере

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

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

По большей части это работает достаточно хорошо, но есть несколько неприятностей:

  • Мое доменное имя жестко запрограммировано в нескольких местах, поэтому переключение между средами занимает много времени. Я могу изменить свой файл hosts вручную, но это не совсем быстро и не работает для двух учетных записей (prod / staging) на одном сервере.

  • У меня нет возможности поддерживать базу данных в актуальном состоянии во всех трех средах. Я мог бы использовать одну и ту же базу данных для всех сред, но мне пришлось бы рискнуть нарушить производственную среду.

Итак, мой вопрос: что я могу сделать, чтобы смягчить эти проблемы?

ОБНОВЛЕНИЕ. Проблема с жестко закодированным доменом возникает из-за стороннего программного обеспечения, поэтому в настоящее время вариант «без жесткого кодирования» невозможен.


workflow svn lamp
person Olivier Lalonde    schedule 02.01.2010    source источник
comment
Оливье: Я отредактировал ваш вопрос, чтобы сделать его более конкретным. ТАК - это не форум, и он плохо работает с любыми комментариями по этому поводу? вопросов; Я думаю, что вы хорошо поработали, выявив конкретные проблемы в своем последнем абзаце, и поэтому попытались выделить их (также изменив фокус заголовка с просьбы рассказать анекдоты)   -  person Shog9    schedule 02.01.2010
comment
Может ли кто-нибудь, пожалуйста, сказать мне, что общее соглашение и значение, связанное с dev, stg и prod. Похоже, я смущен их значением (или кажется, что я использовал соглашение / семантику, которые не синхронизируются с тем, что используют другие). Спасибо   -  person Mahesh Velaga    schedule 02.01.2010
comment
Я считаю, что это обычное соглашение: Dev: среда для разработчиков Staging: среда для обеспечения качества (до внесения изменений в prod) Производство: общедоступная среда   -  person Olivier Lalonde    schedule 03.01.2010

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

person Darrell Brogdon    schedule 02.01.2010
comment
Спасибо за предложения, Дарелл. Я понимаю необходимость среды, которая является точной копией производственной среды, но прямо сейчас, поскольку я единственный разработчик / тестировщик своего приложения, я вряд ли допущу ошибки во время тестирования. Что касается вопроса доменного имени, у меня нет реальной власти над этим, поскольку я использую стороннее программное обеспечение, которое за это отвечает: /. Посмотрю, нормально ли работают поддомены. - person Olivier Lalonde; 02.01.2010

arrow_upward
1
arrow_downward

Что касается последних двух пунктов, очевидным решением может быть (1) нигде не кодируйте домен жестко или, если необходимо, по крайней мере, разделите его в один файл «локальных настроек», который не обновляется через SVN; (2) напишите сценарий для синхронизации баз данных (т. Е. Скопируйте производственные данные в промежуточную и / или локальную среду, но не наоборот) и запускайте его время от времени.

person David Z    schedule 02.01.2010