Какой подход при разработке крупных проектов на локалке лучший?
На примере вп.
Есть статик файлы и есть бд. Я разрабатываю у себя на компе сайт выгружаю его на хостинг заказчику.
Через 2 месяца он мне просит поменять цвет шрифта, а у меня там все завязано на webpack/gulp scss, babel etc, то есть просто поменять пару строк через хост вряд ли выйдет. Что в таком случае делают?Если я еще могу через git или что-то еще деплоить проект со своего компа на хостинг в считанные секунды. то как быть с БД?Ее же просто так не сдеплоишь, а если на локальном сервере будут какие то изменения в бд, то они просто затрутиться.
В общем какой подход к разработке сайтов с бд и их постоянной поддержке используется?
Чтобы желаьно всегда работать из под локальной машины.
Для базы данных заведи отдельную папку и под каждую версию релиза создавай подпапку куда складывай скрипты, которые создают новые объекты в базе. В процессе разработки последней версии когда, что то меняешь в базе, добавляешь файл с изменениями и в эту папку.
Типа такого:
DbMigrations\
v1.1\
v1.2\
чтобы было понятно что ты в базе менял в последнем релизе
Артем Золин, нет, но если мне надо будет его поменять, то я выгружу сайт к себе на комп и поменяю. Просто если у меня проект лежит на компе давно и его верстка актуальна, то бд могла все это время меняться, из-за этого мне придется опять выгружать весь сайт с бд. Просто хочется делать это все одной кнопкой или как то проще. Сейчас я экспортирую через плагин all in one wp import, но это все долго и как-то не профессионально. Сергей delphinpro, это лишь пример, даже если мне нужно какие то поля новые создать через админку, то большую часть времени займет именно выгрузка сайта и его миграция.
godsplane, в случае обычных систем типа WP/Joomla/Modx и т.п., где нет никакх механизмов миграций:
если мне доступна БД и она не очень велика, я делаю дамп на проде и загружаю себе на локалке. Обратно так ни в коем случае не делаю. Только руками.
если недоступна, обхожусь тем, что уже есть в локалке, при необходимости внося правки через админку руками.
Да, это долго, неудобно и вообще треш. Но лучше так, чем накосячить на проде. К тому же время оплачивается =)
Если разработка на чем-то вроде laravel, то тут подобные вопросы даже не стоят. Рефрешнул миграции, засидил базу фейками и сидишь спокойно пилишь фичу. Запилил - коммит, пуш, деплой на серваке, пьёшь кофе.
Эти подходы не только для крупных проектов, они вообще для любых проектов.
БД обновляется через миграции. То есть, вы пишете SQL-скрипты, которые нужно выполнить в БД (создание новых таблиц, новых колонок, добавление записей в справочные таблицы, удаление ненужных более колонок и т.д.), а система миграции (вот не в курсе есть ли такая у WP, но совершенно точно есть у более продвинутых Laravel/Doctrine) контролирует что скрипты миграций были выполнены (и выполнены в правильном порядке). Можно скрипты прокатывать и руками, но в таком случае всегда есть вероятность ошибки.
Разделение исходного кода и собранного кода. У вас есть исходный код и работает разработчик с исходным кодом проекта. Тут путаница возникает в том числе потому, что у PHP исходный код и исполняемый код - суть одно и тоже. Но концептуально разделять это стоит. После того как исходный код написан, выполняется сборка (в частности на этом этапе отрабатывают SCSS/gulp/webpack и т.п. инструменты) и получается код для загрузки на сервер. Поэтому задача "поменять цвет кнопки" решается изменением одной строчки в исходном коде, затем пересборкой и перезаливкой собранного кода на сервер
Пересборку и перезаливку можно делать вручную. Но лучше если этим будет заниматься CI-сервер. Бесплатно CI предоставляет, например, гитлаб. Насчет гитхаба/битбакета не в курсе, не интересовался. Суть в том, что при изменении исходного кода в репозитории, автоматически (или вручную) запускается некоторый процесс (pipeline), выполняющий сборку-тестирование-деплой новой версии. Разумеется, чтобы это все работало сначала придется потрудиться, разобраться, написать нужные скрипты и конфиги. Но для большого проекта это незаменимый инструмент.
Простой
