Как развернуть сценарии SQL через Azure CI/CD?

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

1. Управления источником — вам нужно будет поместить свои скрипты в систему управления версиями. Если вы используете Azure DevOps, используйте репозиторий Git для хранения всех созданных сценариев. Более того, они нужны нам в системе контроля версий, чтобы наш инструментарий CI/CD мог это сделать. Если вы администратор баз данных и это звучит для вас странно, извините, вам придется к этому привыкнуть.

   1б. Включить запросы на вытягивание — Настройте исходный репозиторий так, чтобы он принимал изменения только из запроса на включение. Это гарантирует, что ваши изменения схемы проверяются до того, как они будут приняты в репозиторий. Улучшает обмен знаниями в команде и повышает общее качество, поскольку может обнаруживать ошибки до их развертывания.

2. Безопасность — заблокируйте вашу базу данных, чтобы случайные пользователи не могли вносить случайные изменения. Создайте специальную учетную запись для применения изменений схемы базы данных и предоставьте учетные данные только инструменту непрерывной доставки. В этой модели, если он не находится в системе контроля версий, он не существует. Наш инструмент CI/CD будет отвечать за развертывание этих изменений для нас.

3. Используйте инструмент - и хватит делать это вручную! Наша команда выбрала платформу с открытым исходным кодом под названием БД-мигрировать, которая управляет изменениями в схемах базы данных. Мы выбрали db-migrate, поскольку он имеет открытый исходный код и работает на разных платформах. Microsoft использует EntityFramework Code-First миграции, на котором основана db-migrate.

   Как работает миграция: по сути, каждый раз, когда вам нужно изменить базу данных, вы создаете «миграцию», которая включает изменения вашего SQL-скрипта. Когда инструмент работает с вашей базой данных, он создает таблицу в базе данных, чтобы отслеживать, какие миграции были запущены ранее, поэтому он запускает только новые миграции. Короче говоря, миграции должны быть неразрушающими, чтобы предотвратить потерю данных, а сценарии следует считать доступными только для чтения после их применения к любой базе данных. (Вы никогда не должны изменять скрипт миграции sql после того, как он был использован; вместо этого создайте новую миграцию)

4. Непрерывная интеграция — каждый раз, когда новая миграция регистрируется в системе управления версиями, ваш CI-сервер упаковывает сценарии как артефакт для следующего этапа.

5. Непрерывная доставка — система непрерывной доставки берет артефакт сборки и запускает инструмент db-migrate (node.js) для каждой целевой среды. Инструмент CD использует выделенную учетную запись пользователя SQL, которой разрешено вносить изменения в схему базы данных. Как показано в № 2, это должен быть единственный способ развертывания изменений.

ОБНОВЛЕНИЕ: Использование Entity Framework

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

1. Используйте миграция.exe для выполнения миграции — этот инструмент поставляется с EntityFramework, и в качестве шага развертывания можно будет вызвать миграцию кода в первую очередь. Это было бы очень похоже на то, как я использую db-migrate выше.

2. Скрипт миграции во время запуска приложения — вы можете написать код в логике инициализации вашего веб-приложения в выполнить любые незавершенные миграции. Это, пожалуй, проще всего реализовать, но для этого требуется, чтобы вы запускали приложение с учетной записью базы данных, имеющей неограниченный доступ. Кроме того, если возникнет проблема с миграцией базы данных, вы не узнаете об этом до тех пор, пока приложение не будет развернуто. С точки зрения CI/CD, я хотел бы отказаться от развертывания и, возможно, отката, прежде чем полностью испортить сайт.

3. Настройка профиля публикации — вы можете настроить профиль публикации как изложено в этой статье для «Обновить базу данных». Это эффективно добавляет databaseInitializer в файл web.config для обновления базы данных при запуске приложения. Это имеет аналогичные недостатки, но, по крайней мере, позволяет вам иметь другую учетную запись пользователя для применения изменений базы данных.

Обратите внимание, что вполне возможно встроить ваши хранимые процедуры в качестве ресурсов в ваши миграции, а затем просто вызвать необработанные операторы sql из миграции:

Базовая миграция:

/// <summary>
/// Custom DbMigration with helper methods
/// </summary>
public abstract class BaseDbMigration : DbMigration
{
    /// <summary>
    /// Apply a SQL statement stored in an embedded resource
    /// </summary>
    /// <param name = "resourceName"></param>
    protected void SqlFromEmbeddedResource(string resourceName)
    {
        Assembly assembly = typeof(BaseDbMigration).Assembly;

        string baseNamespace = typeof(BaseDbMigration).Namespace;

        resourceName = baseNamespace + "." + resourceName;

        bool exists = assembly.GetManifestResourceNames().Where(r => r == resourceName).SingleOrDefault() != null;

        if (exists)
        {
            string sql = null;

            using (var stream = assembly.GetManifestResourceStream(resourceName))
            {
                var reader = new StreamReader(stream);
                sql = reader.ReadToEnd();
            }

            base.Sql(sql);
        }
    }
}

Пример миграции:

/// <summary>
/// Migration: Deploy Stored Proc
/// </summary>
public partial class CalculateTotalsV1 : BaseDbMigration
{
    /// <summary>
    /// </summary>
    public override void Up()
    {
        base.SqlFromEmbeddedResource("sp_CalculateTotals.v1.Up.sql");
    }

    /// <summary>
    /// </summary>
    public override void Down()
    {
        base.SqlFromEmbeddedResource("sp_CalculateTotals.v1.Down.sql");
    }
}

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