.pbix — бинарный файл-«чёрный ящик»: его нельзя осмысленно сравнить в Git, нельзя сделать ревью «что изменилось в мере», двое не могут работать параллельно. Решение — формат .pbip, который раскладывает проект в текстовые файлы. Это открывает нормальную разработку: ветки, диффы, ревью, CI/CD.
Форматы файлов (PBIX/PBIT/PBIP/TMDL/PBIR) подробно разбирались в продвинутом курсе. Здесь — как на .pbip строится командный процесс с Git.
Что даёт .pbip
Power BI Project (.pbip) сохраняет отчёт и модель не одним бинарником, а папкой текстовых файлов:
- модель — в формате TMDL (Tabular Model Definition Language): таблицы, связи, меры — читаемым текстом;
- отчёт — в формате PBIR: страницы и визуалы как структурированные файлы.
Текст → Git видит каждое изменение построчно.
Бинарный .pbix в Git — это «файл изменился целиком», без деталей. Текстовый .pbip даёт осмысленный дифф: видно, что в меру [Выручка] добавили DIVIDE, а связь стала неактивной. Появляется то, без чего нет инженерной культуры: code review, история «кто и зачем», слияние веток.
Рабочий цикл с Git
- Включить Power BI Project (.pbip) в настройках Desktop (preview-возможность исторически) и сохранить проект в репозиторий.
- Под задачу — ветка; правки модели/отчёта коммитятся как обычный код.
- Pull request с ревью: коллега видит дифф TMDL/PBIR, обсуждает, одобряет.
- Слияние в основную ветку — единый источник истины.
Внешние правки файлов .pbip (слияние ветки, ручная правка TMDL) Power BI Desktop подхватывает только при переоткрытии. Правило: закрыть проект → внести/слить изменения → открыть заново. Не редактируйте файлы проекта, пока он открыт в Desktop, — рассинхронизируете состояние.
Fabric Git integration
В Microsoft Fabric / Power BI рабочую область можно напрямую связать с веткой Git (Azure DevOps, GitHub): содержимое workspace синхронизируется с репозиторием. Изменения в Service видны в Git и наоборот — версионирование без ручного экспорта.
CI/CD: автоматический деплой
На текстовом проекте строится конвейер:
- по коммиту/PR пайплайн (Azure DevOps, GitHub Actions) проверяет модель — линтинг, best-practice-правила (например, через скрипты Tabular Editor);
- после одобрения — деплой в нужную среду через XMLA/Fabric API или через deployment pipeline (прошлый урок).
Не путайте: Git/CI-CD отвечает за исходники и историю (что в модели, кто менял, прошло ли ревью). Deployment pipelines — за проведение по средам (dev→test→prod в Service). Зрелый процесс совмещает обе оси: код живёт и ревьюится в Git, а собранный результат катится по средам пайплайном.
Реалистично о пороге входа
Это инженерный процесс: нужны Git, навыки веток/PR, договорённости команды. Для одного автора и пары отчётов — избыточно. Внедряют, когда моделей много, авторов несколько, а цена ошибки в проде высока. До этого хватает аккуратного хранения .pbix/.pbip с версиями в имени и ручного переноса.
Что дальше
Исходники под контролем версий. Дальше — как понимать, что происходит с отчётами в эксплуатации: мониторинг, метрики использования и аудит. Следующий урок.