Непрерывная интеграция/развертывание и базы данных

Question

У меня есть проект Laravel (API для приложения iOS), и в настоящее время я устанавливаю сервер непрерывной интеграции (Jenkins) для обработки развертываний в AWS. Для этого я использую такие инструменты, как Capistrano, Packer и Terraform.

И в настоящее время приложение имеет две среды: постановка и производство.

Тем не менее, я пытаюсь найти хороший способ работы с базами данных в этой системе.

В принципе, я себе трубопровод нечто вроде:

1. Извлекает код
2. запускать тесты
3. развертывания Поэтапное МАСС и стоячую новой инфраструктуры
4. QA и развертывание МАСС производства

Тем не менее, между этапами 3 и 4 мне бы хотелось сделать «сухой ход» производственного развертывания - wh Это означает, что вы пытаетесь выполнить миграцию и имеете доступ к потенциально большому набору данных, который будет иметься в производстве.

Так что я вижу 2 варианта:

1) Когда мы готовы QA, экспортировать Продукцию БД и импортировать его в постановщики. Затем запустите «процесс» (миграции, terraform, упаковщик и т. Д.). Если все пойдет хорошо, то перейти к производству

ПРОФИ:

• Вы все попробовать на прямом наборе данных производства, поэтому у вас есть уверенность вещи будут работать
• Вы работать с большие наборы данных и проверить, есть ли какие-либо узкие места в результате там быть большое количество записей, по сравнению с типичной промежуточной средой

СВОДОМ:

• В конце концов, производственная база данных может быть очень большой, и экспорт это ежедневно или несколько раз в день, может стать очень медленным
• Аналогично выше точки, это делает для очень медленной непрерывной интеграции

2) Вместо импорта из производства напишите конфигурируемые сеялки для всех моделей баз данных и запустите их по мере необходимости для обеспечения качества.

ПРОФИ:

• Вы можете Seed базы данных с малыми или очень большими наборами данных, в зависимости от ваших потребностей для конкретного развертывания
• сеялок только простой сценарий и могут быть запущены очень быстро

СВОД:

• Вы должны постоянно обновлять сеялки при любых изменениях Модели, которые вы делаете.

• В общем, этот процесс кажется более подверженным человеческой ошибке, чем экспорт фактического набора данных из Production.

Как люди в целом подходят к этому процессу?

Answer 1

Ваша промежуточная среда хочет выглядеть так же, как производство, если это возможно, иначе она будет поражать ее, потому что это будет трудно выполнить QA или использовать ее для фактического тестирования, вы не собираетесь нарушать производство.

Таким образом, миграция базы данных должна перемещаться вместе с кодом, и любые изменения, внесенные вами в базовую схему, должны выполняться одновременно с кодом, который использует эти изменения и, таким образом, распространяться по конвейеру CI в одно и то же время.

Что касается фактических данных, мы делаем регулярные снимки наших баз данных (работает на RDS в AWS), а затем восстанавливаем их в наших «похожих» средах. Это означает, что наши тестовые среды имеют одинаковое количество данных для производства, поэтому мы можем видеть влияние таких вещей, как миграция базы данных, и сколько времени требуется на выполнение до того, как он достигнет производительности.

У нас также есть несколько срезанных сред для запуска расширенного набора автоматических тестов, но у них минимальные сгенерированные данные, которых достаточно для запуска тестов.

В нашем случае мы также обработки личной информации, чтобы наш процесс снимка на самом деле немного более запутанный, поскольку мы также рандомизациям любых потенциально важные данных, создавая новые имена и контактные данные и т.д.

Для вас это, вероятно, придут вплоть до того, насколько больно реально восстанавливать данные с производства. Я бы сказал, начните с этого, и когда он станет слишком болезненным или медленным, подумайте о том, чтобы перейти к созданию набора данных и убедиться, что он имеет размер, достаточно большой, чтобы имитировать производство или дать вам хорошее представление о реальном мире.

Так что в вашем случае я бы начать что-то вроде этого:

1. Дженкинс улавливает изменения кода (например, сливает освоить в Git).
2. Модульные тесты выполняются в памяти в Дженкинсе.
3. Зеленая сборка затем запускает сборку с упаковщиком AMI, которая затем помечена соответствующим образом.
4. У Дженкинса тогда есть Terraform, создайте свою промежуточную среду, используя самый последний (очищенный при необходимости) снимок от производства и новый AMI, который автоматически подбирается с использованием источника данных aws_ami.
5. Если ваше тестирование проходит этот этап, вы можете запустить развертывание производства, в котором Terraform заменит старый AMI новым AMI.

Я предложил бы использовать синий/зеленый развертывает свернуть свой новый AMI с использованием стратегии, такие как указано here но это отдельный вопрос сам по себе (с большим количеством ресурсов, в других местах).