Latest / M365.FM – подкаст о Microsoft 365, Copilot и ИИ на русском / ALM для Power Platform с GitHub Actions: исходники, сборка, тесты и развёртывание без гаданий (ИИ-дубляж)

Transcript

ALM для Power Platform с GitHub Actions: исходники, сборка, тесты и развёртывание без гаданий (ИИ-дубляж) · M365.FM – подкаст о Microsoft 365, Copilot и ИИ на русском

• 0:00
  Готовы к 10 дням погружения в Microsoft 365, Капайлот и Азур и знакомство с людьми,
• 0:06
  формирующими будущие работы. В этом январе М365 Кон возвращается, и мы берем новую планку.
• 0:12
  Присоединяйтесь к нам для участия в живых сессиях, демонстрациях реальных кейсов и получения
• 0:16
  практических знаний от MVP и экспертов со всего мира. Никаких общих слайдов,
• 0:20
  никаких бесконечных модных словечек. Мы решаем реальные задачи, Капайлот Студия,
• 0:24
  и агенты, фабрик, безопасность, управление и автоматизация. Независимо от того,
• 0:30
  являетесь ли вы это специалистом, разработчиком или бизнес-лидером, у нас найдутся сессии
• 0:34
  специально для вас. За 10 полных дней вы сможете изучить множество технологий и пообщаться с
• 0:39
  мировым сообществом. Смотрите в прямом эфире и используйте полученные практические идеи в своей
• 0:44
  организации. Январь 2027 года, 10 дней, одно сообщество Microsoft. Регистрация уже открыта.
• 0:51
  Забронируйте свое место сегодня. Это m365con.net. Присоединяйтесь на m365con.net.
• 1:03
  Увидимся в прямом эфире в январе. Вам когда-нибудь казалось, что развертывание в Power Platform — это
• 1:07
  черный ящик? Вы выпускаете обновление, затаив дыхание, и просто надеетесь, что оно заработает в
• 1:11
  средах разработки, тестирования и продакшена. Что, если бы вы могли реально контролировать и видеть
• 1:16
  каждый этап процесса ALM с помощью GitHub Actions, забыв о догадках и ручных заплатках?
• 1:21
  Давайте приоткроем завесу и посмотрим, как связаны компоненты, контроль версий,
• 1:26
  автоматизация и безопасные переменные. Это не просто очередное пошаговое руководство. Это-то,
• 1:30
  о чем умалчивают большинство гайдов, чтобы ваше следующее развертывание не заставляло вас гадать.
• 1:35
  Итак, почему ALM в Power Platform кажется таким лабиринтом? Если вы когда-либо пытались развернуть
• 1:40
  Power App и чувствовали ту самую неуверенность, будто что-то важное ускользнуло от внимания,
• 1:45
  вы не одиноки. На бумаге Power Platform обещает простую разработку приложений,
• 1:49
  но за этим дружелюбным фасадом скрывается далеко не прямолинейный процесс ALM.
• 1:53
  Веб-приложение развертывается из системы контроля версий, собирается в конвейере и попадает
• 1:58
  в продакшен с предсказуемым поведением. Power Platform, напротив, скрывает половину логики
• 2:02
  внутри drag-and-drop интерфейсов, экранов, коннекторов и формул, которые невозможно увидеть в
• 2:07
  репозитории Git. Поэтому, даже если вы следуете каждому шагу из общих административных руководств,
• 2:11
  вы все равно столкнетесь со странными, труднодиагностируемыми с боями, когда критически
• 2:15
  важные приложения покидают среду разработки. Давайте взглянем на имеющееся руководство
• 2:19
  по ALM. Большинство из них просто объясняют, как экспортировать ЦИП-файл решения и импортировать
• 2:23
  его куда-то еще. Довольно просто, верно? Но ответ на вопрос, как это лишь один уровень?
• 2:27
  А вот, почему они опускают? Почему развертывание в Power Platform ломается так,
• 2:32
  как никогда не ломается обычный код? Именно это вызывает бесконечную путаницу.
• 2:35
  Корень проблемы в том, что логика, соединение и конфигурации в Power Apps хранятся не так,
• 2:40
  как классический программный код. Вы не просто клонируете репозиторий и запускаете модульные
