@evilelf
Тупой, руки из жопы, кодю за зп и т.п. и т.д.

Как правильней сделать быстрое выкатывание в продакшн?

Коллеги, всем доброго воскресенья.

Кто как решает вопрос с выкатыванием новых релизов (кода и|или бд) в живой проект?

Юзаем сейчас git, но конфликты мерджей очень сильно тормозят и пользователи не годуют :(
Да и бд экспорт/импорт постоянно приходится делать.

Всем спасибо за ответы.
  • Вопрос задан
  • 1787 просмотров
Решения вопроса 1
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
конфликты мерджей очень сильно тормозят

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/инфраструктура функциональными (читать про пирамиду тестирования).
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
alexclear
@alexclear
A cat
> Юзаем сейчас git, но конфликты мерджей очень сильно тормозят и пользователи не годуют :(

Судя по этой фразе, вы что-то делаете не так.
Вы что, выполняете мерджи прямо на продакшн машине? Иначе, откуда пользователи знают, были у вас конфликты мерджей, или нет?
Есть ли у вас тестовая среда, в которую вы выкладываете ветку до того, как она попадет в продакшн? Если нет - обязательно внедрите.
Если ли у вас автоматическое тестирование? Если нет никакого, внедрите хотя бы базовые смок тесты.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы