Править боевой отчёт прямо в проде — как менять колесо на ходу. Рано или поздно сломаешь то, чем пользуются люди. Зрелая эксплуатация разделяет среды: разработка → тест → прод. В Power BI Service это поддержано встроенным механизмом — deployment pipelines.
Организационный слой: как изменения в модели и отчёте безопасно доезжают до пользователей. Требует Premium/PPU/Fabric-ёмкости.
Три этапа
Pipeline связывает три рабочие области одного содержимого:
- Development (разработка) — здесь авторы свободно меняют модель и отчёты;
- Test (тест) — сюда продвигают готовое для проверки: данные побольше, смотрят согласующие/QA;
- Production (прод) — то, что видят пользователи; меняется только через продвижение из теста.
Контент продвигают (deploy) слева направо: dev → test → prod. Прямые правки в проде исключаются как практика.
Разделение сред отвечает на вопрос «а не сломаю ли я то, чем пользуются?». В dev экспериментируют, в test проверяют на близких к бою данных, в prod попадает только проверенное. Pipeline делает это продвижение управляемым и наглядным — видно, что и куда уехало.
Сравнение этапов
Между этапами pipeline показывает что отличается: какие отчёты/модели изменены, добавлены или удалены по сравнению с соседней средой. Перед продвижением видно, что именно поедет в прод, — не «вслепую».
Параметры подключения (deployment rules)
Главная тонкость: в dev модель смотрит на тестовую БД, а в проде должна смотреть на боевую. Чтобы при продвижении не тащить «адрес dev-базы» в прод, задают правила привязки (deployment rules): «на этапе prod источник данных = боевой сервер, такие-то параметры». При деплое Service сам подменяет подключение.
Продвижение переносит содержимое (модель, меры, отчёты), а параметры окружения (строки подключения, значения Power Query-параметров) на каждом этапе свои и закреплены правилами. Это тот же принцип, что в обычной разработке: один артефакт — разные конфиги по средам.
Связь с .pbip и Git
Deployment pipelines — это «среды внутри Power BI Service». Их дополняет версионирование исходников в Git через формат .pbip (следующий урок): Git хранит историю и ревью изменений как код, а pipeline проводит собранный результат по средам. Зрелый процесс использует оба.
Самая дорогая ошибка эксплуатации — «быстренько поправлю прямо в проде». Без сред любая правка сразу у пользователей, откатить нечем, тестировать негде. Даже если pipeline пока недоступен (нет нужной ёмкости), заведите хотя бы две рабочие области руками — «разработка» и «прод» — и переносите осознанно, а не редактируйте боевое вживую.
Что дальше
Среды и продвижение настроены. Дальше — как хранить и ревьюить сами исходники модели как код: Git-интеграция и .pbip. Следующий урок.