конфликты мерджей очень сильно тормозят
1) Дробите задачи, делайте ветки короткоживущими
2) Хорошая идея делать ребейз принятых веток
3) Попробуйте адаптировать под себя git-flow, как альтернатива хорошо себя показывает feature-toggles вместо feature-branches
Да и бд экспорт/импорт постоянно приходится делать.
1) Миграции
2) Старайтесь делать миграции так, что бы они не ломали предыдущие релизы. Ну мол если вам надо добавить колонку, хорошей мыслью будет в первом релизе сделать ее nullable что бы старая версия приложения еще могла работать с новой версией базы, и потом уже следующим релизом добивать этот кусок. Основная идея - желательно что бы две последние версии приложеньки могли работать с последней версией базы данных. Если у вас база нормализована нормально, то проблем с этим быть не должно.
Если второй пункт соблюдается то вакатка новых релизов будет происходить по такому алгоритму:
- выкатывается новый билд приложеньки в отдельную директорию (можно автоматизировать, организовать ротацию билдов и т.д.)
- накатываем миграции на базу, в этом случае у нас старая версия приложения будет работать с уже новой структурой базы
- переключаем webroot на новую версию. В случае с контейнерами (docker) тушим старый контейнер
- если что-то идет не так, мы можем быстро поменять симлинк обратно и запустить откат миграции
При таком сценарии даунтайм будет минимальным.
вопрос с выкатыванием новых релизов
Вот вам варианты в порядке сложности и мощности (от простого к сложному).
- capistrano/capifony
- ansible/puppet/chief/etc
- docker + docker-machines + docker-compose
Ну и да, тесты тесты тесты. Все самое критичное должно быть покрыто хотя бы интеграционными/функциональными тестами. В идеале же вся бизнес логика должна быть покрыта быстрыми юнит тестами и UI/инфраструктура функциональными (читать про пирамиду тестирования).
