Станислав

Мы gamedev, у нас docker + hetzner'овские сервера. Настроили CI\CD так, что тестируем именно тот самый образ, который уйдет на продакшн и это избавило нас от бесконечной головной боли.
Меня в свое время вдохновили статьи от Альфа.Лаборатории - ссылку не привожу, как и они так и ваша статья - сейчас это все безнадежно устарело. Наш опыт уже около 1.5 года, полет нормальный - проблемы были больше от непонимания. Оркестрация досихпор самописная на ansible, смотрим в сторону kubernetes.

Можно поинтересоваться, чем не устраивают те CMS, которые уже есть на рынке? Даже бесплатные. Не проще ли какую-то из них допилить по личные нужды?

$4000 - это два месяца работы среднего (неплохого) PHP программиста. На фрилансе может даже быть и три месяца. Что можно успеть сделать за три месяца одному программисту? Правильно, кое-какой блоговый движок. Оно вам надо? Для разработки полноценной cms, которую еще можно будет впихнуть какому-нибудь бизнесу надо не меньше $100 000.

Миграции.

Идея миграций - вынести создание и изменение структуры бд в программный код. Одно изменение - одна миграция. Миграции имеют порядковый номер и соответственно выполняются друг за другом согласно порядковому номеру, где-то в системе всегда хранится номер миграции, которая была применена последней.

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

Разработчики должны изменения структуры/наполнение бд делать только миграциями.

Опять же для CodeReview миграции просто отличный инструмент.

Для PHP
Например в Yii:
www.yiiframework.com/doc/guide/1.1/ru/database.mig...

Как отдельно решение
https://github.com/ruckus/ruckusing-migrations

Для Python:
https://pypi.python.org/pypi/alembic

bash:
https://github.com/dwb/dogfish/blob/master/dogfish

вам нужно синхронизировать структуру базы между разработчиками? Миграции... и все... храните их в git, если кто-то поменял структуру базы - пишется миграция (а еще лучше менять базу только миграциями) и пушится, остальные разработчики забирают себе изменения и после каждого пула/мерджа делают migration up. Можно даже на пост-хуки повесить.

Синхронизация же данных между разработчиками ненужна. Если и должны быть какие-от обязательные данные - их можно опять же в миграцию запихнуть.

Используйте Gearman. Он предельно прост в использовании и удобен. Ставите расширение для PHP, пишете воркеры ваши и все. Может хранить очереди в MySQL.

Если тегов немного — попробуйте битовую маску, она работает очень быстро