• 2:45
  тесты. Поэтому, когда вы пытаетесь перенести приложение, все эти скрытые зависимости,
• 2:49
  подключение к Outlook, SharePoint или сторонней мапе не всегда аккуратно упаковываются в ЦИП-файл.
• 2:54
  Вот типичный сценарий. Вы создали отличное новое приложение, и оно работает в среде разработки.
• 2:58
  Вы экспортируете решение, импортируете его в тестовую среду, и внезапно поток перестает работать.
• 3:02
  Дело редко бывает только в самом файле. Проблема в том, что подключение указывают не туда,
• 3:06
  права доступа не совпадают, а политики данных блокируют соединения, которые еще минуту назад
• 3:10
  работали нормально. А теперь представьте, что это нужно делать для трех сред разработки,
• 3:15
  тестирования и продакшена, где у каждой свои подключения, политики защиты данных,
• 3:19
  согласующие лица и административные ограничения. Простым копированием здесь не обойтись.
• 3:23
  Исследования подтверждают то, с чем администраторы и разработчики сталкиваются каждую неделю.
• 3:28
  Большинство неудачных развертываний в Power Platform связаны с отсутствующими ссылками
• 3:31
  на коннекторы или неправильной настройкой переменных среды. Отсутствие ссылки на коннектор
• 3:35
  означает лишь то, что поток не может найти свое подключение к Outlook или Dataverse.
• 3:40
  В итоге, как только вы пытаетесь запустить приложение или поток в другой среде,
• 3:44
  вы получаете ошибки времени выполнения. А поскольку переменные среды в Power Platform работают
• 3:49
  иначе, чем в других продуктах Microsoft 365, на них спотыкаются даже опытные разработчики.
• 3:55
  Переменные предназначены для управления конечными точками, ключами или конфигурациями
• 3:59
  конкретного клиента. Но если кто-то забудет обновить их после экспорта решения,
• 4:03
  даже безобидное на вид изменения может вывести из строя работающие приложения.
• 4:06
  Многие из нас поначалу попадают в эту ловушку. Можно подумать, что экспорт цип архива
• 4:10
  решения включает все необходимое, но на самом деле он пропускает динамические ссылки на
• 4:14
  коннекторы. Например, допустим, у вас есть приложение, которое использует
• 4:17
  HTTP-коннектор для стороннего сервиса в среде разработки. При импорте в тестовую среду или
• 4:21
  продакшен именно этого экземпляра коннектора там не будет. Ссылка на коннектор внутри
• 4:25
  вашего приложения указывает на несуществующий объект, и потоки внутри решения тихо ломаются,
• 4:30
  пока пользователь или администратор вручную их не пересоздаст и не перенастроит.
• 4:34
  Если у вас несколько разработчиков или администраторов, становится еще проще потерять
• 4:38
  нить того, какая ссылка куда ведет, а никому не нужны разборы полетов в стиле. Но ведь в
• 4:43
  разработке все работало. Еще одна сложность — сервисные учетные записи. Большинство начинают
• 4:48
  с использования обычных учетных записей для экспорта и импорта решений, потому что так быстрее начать
• 4:53
  работу. Но при попытке автоматизации с помощью GitHub Actions или любой CI-системы использования
• 4:57
  личных учетных данных быстро заводят в тупик. Вы упретесь в ограничении прав доступа, иногда без
• 5:01
  четких сообщений об ошибках, или даже спровоцируете аудит соответствия требованиям, потому что
• 5:05
  выполняете критически важные развертывания под личной учетной записью, а не под той, что предназначена
• 5:09
  для автоматизации. Субъекты службы, по сути, идентификаторы приложений в Azure Ad, отвечают за все
• 5:14
  разрешения, ведение журналов и аудит, необходимые вашему конвейеру. Без них ваша цепочка автоматизации
• 5:20
  превращается в лоскутное одеяло из ручных передач задач, и вы никогда не узнаете, кто и что
• 5:25
  изменил. Контроль версий тоже становится непредсказуемым. В обычном коде у вас есть история коммитов
• 5:30
  и инструменты для поиска авторства изменений. Файлы решений Power Platform — это лишь снимки
