Как я мог бы улучшить свою стратегию развития и стратегию развертывания?
Я работаю над веб-приложением, которое работает на стеке LAMP (Apache Linux Mysql PHP) и хотело бы рекомендации на улучшении моего рабочего процесса.
У меня есть 3 среды:
- Моя локальная машина иначе моя среда разработки
- Учетная запись подготовки на моем выделенном сервере так, чтобы я мог протестировать веб-приложение
- Производственная учетная запись на моем выделенном сервере
Я делаю всю разработку на своем локальном компьютере и использую сервер подверсии, который расположен на моем выделенном сервере. Я настроил сценарий рычага так, чтобы каждый раз, когда я фиксирую, моя учетная запись "подготовки" была обновлена с новым кодом.
Время от времени я удостоверяюсь, что все хорошо работает на подготовке, считают и продвигают изменения в моей производственной учетной записи с помощью маленького сценария.
Это работает достаточно хорошо по большей части, но существует несколько раздражений:
Мое доменное имя трудно кодируется в нескольких местах, делая это трудоемким для переключения между средами. Я могу изменить свой файл hosts вручную, но это не точно быстро, и это не работает на 2 учетных записи (напоминание/подготовка) на том же сервере.
У меня нет способа усовершенствовать базу данных через все три среды. Я мог использовать ту же базу данных для всех сред, но я должен буду рискнуть повреждения продуктивной среды.
Так, мой вопрос: что я мог сделать для смягчения этих проблем?
ОБНОВЛЕНИЕ: твердая кодированная доменная проблема представлена сторонним программным обеспечением и поэтому, "не трудно кодирование ее" не является опцией в данный момент.
2 ответа
В идеале вы бы хотели, чтобы постановка была точной копией производства. Таким образом, то, что вы видите в инсценировке, вы можете быть достаточно уверены, что вы увидите в производстве. Автоматический переход к инсценировке, когда вы делаете коммит, не делает этого, так как все ошибки, которые вы вводите с коммитом, мгновенно отправляются в инсценировку.
Возможно, вы захотите настроить другое окружение и назвать его тестированием. В этом случае вы автоматически перейдёте к коммиту. Используйте это окружение для контроля качества, и оттуда вы можете упаковать код и отправить его на сцену для окончательного тестирования. Если все идет хорошо, то запустите пакет в производство.
Что касается проблемы с доменными именами, я бы не рекомендовал их жестко закодировать, если вам это сойдет с рук. Или, по крайней мере, используйте субдомены для различных сред, чтобы легче было программно определить, в каком окружении вы находитесь.
Чтобы поддерживать базу данных в актуальном состоянии в различных окружениях, вам, возможно, стоит подумать о том, чтобы периодически делать дамп из производственной среды и обновлять инсценировку, тестирование и dev окружения с помощью этого дампа. Раз в день это должно работать. Таким образом, вы разрабатываете и тестируете на основе того, что пользователи видят в производстве
.Что касается вашей последней пары пунктов, очевидным решением, кажется, будет (1) нигде не жестко закодировать домен, или, если вы должны, по крайней мере, разделить его на один файл "локальных настроек", который не обновляется через SVN; (2) написать скрипт для синхронизации баз данных (т.е. скопировать производственные данные на инсценировку и/или ваше локальное окружение, конечно же, не наоборот) и время от времени запускать его.
.