Как вести разработку уже рабочего проекта (в продакшене)?

Question

[yutupucole]

Здравствуйте!
Есть проект, уже разработанный, уже работающий в продакшене. Но так же требуется его дальнейшая доработка, добавление функционала и т.д. Естественно заниматься тестированием проекта прямо в продакшене будет глупо, пользователи будут видеть постоянные изменения или ошибки.
Создавать отдельный сервер более подходящий вариант. Но есть свои нюансы, а именно:
- У тестового сервера не будет оригинального домена, а то есть часть функционала работать уже не будет. Если регистрировать отдельный домен тестовый, то придется менять конфиги и каждый раз менять обратно при публикации в продакшен.
- Есть база данных, которая естественно во время разработки, на продакшене будет дополняться записями, а тестовая БД не будет иметь этих записей, т.е. получается каждый раз придется интегрировать измененную структуру БД в продакшн.

Проект работает на Yii2, MySQL, debian squeeze
Пожалуйста, дайте дельный совет, как все таки заниматься разработкой безопасно для пользователей и для самого проекта?

Comments

[shqn]

А можете привести пример функциональности, которая зависит от домена?

[yutupucole]

shqn: например принятие API оплаты, почта с обратными DNS записями

[Алексей Немиро]

shqn: платежные шлюзы, некоторые внешний сервисы с привязкой к ip, страницы обратного вызова и т.п.

Answer 1

[index0h]

1. Vagrant, или docker с системой максимально похожей на production сервер. Разработку ведем там.
2. Если никакая vcs не используется - пи"№;ц конечно, но быстро подключайте, иначе бида обеспечена. Рекомендую git + git-flow.
3. Правки в БД ТОЛЬКО на основе миграций, при этом создавайте как up, так и down.
4. Возьмите готовую систему для диплоя, либо напишите свой скрипт для этого. Цель в том, что бы минимизировать человеческий фактор при обновлении продакшна на столько, на сколько это возможно.
5. Все, что находится в /vendor - обязательно должно быть заигнорировано в vcs, composer.json И composer.lock (спс OnYourLips) должен ссылаться на фиксированные версии пакетов.
6. Код ОЧЕНЬ-ОЧЕНЬ-ОЧЕНЬ желательно покрыть тестами. Самый кульный вариант - запуск тестов после push изменений в главный репозиторий. Для этого можно использовать связку gitlab + gitlab-ci.
7. На счет доменов - в чем проблема то? Вынесите домен в конфигурацию, и создайте конфиги для локального, тестового и боевого окружений.
8. На счет записей в БД: да, они обязаны отличаться. По хорошему на проде руками в принципе можно только смотреть, а записывать нельзя. Для тестовой БД - пишите фикстуры.
9. сразу подумайте на счет логов: если их over-дофига, имеет смысл использовать системы типа logstash, или sentry.

Comments

[index0h]

OnYourLips И то И другое)) в случае работы в команде - обязательно кто-то по ошибке да закоммитит))

[index0h]

Да я и не спорю, но composer.lock генерируется на основе composer.json, по этому коммитить нужно оба.

Answer 2

[Макс Сысоев]

Разработку вести локально, это 100%.

Изучите Vagrant \ Docker, это поможет вести разработку на локальной машине с изоляцией рабочих проектов.

Насчёт изменения базы данных - в Yii есть миграции, изучите их.

Answer 3

[may-cat]

Когда делали проект - надо было учитывать это и делать домены и прочее настраивыми.

Но вообще домены можно экранировать, подменять. Если у вас на win-машине будет прописано в hosts.txt, что домен microsoft.com ведёт на айпишник 213.180.193.3, то запросы до серверов майкрософта даже не дойдут - сразу улетят в яндекс. Этого приёма достаточно в вашем случае, хотя он и создаст определённые трудности.

Comments

[may-cat]

Про изменения в базе данных в Yii - смотрите главу про миграции в доках по Yii. Удивительно, что вы с этим ещё не сталкивались - это одна из сильных сторон Yii.