• 5:34
  состояния, поэтому вам не хватает детализированного отслеживания изменений. Логика, скрытая в формулах
• 5:38
  экранов, холстовых приложений или в слабо документированных потоках, остается невидимой до следующего
• 5:43
  экспорта. Кто-то меняет настройку потока в интерфейсе, и попробуйте потом понять, почему нежестоящие
• 5:48
  среды вдруг ведут себя иначе. В итоге управление ALM для Power Platform похоже на сборку пазла,
• 5:54
  где половина деталей отсутствует или спрятана под коробкой. Невидимые зависимости, специфичные
• 5:59
  для среды коннекторы и переменные, которые нельзя увидеть в коде, нарушают привычный рабочий
• 6:04
  процесс разработчика. И это еще до того, как вы столкнетесь с тем, что в продуктивных средах почти
• 6:09
  всегда действуют более строгие права доступа, другие политики данных и аудиторские требования,
• 6:14
  неочевидные при разработке или тестировании. Но есть и положительный момент. Эта сложность
• 6:19
  не случайна. Существует практическая причина, по которой Power Platform обрабатывает исходный код,
• 6:24
  переменные и коннекторы таким уникальным образом. Она стремится позволить бизнес-пользователям
• 6:29
  создавать мощные приложения, не беспокоясь о написании кода. Побочный эффект заключается в том,
• 6:34
  что вам, как специалисту по автоматизации, нужно отслеживать то, что скрыто под капотом.
• 6:38
  Если вы знаете, где проходят эти невидимые связи, вы сможете исправить или избежать большинства ошибок,
• 6:44
  которые подрывают ALM в Power Platform. Если все это кажется слишком сложным, вы не ошибаетесь.
• 6:50
  Однако есть четыре столпа ALM, которые помогают распутать этот узел. Исходный код – сборка,
• 6:55
  тестирование и развертывание. У каждого из них в Power Platform есть свои особенности,
• 6:59
  но вместе они возвращают структуру в то, что иначе кажется хаосом.
• 7:02
  Базовая система ALM – исходный код – сборка, тестирование, развертывание.
• 7:06
  Всякий раз, когда кто-то просит создать конвейер Power Platform, который просто работает,
• 7:10
  на ум приходят эти четыре фундаментальных столпа – исходный код, сборка, тестирование,
• 7:14
  развертывание. В традиционной разработке вы могли бы делать это практически с закрытыми
• 7:18
  глазами. Power Platform не дает такой свободы. Внезапно исходный код перестает означать просто
• 7:24
  код. Это означает работу с файлами решений, экспорт заархивированных пакетов с приложениями,
• 7:29
  потоками и иногда коннекторами, которые выдают себя за часть исходного кода.
• 7:33
  Давайте начнем с основ, а затем разберем, что делает каждый столб таким необычным в этом мире.
• 7:38
  У вас есть ZIP-файл решения. Это не код в привычном понимании. Откройте его,
• 7:42
  и вас встретят файлы XML и JSON, а не логика, которую вы ожидаете увидеть в TypeScript или
• 7:47
  C-решетка. Но это и есть исходный код для Power Platform. Команды часто спотыкаются на этом этапе.
• 7:53
  Все выглядит портативно, пока не понимаешь, что большинство изменений, например,
• 7:57
  обновлений формулы или логики потока, не видны, пока не экспортируешь свежий цип файл решения.
• 8:02
  Да, вы можете версионировать эти файлы решений в Git, но если вы не дисциплинированы в плане
• 8:07
  экспорта после каждой правки, в истории будут огромные пробелы.
• 8:10
  Теперь перейдем к конфигурации. В обычных приложениях вы просто сохраняете строки
• 8:14
  подключения в файле конфигурации и считаете задачу выполненной. Power Platform же протаскивает
• 8:18
  данные, специфичные для среды, прямо внутри решений. Это не только переменные среды,
• 8:23
  но и ссылки на коннекторы, динамические конечные точки, роли и разрешения,
• 8:27
  упакованные вместе с бизнес-логикой. Если вы забудете обновить их перед экспортом и среды
• 8:32
  разработки или тестирования, вы зафиксируете указатели на неверные адреса.
