Есть два способа избегать неприятностей подобного рода:
- Мотивировать команду быть сосредоточенными при обновлении, составить пошаговый план и не пропустить всех пунктов сценария обновления;
- Максимально автоматизировать процесс обновления production-сервера проекта, тем самым снизить роль человеческого фактора.
Одной из наших специализаций является разработка проектов на платформе “1С Битрикс”. Решения по развороту и обновлению продукта не входят в коробку. Проанализировав доступные решения на тот момент, мы пришли к выводу что подходящих не существует и для необходимой автоматизации придется реализовывать решение самостоятельно.
Если проблему обновления исходного кода за нас решает система версионирования, то с базой данных дела обстоят иначе. Наиболее популярным решением обновлений баз данных являются
Так вышел на свет наш
За миграцию отвечает программист. Модуль миграций используется как инструмент, не пытаясь возложить на себя ответственность по развороту конкретных данных и схем. Процесс каждой миграции запускается исходным кодом. Модуль только определяет очередность выполнения.
Для каждой миграции можно задать примерное время выполнения. Перед обновлением это время можно просуммировать и определить длительность сессии обновления. Это очень важно при обновлении production-сервера проекта. К примеру, если у вас есть список миграций которые обновляются два часа, то лучше запускать обновление ночью, если же время не превышает и одной секунды, то можно смело обновиться и днем.
Такая потребность возникла в тот момент, когда миграции повсеместно стали использоваться и как инструмент актуализации данных. Например, обратиться к внешнему источнику и обновить контент у себя на проекте. Такие сценарии нужны для одноразового использования на проекте и миграции как нельзя лучше подходят на эту роль. Они гарантируют что исходный код одной миграции будет выполнен только один раз. Правда такие миграции как раз и мешают при большом обновлении, потому что их время выполнения обычно большое, а в очереди стоят миграции которые работают со схемой данных без выполнения которых проект просто не будет работает. Тут и возникло решение внедрить понятие приоритета выполнения. Таким образом миграциям, которые меняет схему данных проекта, программист должен установить наивысший приоритет, что обеспечит их немедленное выполнение, а “долгие” миграции будут выполняться уже после. Такое решение обеспечило необходимую стабильность обновлению.
При выпуске первого модуля мы не уделили терминалу должного внимания и все управление миграциями реализовали через web интерфейс. Это была еще одна наша ошибка, так как web интерфейс не обеспечивает нам необходимой стабильности. При обновлении разработчик в основном взаимодействует с системой через ssh-интерфейс: он обновляет исходный код, обновляет сторонние библиотеки и web-интерфейс миграций данных нарушал эту единую точку входа. Теперь основная работа с миграциями организована через консоль, со множеством удобной информации,что обеспечивает единый интерфейс и повышает устойчивость обновления проекта.
Решение доступно каждому желающему