• 8:36
  Я видел, как команды старательно коммитят цип файлы решений, а при развертывании обнаруживают,
• 8:41
  что половина приложения все еще обращается к тестовой датаверс, а не к продакшену,
• 8:46
  потому что никто не перенастроил ссылки. Затем у нас идет сборка, билл.
• 8:50
  Слово «сборка» обычно ассоциируется с компиляцией кода и зелеными галочками в CI-заданиях.
• 8:55
  В Power Platform процесс сборки – это хранение цип архивов, проверка схем и подтверждение
• 9:01
  зависимостей. В конвейере GitHub Actions задача сборки берет ваш закоммиченный файл решения,
• 9:06
  а затем использует CLI Power Platform от Microsoft для распаковки, проверки и повторной упаковки.
• 9:11
  На этапе проверки происходит либо чудо, либо хаос. Она может выявить нерабочие ссылки
• 9:16
  или неподдерживаемые действия. Хуже того, если изменения в потоке зависят от кастомного
• 9:21
  коннектора, который не попал в систему контроля версий, сборка молча упакует неполный продукт.
• 9:26
  Вот здесь все становится сложнее. Эти задачи сборки – это не столько компиляция,
• 9:30
  сколько организация надежного экспорта и гарантия того, что содержимое готово к поставке.
• 9:36
  Команды, которые пропускают или торопят этот процесс, быстро оказываются в ситуации,
• 9:40
  когда сборка технически успешна, но в UIT или продакшене не хватает половины задуманных функций.
• 9:44
  Microsoft продолжает продвигать мысль, что файлы решений делают ALM портативным,
• 9:49
  но здесь всегда есть «но». Портативность зависит от того, правильно ли настроены коннекторы
• 9:53
  и распределены роли между средами. Тестирование – это следующий важный этап.
• 9:57
  В конвейере веб-приложения автоматизированные тесты могут включать модульные тесты или проверку интерфейса.
• 10:02
  Что считать тестом в Power Platform – вопрос дискуссионный.
• 10:06
  Иногда это проверка решения, открывается ли оно и разрешаются ли ключевые зависимости.
• 10:12
  В других случаях это запуск тестовых потоков или проверка того, отвечают ли коннекторы в тестовой среде.
• 10:18
  Часто тестирование проводится вручную, поскольку проверка бизнес-логики внутри конвас-приложений
• 10:23
  еще не встроена в автоматизированные конвейеры.
• 10:25
  Однако можно автоматизировать проверки, находить отсутствующие коннекторы,
• 10:28
  тестировать критические потоки или пинговать среду тестирования, чтобы убедиться в работе учетных данных.
• 10:33
  Развертывание – самый болезненный этап.
• 10:36
  При развертывании обычного приложения вы можете просто отправить веб-артефакт в Азу.
• 10:40
  В Power Platform приходится настраивать соединения, назначать права, обновлять секреты,
• 10:44
  менять переменные среды и запускать импорт через субъект службу, а не обычную учетную запись.
• 10:49
  Иначе вы столкнетесь с проблемами при аудите и отказами в доступе.
• 10:53
  GitHub Actions может объединить этот процесс, но только если каждая задача знает,
• 10:57
  на какую среду нацелена и какие секреты использовать.
• 11:00
  Я видел, как команды пытались сэкономить время, используя одни и те же учетные данные для разработки и продакшена,
• 11:06
  что приводит к хаосу, утечкам данных, ошибкам доступа и с боям функций в отдельных средах.
• 11:10
  Вспомните команду, с которой я работал несколько месяцев назад.
• 11:13
  Они делали почти все правильно – стандартные гид-репозитории, версионные архивы решений и четкое ветвление.
• 11:18
  Но их конвейер постоянно ломался на этапе развертывания.
• 11:21
  Почему? Они не утруждались с заменой переменных среды или обновлением ссылок на коннекторы перед импортом в продакшен.
• 11:26
  В итоге ключевые потоки указывали не на те конечные точки, а данные попадали не в те системы.
• 11:31
  Решением стали скриптовые шаги в их GitHub-конвейере, которые подменяли переменные и перенастраивали все коннекторы при импорте.
• 11:38
  Собственные рекомендации Microsoft говорят об этом прямо.
• 11:40
  Используйте файлы решений для перемещения объектов между средами, но всегда учитывайте ссылки на коннекторы и сопоставление ролей в вашем конвейере.
• 11:48
  Они подчеркивают, что пропуск этих шагов – главная причина поломки приложений, особенно в сильно защищенных средах.
• 11:54
  Когда вы воспринимаете исходный код, сборку, тестирование и развертывание как взаимосвязанные части, а не изолированные этапы, проще понять,
• 12:01
  почему многие попытки внедрения ELM проваливаются и как решать проблемы, а не просто надеяться на удачу.
• 12:06
  Далее мы разберем, как GitHub Actions координирует этот процесс, трикгеры, ветвление и разделение задач, делая автоматизацию Power Platform гибкой и безопасной.
• 12:17
  GitHub Actions соединяем все воедино с помощью триггеров и задач.
• 12:20
  Если вы хоть раз ждали завершение конвейера GitHub Actions после обновления Power App, то знаете, что автоматизация – это не мгновенно и точно не магия.
• 12:29
  Большинство команд сталкиваются с этой реальностью сразу после восторга от первого запуска рабочего процесса.
• 12:34
  Вы настраиваете скрипт, подключаете его к репозиторию и ждете, что каждый новый коммит будет гладко разворачиваться во всех средах.
• 12:41
  А потом наступает суровая реальность.
• 12:43
  Вместо простого запуска скрипта, GitHub Actions использует логическую цепочку, построенную на триггерах, заданиях и передаче данных между средами.
• 12:51
  Этот порядок и структура позволяют развертыванием не превращаться в путаницу из неудачных шагов и странных ошибок.
• 12:56
  Отправной точкой в этой системе является триггер.
• 13:00
  Большинство новичков создают рабочий процесс, который запускается при каждом пуш или при слиянии пул-рекист в основную ветку.
• 13:07
  На первый взгляд, это кажется лучшей практикой.
• 13:10
  Почему бы не запускать конвейер каждый раз, когда вносятся изменения?
• 13:12
  Но есть один нюанс.
• 13:13
  Когда вы устанавливаете триггер только на основную ветку, все проходит через один канал.
• 13:17
  Что, если изменения должны попасть в разработку, но не в тестирование или продакшн?
• 13:20
  Что, если вы готовы к развертыванию в продакшне, но в тестовой среде еще идет проверка?
• 13:24
  Команды, которые используют универсальные триггеры, часто сталкиваются с проблемами,
• 13:29
  когда функции для разработки попадают в продакшн или тестовые развертывания внезапно переопределяют рабочие настройки.
• 13:34
  Вы можете разделить рабочие процессы для каждой среды, разработки, тестирования и продакшна,
• 13:39
  и настроить специфические триггеры для каждой из них.
• 13:42
  Например, настройте процесс, который запускается только при пуш в ветку разработки,
• 13:46
  или другой процесс, когда кто-то делает слияние в ветку релиза.
• 13:50
  Этот подход дает больше контроля и создает четкую границу между текущей работой и изменениями в реальной среде,
• 13:55
  но многие команды никогда не пересматривают триггеры после их создания.
• 13:58
  Именно так секреты из одной среды могут просочиться в другую,
• 14:02
  а конфигурация для разработки случайно попадет в продакшн.
• 14:05
  Одна команда, с которой я работал, пыталась запустить весь свой ELM-процесс через один рабочий процесс.
• 14:10
  Какое-то время все было нормально, пока кто-то не заметил,
• 14:14
  что строка подключения к продакшн-базе данных появилась в среде разработки.
• 14:18
  Они не осознавали, что их секреты были общими для всех заданий.
• 14:21
  И как только код перемещался между средами, эти секреты утекали вместе с ним.
• 14:24
  Это не было очевидным сбоем или ошибкой.
• 14:26
  Все произошло незаметно. Такая утечка данных встречается чаще, чем вы думаете,
• 14:31
  особенно если вы не настроили свои процессы так, чтобы разделять секреты и переменные окружения.
• 14:35
  Каждое задание в рабочем процессе GitHub Actions отвечает за отдельный этап процесса.
• 14:40
  Одно задание может отвечать за экспорт решения из исходной среды,
• 14:44
  другое берет на себя проверку, распаковку, сканирование метаданных,
• 14:48
  проверку зависимости и наличие ссылок на коннекторы.
• 14:51
  Затем следует задание, которое подготавливает переменные среды,
• 14:56
  адаптируя решение под целевую среду.
• 14:58
  Последнее задание запускает процесс импорта,
• 15:01
  используя сервисные учетные записи для внесения изменений в нужную среду.
• 15:05
  Можно подумать, что переменные среды и секреты – это просто заполнители,
• 15:09
  но на практике это клей, который удерживает все вместе.
• 15:12
  Строки подключения, ключи API, общие пароли –
• 15:15
  все это нужно переключать между заданиями,
• 15:17
  но они ни в коем случае не должны выходить за свои границы.
• 15:20
  В ALM для Power Platform у вас может быть разное подключение к датаверс для каждой среды,
• 15:24
  или вам может потребоваться переключать конечные точки в зависимости от того,
• 15:27
  какой поток или PowerApp вы используете.
• 15:29
  Если вы повторно используете переменные или прописываете секреты в коде,
• 15:32
  вы получаете либо хрупкий конвейер, либо, что еще хуже, серьезные риски безопасности.
• 15:37
  Процесс импорта зависит от получения секретов только из нужного хранилища,
• 15:40
  чтобы рабочая среда не пострадала из-за ошибок в тест-авы или среде разработки.
• 15:44
  Хорошая модель для понимания секретов в GitHub Actions –
• 15:47
  представить, что каждая среда имеет собственное цифровое хранилище,
• 15:50
  закрытый ящик, доступный только нужным заданиям.
• 15:53
  GitHub предоставляет вам точные элементы управления.
• 15:55
  Вы можете ограничить секреты средами, чтобы задание, выполняемое в разработке,
• 15:59
  не могло получить доступ к учетным данным рабочей среды и наоборот.
• 16:02
  Настройте эти хранилища, и даже если кто-то, настраивая конвейер,
• 16:05
  попробует что-то рискованное, правила защиты среды не дадут ошибки распространиться.
• 16:10
  Документация Microsoft и GitHub делает особый упор на этом моменте.
• 16:13
  Они рекомендуют использовать правила защиты среды и строгую область действия секретов,
• 16:17
  чтобы предотвратить утечки между средами еще до их появления.
• 16:20
  Без такой защиты даже самые продуманные рабочие процессы и ELM могут развалиться.
• 16:25
  Представьте рабочий процесс, развертывающийся в продуктивную среду,
• 16:27
  но использующий строку подключения разработки или тестовую среду,
• 16:30
  внезапно получившую доступ к продуктивным данным.
• 16:32
  Это не всегда приводит к видимым сбоям.
• 16:34
  Иногда это означает, что срабатывают флаги соответствия требованиям,
• 16:37
  или журналы заполняются едва заметными ошибками,
• 16:39
  которые постепенно перерастают в большие проблемы.
• 16:40
  Вот почему ветвление рабочих процессов и ограничение в области действия секретов –
• 16:44
  это не просто продвинутые темы.
• 16:45
  Это страховочная сетка, которая не дает вашей автоматизации незаметно выйти из строя.
• 16:49
  Также есть смысл разделять рабочие процессы не только по среде, но и по зонам ответственности.
• 16:53
  Код, который экспортирует и проверяет решения,
• 16:56
  даже не должен знать, как выполнять развертывание или переключать секреты.
• 17:00
  Если каждое задание выполняет одну часть головоломки,
• 17:03
  становится намного проще обнаружить сбой,
• 17:05
  выполнить откат и провести аудит изменений после факта.
• 17:08
  Секреты остаются в хранилищах, задания следуют четко ограниченным разрешением,
• 17:12
  а сбои конвейера указывают прямо на ту часть, которую нужно исправить.
• 17:16
  Понимание того, как гид Хаб Акшенс передает работу от одного задания к другому,
• 17:20
  сохраняя при этом узкую область действия секретов и четко определенные трикгеры,
• 17:24
  превращает РЛМ из эксперимента в надежную, безопасную и предсказуемую практику.
• 17:29
  Эта сегментация рабочих процессов – не просто следование передовым методам.
• 17:33
  Она блокирует тихие утечки безопасности и случайные перезаписи,
• 17:37
  а также устраняет целый класс невидимых ошибок, прежде чем они начнут вредить вашим средам.
• 17:42
  Теперь, когда компоненты работают вместе благодаря правильно настроенной автоматизации,
• 17:46
  пришло время устранить еще одну проблемную зону.
• 17:49
  Коннекторы, сервисные принципалы и небольшие, но критические ловушки,
• 17:53
  которые могут остановить развертывание, когда вы уже обрели уверенность.
• 17:56
  Секретные принципы обслуживания и проблемы с коннекторами.
• 17:59
  Если вы хоть раз пытались перенести PowerApp или Flow из среды разработки в продакшн,
• 18:04
  вы знаете эту историю.
• 18:05
  Все безупречно работает в одной среде, но как только вы переключаетесь,
• 18:09
  все замирает или выдает загадочные ошибки подключения.
• 18:13
  Это случается не только в какой-то одной команде.
• 18:15
  Рано или поздно каждый администратор Power Platform сталкивается с этой стеной.
• 18:19
  Корень проблемы кроется в том, как коннекторы и секреты ведут себя под капотом.
• 18:24
  Нельзя просто экспортировать цип-файл решения из разработки и ожидать,
• 18:28
  что он заработает в другом месте, ведь связи, от которых он зависит, меняются в каждой среде.
• 18:33
  Возьмем, к примеру, ссылки на коннекторы.
• 18:35
  В Power Platform Connector это никогда не просто статический фрагмент информации,
• 18:39
  встроенный в ваше приложение.
• 18:40
  Он динамичен, изменчив и часто уникален для каждой среды.
• 18:44
  При экспорте решения ссылки на коннекторы работают почти как закладки.
• 18:47
  Они указывают на объекты соединений, которые существуют только в той среде, где были созданы.
• 18:52
  Поэтому при импорте в тестовую или рабочую среду, ваше продвинутое HTTP, конечная точка или ссылка Dataverse
• 18:58
  не обязательно воссоздадутся так же или вообще.
• 19:00
  Именно здесь команды попадаются в ловушку.
• 19:03
  Если в разработке используется коннектор к тестовым данным,
• 19:06
  а в продакшене эта конфигурация не продублирована,
• 19:09
  ваш поток или приложение либо тихо сбоят,
• 19:13
  либо зависают при первой попытке подключения.
• 19:16
  Многие пытаются обойти это, используя одни и те же учетные данные пользователей в разных средах.
• 19:20
  Они думают, если использовать тот же аккаунт или пароль, что создал соединение в разработке,
• 19:25
  возможно, в продакшене все заработает само.
• 19:27
  На деле это влечет массу проблем от отказа в доступе до инициации проверок на соответствие требованиям.
• 19:32
  Рекомендации Microsoft однозначны,
• 19:34
  использование личных учетных данных пользователей для автоматизированного развертывания
• 19:37
  не является жизнеспособным или безопасным.
• 19:39
  Это ставит автоматизацию в зависимость от смены паролей
• 19:41
  и оставляет грязные следы в журналах аудита.
• 19:44
  Нет четкой ответственности, и в конечном итоге право доступа блокирует конвейер,
• 19:48
  когда исходный пользователь помечается как неактивный, удаляется или теряет доступ.
• 19:53
  На помощь приходят сервисные принципалы.
• 19:55
  Если вы с ними не работали, представьте сервисный принципал
• 19:58
  как цифровую пару дополнительных рук, созданных специально для автоматизации.
• 20:01
  В отличие от обычного пользователя,
• 20:03
  сервисный принципал привязан к регистрации приложения в Azure Red,
• 20:07
  а не к реальному человеку.
• 20:08
  Вы предоставляете ему минимальные разрешения,
• 20:10
  необходимые для выполнения задач по развертыванию.
• 20:13
  Звучит просто, но отдача огромна.
• 20:14
  Вместо зависимости от пользователя, который может уволиться или сменить должность,
• 20:18
  развертывания остаются последовательными, проверяемыми и очлеживаемыми.
• 20:22
  Каждая среда получает доступ только к нужным подключениям и ресурсам,
• 20:25
  а все изменения фиксируются для этой учетной записи робота.
• 20:28
  В случае сбоя у вас остается четкий журнал аудита,
• 20:31
  и вы не остаетесь осиротевшими потоками, которые никому исправить.
• 20:34
  Рассматривая проблему сопоставления коннекторов,
• 20:37
  подумайте, что происходит, когда среды начинают расходиться.
• 20:40
  Допустим, команда разработчиков получила одобрение на новый пользовательский коннектор.
• 20:43
  Предположим, он обращается к API «Песочнице».
• 20:46
  Когда приходит время перехода в прот, этот коннектор не просто отсутствует,
• 20:49
  он может быть даже запрещен политиками безопасности данных организации.
• 20:52
  Если вы забудете перенастроить его,
• 20:54
  приложение будет обращаться к неверной конечной точке или вовсе перестанет работать.
• 20:58
  Недавно я видел, как это обернулось серьезными проблемами для одной медицинской организации.
• 21:01
  Одна упущенная настройка коннектора привела к использованию тестовых данных в продакшене
• 21:05
  и едва не вызвала инцидент с нарушением комплайенса.
• 21:07
  Их автоматизированный конвейер экспортировал все по плану,
• 21:10
  но ссылка на коннектор внутри решения все еще указывала на старую тестовую базу данных,
• 21:14
  которую Power Platform не пометила как ошибочную,
• 21:17
  пока реальные данные не потекли по неверным каналам.
• 21:20
  Переменные среды призваны облегчить эту боль.
• 21:22
  В отличие от жестко прописанных конечных точек или API-ключей,
• 21:26
  переменные среды позволяют отделить то, что меняется в разных средах,
• 21:29
  от того, что остается неизменным.
• 21:30
  Вы можете менять конечные точки, API-ключи или другие секреты при каждом развертывании,
• 21:35
  не переписывая приложение или поток.
• 21:37
  Например, поток, работающий с таблицей Dataverse для разработки,
• 21:41
  при импорте можно перенастроить на рабочую таблицу,
• 21:44
  просто изменив переменную среды в процессе развертывания.
• 21:47
  Конвейеры GitHub Actions делают это практичным.
• 21:50
  Каждое задание может внедрить нужное значение в нужное время.
• 21:54
  Но даже здесь важна дисциплина.
• 21:56
  Стоит забыть обновить переменную или допустить утечку секретов между средами,
• 22:00
  и ваш рабочий процесс оказывается под угрозой.
• 22:02
  Microsoft подчеркивает необходимость тщательного определения области действия секретов
• 22:07
  и осознанного сопоставления ссылок на коннекторы.
• 22:09
  Их политики предотвращения потери данных, DLP, существуют не просто так.
• 22:13
  Они не дают конфиденциальной информации перемещаться между средами
• 22:16
  или появляться там, где не положено.
• 22:18
  Если попытаться обойти их, предоставляя общий доступ к переменным или подключениям,
• 22:22
  вы столкнетесь с проблемами корпоративной безопасности или комплайнс-контроля.
• 22:26
  Что еще важнее, вы теряете предсказуемость,
• 22:28
  так как стирается грань между тем, что предназначено для разработки, тестирования или продакшена.
• 22:33
  Трудно переоценить преимущества, которые вы получаете, если все настроено верно.
• 22:37
  Сервисные принципалы в сочетании с грамотно управляемыми переменными средой
• 22:40
  и правильно сопоставленными коннекторами преображают ваш конвейер.
• 22:42
  Ваши развертывания становятся предсказуемыми.
• 22:45
  Когда что-то ломается, у вас есть четкая цепочка ответственности,
• 22:47
  и вы точно знаете, где искать.
• 22:49
  Дело было в сопоставлении коннектора, переменной или упущенном разрешении.
• 22:52
  Аудиторы могут отследить изменения, и вам не придется волноваться,
• 22:55
  когда кто-то покидает организацию или меняет пароли.
• 22:57
  Все сводится к тому, чтобы относиться к секретам, коннекторам и сервисным принципалам
• 23:01
  как к чему-то по-настоящему важному.