WEBVTT

00:00:00.100 --> 00:00:06.000
Готовы к 10 дням погружения в Microsoft 365, Капайлот и Азур и знакомство с людьми,

00:00:06.200 --> 00:00:12.280
формирующими будущие работы. В этом январе М365 Кон возвращается, и мы берем новую планку.

00:00:12.420 --> 00:00:16.280
Присоединяйтесь к нам для участия в живых сессиях, демонстрациях реальных кейсов и получения

00:00:16.280 --> 00:00:20.020
практических знаний от MVP и экспертов со всего мира. Никаких общих слайдов,

00:00:20.180 --> 00:00:24.960
никаких бесконечных модных словечек. Мы решаем реальные задачи, Капайлот Студия,

00:00:24.960 --> 00:00:30.100
и агенты, фабрик, безопасность, управление и автоматизация. Независимо от того,

00:00:30.340 --> 00:00:34.540
являетесь ли вы это специалистом, разработчиком или бизнес-лидером, у нас найдутся сессии

00:00:34.540 --> 00:00:39.400
специально для вас. За 10 полных дней вы сможете изучить множество технологий и пообщаться с

00:00:39.400 --> 00:00:44.160
мировым сообществом. Смотрите в прямом эфире и используйте полученные практические идеи в своей

00:00:44.160 --> 00:00:51.060
организации. Январь 2027 года, 10 дней, одно сообщество Microsoft. Регистрация уже открыта.

00:00:51.060 --> 00:01:02.740
Забронируйте свое место сегодня. Это m365con.net. Присоединяйтесь на m365con.net.

00:01:03.060 --> 00:01:07.740
Увидимся в прямом эфире в январе. Вам когда-нибудь казалось, что развертывание в Power Platform — это

00:01:07.740 --> 00:01:11.960
черный ящик? Вы выпускаете обновление, затаив дыхание, и просто надеетесь, что оно заработает в

00:01:11.960 --> 00:01:16.420
средах разработки, тестирования и продакшена. Что, если бы вы могли реально контролировать и видеть

00:01:16.420 --> 00:01:21.380
каждый этап процесса ALM с помощью GitHub Actions, забыв о догадках и ручных заплатках?

00:01:21.520 --> 00:01:25.840
Давайте приоткроем завесу и посмотрим, как связаны компоненты, контроль версий,

00:01:26.100 --> 00:01:30.840
автоматизация и безопасные переменные. Это не просто очередное пошаговое руководство. Это-то,

00:01:30.920 --> 00:01:35.100
о чем умалчивают большинство гайдов, чтобы ваше следующее развертывание не заставляло вас гадать.

00:01:35.220 --> 00:01:40.440
Итак, почему ALM в Power Platform кажется таким лабиринтом? Если вы когда-либо пытались развернуть

00:01:40.440 --> 00:01:45.000
Power App и чувствовали ту самую неуверенность, будто что-то важное ускользнуло от внимания,

00:01:45.000 --> 00:01:49.160
вы не одиноки. На бумаге Power Platform обещает простую разработку приложений,

00:01:49.320 --> 00:01:53.160
но за этим дружелюбным фасадом скрывается далеко не прямолинейный процесс ALM.

00:01:53.340 --> 00:01:58.000
Веб-приложение развертывается из системы контроля версий, собирается в конвейере и попадает

00:01:58.000 --> 00:02:02.680
в продакшен с предсказуемым поведением. Power Platform, напротив, скрывает половину логики

00:02:02.680 --> 00:02:07.340
внутри drag-and-drop интерфейсов, экранов, коннекторов и формул, которые невозможно увидеть в

00:02:07.340 --> 00:02:11.620
репозитории Git. Поэтому, даже если вы следуете каждому шагу из общих административных руководств,

00:02:11.620 --> 00:02:15.300
вы все равно столкнетесь со странными, труднодиагностируемыми с боями, когда критически

00:02:15.300 --> 00:02:19.200
важные приложения покидают среду разработки. Давайте взглянем на имеющееся руководство

00:02:19.200 --> 00:02:23.500
по ALM. Большинство из них просто объясняют, как экспортировать ЦИП-файл решения и импортировать

00:02:23.500 --> 00:02:27.680
его куда-то еще. Довольно просто, верно? Но ответ на вопрос, как это лишь один уровень?

00:02:27.800 --> 00:02:31.960
А вот, почему они опускают? Почему развертывание в Power Platform ломается так,

00:02:32.080 --> 00:02:35.940
как никогда не ломается обычный код? Именно это вызывает бесконечную путаницу.

00:02:35.940 --> 00:02:40.540
Корень проблемы в том, что логика, соединение и конфигурации в Power Apps хранятся не так,

00:02:40.700 --> 00:02:45.120
как классический программный код. Вы не просто клонируете репозиторий и запускаете модульные

00:02:45.120 --> 00:02:49.380
тесты. Поэтому, когда вы пытаетесь перенести приложение, все эти скрытые зависимости,

00:02:49.580 --> 00:02:54.140
подключение к Outlook, SharePoint или сторонней мапе не всегда аккуратно упаковываются в ЦИП-файл.

00:02:54.240 --> 00:02:58.300
Вот типичный сценарий. Вы создали отличное новое приложение, и оно работает в среде разработки.

00:02:58.420 --> 00:03:02.020
Вы экспортируете решение, импортируете его в тестовую среду, и внезапно поток перестает работать.

00:03:02.020 --> 00:03:06.300
Дело редко бывает только в самом файле. Проблема в том, что подключение указывают не туда,

00:03:06.500 --> 00:03:10.960
права доступа не совпадают, а политики данных блокируют соединения, которые еще минуту назад

00:03:10.960 --> 00:03:15.080
работали нормально. А теперь представьте, что это нужно делать для трех сред разработки,

00:03:15.240 --> 00:03:19.160
тестирования и продакшена, где у каждой свои подключения, политики защиты данных,

00:03:19.380 --> 00:03:23.680
согласующие лица и административные ограничения. Простым копированием здесь не обойтись.

00:03:23.880 --> 00:03:27.820
Исследования подтверждают то, с чем администраторы и разработчики сталкиваются каждую неделю.

00:03:28.000 --> 00:03:31.780
Большинство неудачных развертываний в Power Platform связаны с отсутствующими ссылками

00:03:31.780 --> 00:03:35.880
на коннекторы или неправильной настройкой переменных среды. Отсутствие ссылки на коннектор

00:03:35.880 --> 00:03:40.200
означает лишь то, что поток не может найти свое подключение к Outlook или Dataverse.

00:03:40.380 --> 00:03:44.600
В итоге, как только вы пытаетесь запустить приложение или поток в другой среде,

00:03:44.880 --> 00:03:49.680
вы получаете ошибки времени выполнения. А поскольку переменные среды в Power Platform работают

00:03:49.680 --> 00:03:55.160
иначе, чем в других продуктах Microsoft 365, на них спотыкаются даже опытные разработчики.

00:03:55.340 --> 00:03:59.180
Переменные предназначены для управления конечными точками, ключами или конфигурациями

00:03:59.180 --> 00:04:02.780
конкретного клиента. Но если кто-то забудет обновить их после экспорта решения,

00:04:03.020 --> 00:04:06.580
даже безобидное на вид изменения может вывести из строя работающие приложения.

00:04:06.780 --> 00:04:10.760
Многие из нас поначалу попадают в эту ловушку. Можно подумать, что экспорт цип архива

00:04:10.760 --> 00:04:14.340
решения включает все необходимое, но на самом деле он пропускает динамические ссылки на

00:04:14.340 --> 00:04:17.400
коннекторы. Например, допустим, у вас есть приложение, которое использует

00:04:17.400 --> 00:04:21.400
HTTP-коннектор для стороннего сервиса в среде разработки. При импорте в тестовую среду или

00:04:21.400 --> 00:04:25.540
продакшен именно этого экземпляра коннектора там не будет. Ссылка на коннектор внутри

00:04:25.540 --> 00:04:30.600
вашего приложения указывает на несуществующий объект, и потоки внутри решения тихо ломаются,

00:04:30.800 --> 00:04:34.800
пока пользователь или администратор вручную их не пересоздаст и не перенастроит.

00:04:34.920 --> 00:04:38.920
Если у вас несколько разработчиков или администраторов, становится еще проще потерять

00:04:38.920 --> 00:04:43.160
нить того, какая ссылка куда ведет, а никому не нужны разборы полетов в стиле. Но ведь в

00:04:43.160 --> 00:04:48.320
разработке все работало. Еще одна сложность — сервисные учетные записи. Большинство начинают

00:04:48.320 --> 00:04:53.160
с использования обычных учетных записей для экспорта и импорта решений, потому что так быстрее начать

00:04:53.160 --> 00:04:57.780
работу. Но при попытке автоматизации с помощью GitHub Actions или любой CI-системы использования

00:04:57.780 --> 00:05:01.940
личных учетных данных быстро заводят в тупик. Вы упретесь в ограничении прав доступа, иногда без

00:05:01.940 --> 00:05:05.700
четких сообщений об ошибках, или даже спровоцируете аудит соответствия требованиям, потому что

00:05:05.700 --> 00:05:09.800
выполняете критически важные развертывания под личной учетной записью, а не под той, что предназначена

00:05:09.800 --> 00:05:14.960
для автоматизации. Субъекты службы, по сути, идентификаторы приложений в Azure Ad, отвечают за все

00:05:14.960 --> 00:05:20.660
разрешения, ведение журналов и аудит, необходимые вашему конвейеру. Без них ваша цепочка автоматизации

00:05:20.660 --> 00:05:25.140
превращается в лоскутное одеяло из ручных передач задач, и вы никогда не узнаете, кто и что

00:05:25.140 --> 00:05:30.060
изменил. Контроль версий тоже становится непредсказуемым. В обычном коде у вас есть история коммитов

00:05:30.060 --> 00:05:34.160
и инструменты для поиска авторства изменений. Файлы решений Power Platform — это лишь снимки

00:05:34.160 --> 00:05:38.940
состояния, поэтому вам не хватает детализированного отслеживания изменений. Логика, скрытая в формулах

00:05:38.940 --> 00:05:43.680
экранов, холстовых приложений или в слабо документированных потоках, остается невидимой до следующего

00:05:43.680 --> 00:05:48.740
экспорта. Кто-то меняет настройку потока в интерфейсе, и попробуйте потом понять, почему нежестоящие

00:05:48.740 --> 00:05:54.100
среды вдруг ведут себя иначе. В итоге управление ALM для Power Platform похоже на сборку пазла,

00:05:54.320 --> 00:05:59.740
где половина деталей отсутствует или спрятана под коробкой. Невидимые зависимости, специфичные

00:05:59.740 --> 00:06:04.940
для среды коннекторы и переменные, которые нельзя увидеть в коде, нарушают привычный рабочий

00:06:04.940 --> 00:06:09.780
процесс разработчика. И это еще до того, как вы столкнетесь с тем, что в продуктивных средах почти

00:06:09.780 --> 00:06:14.480
всегда действуют более строгие права доступа, другие политики данных и аудиторские требования,

00:06:14.480 --> 00:06:19.360
неочевидные при разработке или тестировании. Но есть и положительный момент. Эта сложность

00:06:19.360 --> 00:06:24.560
не случайна. Существует практическая причина, по которой Power Platform обрабатывает исходный код,

00:06:24.800 --> 00:06:29.280
переменные и коннекторы таким уникальным образом. Она стремится позволить бизнес-пользователям

00:06:29.280 --> 00:06:34.040
создавать мощные приложения, не беспокоясь о написании кода. Побочный эффект заключается в том,

00:06:34.200 --> 00:06:38.680
что вам, как специалисту по автоматизации, нужно отслеживать то, что скрыто под капотом.

00:06:38.840 --> 00:06:44.360
Если вы знаете, где проходят эти невидимые связи, вы сможете исправить или избежать большинства ошибок,

00:06:44.360 --> 00:06:49.880
которые подрывают ALM в Power Platform. Если все это кажется слишком сложным, вы не ошибаетесь.

00:06:50.020 --> 00:06:54.840
Однако есть четыре столпа ALM, которые помогают распутать этот узел. Исходный код – сборка,

00:06:55.000 --> 00:06:58.860
тестирование и развертывание. У каждого из них в Power Platform есть свои особенности,

00:06:59.000 --> 00:07:01.860
но вместе они возвращают структуру в то, что иначе кажется хаосом.

00:07:02.000 --> 00:07:05.760
Базовая система ALM – исходный код – сборка, тестирование, развертывание.

00:07:06.000 --> 00:07:10.060
Всякий раз, когда кто-то просит создать конвейер Power Platform, который просто работает,

00:07:10.060 --> 00:07:14.460
на ум приходят эти четыре фундаментальных столпа – исходный код, сборка, тестирование,

00:07:14.660 --> 00:07:18.640
развертывание. В традиционной разработке вы могли бы делать это практически с закрытыми

00:07:18.640 --> 00:07:24.020
глазами. Power Platform не дает такой свободы. Внезапно исходный код перестает означать просто

00:07:24.020 --> 00:07:29.040
код. Это означает работу с файлами решений, экспорт заархивированных пакетов с приложениями,

00:07:29.160 --> 00:07:33.180
потоками и иногда коннекторами, которые выдают себя за часть исходного кода.

00:07:33.380 --> 00:07:38.280
Давайте начнем с основ, а затем разберем, что делает каждый столб таким необычным в этом мире.

00:07:38.280 --> 00:07:42.680
У вас есть ZIP-файл решения. Это не код в привычном понимании. Откройте его,

00:07:42.880 --> 00:07:47.840
и вас встретят файлы XML и JSON, а не логика, которую вы ожидаете увидеть в TypeScript или

00:07:47.840 --> 00:07:53.020
C-решетка. Но это и есть исходный код для Power Platform. Команды часто спотыкаются на этом этапе.

00:07:53.160 --> 00:07:57.100
Все выглядит портативно, пока не понимаешь, что большинство изменений, например,

00:07:57.220 --> 00:08:02.220
обновлений формулы или логики потока, не видны, пока не экспортируешь свежий цип файл решения.

00:08:02.440 --> 00:08:07.140
Да, вы можете версионировать эти файлы решений в Git, но если вы не дисциплинированы в плане

00:08:07.140 --> 00:08:10.400
экспорта после каждой правки, в истории будут огромные пробелы.

00:08:10.480 --> 00:08:14.320
Теперь перейдем к конфигурации. В обычных приложениях вы просто сохраняете строки

00:08:14.320 --> 00:08:18.840
подключения в файле конфигурации и считаете задачу выполненной. Power Platform же протаскивает

00:08:18.840 --> 00:08:23.260
данные, специфичные для среды, прямо внутри решений. Это не только переменные среды,

00:08:23.400 --> 00:08:27.520
но и ссылки на коннекторы, динамические конечные точки, роли и разрешения,

00:08:27.720 --> 00:08:32.320
упакованные вместе с бизнес-логикой. Если вы забудете обновить их перед экспортом и среды

00:08:32.320 --> 00:08:36.380
разработки или тестирования, вы зафиксируете указатели на неверные адреса.

00:08:36.380 --> 00:08:41.420
Я видел, как команды старательно коммитят цип файлы решений, а при развертывании обнаруживают,

00:08:41.660 --> 00:08:45.880
что половина приложения все еще обращается к тестовой датаверс, а не к продакшену,

00:08:46.040 --> 00:08:50.000
потому что никто не перенастроил ссылки. Затем у нас идет сборка, билл.

00:08:50.100 --> 00:08:55.780
Слово «сборка» обычно ассоциируется с компиляцией кода и зелеными галочками в CI-заданиях.

00:08:55.920 --> 00:09:01.320
В Power Platform процесс сборки – это хранение цип архивов, проверка схем и подтверждение

00:09:01.320 --> 00:09:06.380
зависимостей. В конвейере GitHub Actions задача сборки берет ваш закоммиченный файл решения,

00:09:06.560 --> 00:09:11.740
а затем использует CLI Power Platform от Microsoft для распаковки, проверки и повторной упаковки.

00:09:11.880 --> 00:09:16.540
На этапе проверки происходит либо чудо, либо хаос. Она может выявить нерабочие ссылки

00:09:16.540 --> 00:09:21.260
или неподдерживаемые действия. Хуже того, если изменения в потоке зависят от кастомного

00:09:21.260 --> 00:09:26.400
коннектора, который не попал в систему контроля версий, сборка молча упакует неполный продукт.

00:09:26.480 --> 00:09:30.860
Вот здесь все становится сложнее. Эти задачи сборки – это не столько компиляция,

00:09:30.860 --> 00:09:35.840
сколько организация надежного экспорта и гарантия того, что содержимое готово к поставке.

00:09:36.020 --> 00:09:39.920
Команды, которые пропускают или торопят этот процесс, быстро оказываются в ситуации,

00:09:40.060 --> 00:09:44.760
когда сборка технически успешна, но в UIT или продакшене не хватает половины задуманных функций.

00:09:44.900 --> 00:09:49.000
Microsoft продолжает продвигать мысль, что файлы решений делают ALM портативным,

00:09:49.140 --> 00:09:53.280
но здесь всегда есть «но». Портативность зависит от того, правильно ли настроены коннекторы

00:09:53.280 --> 00:09:57.180
и распределены роли между средами. Тестирование – это следующий важный этап.

00:09:57.180 --> 00:10:02.460
В конвейере веб-приложения автоматизированные тесты могут включать модульные тесты или проверку интерфейса.

00:10:02.660 --> 00:10:05.980
Что считать тестом в Power Platform – вопрос дискуссионный.

00:10:06.760 --> 00:10:11.900
Иногда это проверка решения, открывается ли оно и разрешаются ли ключевые зависимости.

00:10:12.460 --> 00:10:18.220
В других случаях это запуск тестовых потоков или проверка того, отвечают ли коннекторы в тестовой среде.

00:10:18.220 --> 00:10:23.160
Часто тестирование проводится вручную, поскольку проверка бизнес-логики внутри конвас-приложений

00:10:23.160 --> 00:10:25.280
еще не встроена в автоматизированные конвейеры.

00:10:25.440 --> 00:10:28.760
Однако можно автоматизировать проверки, находить отсутствующие коннекторы,

00:10:28.960 --> 00:10:33.720
тестировать критические потоки или пинговать среду тестирования, чтобы убедиться в работе учетных данных.

00:10:33.900 --> 00:10:35.940
Развертывание – самый болезненный этап.

00:10:36.060 --> 00:10:39.960
При развертывании обычного приложения вы можете просто отправить веб-артефакт в Азу.

00:10:40.120 --> 00:10:44.620
В Power Platform приходится настраивать соединения, назначать права, обновлять секреты,

00:10:44.620 --> 00:10:49.500
менять переменные среды и запускать импорт через субъект службу, а не обычную учетную запись.

00:10:49.720 --> 00:10:53.000
Иначе вы столкнетесь с проблемами при аудите и отказами в доступе.

00:10:53.180 --> 00:10:57.340
GitHub Actions может объединить этот процесс, но только если каждая задача знает,

00:10:57.560 --> 00:11:00.160
на какую среду нацелена и какие секреты использовать.

00:11:00.360 --> 00:11:05.860
Я видел, как команды пытались сэкономить время, используя одни и те же учетные данные для разработки и продакшена,

00:11:06.080 --> 00:11:10.520
что приводит к хаосу, утечкам данных, ошибкам доступа и с боям функций в отдельных средах.

00:11:10.700 --> 00:11:13.540
Вспомните команду, с которой я работал несколько месяцев назад.

00:11:13.540 --> 00:11:18.280
Они делали почти все правильно – стандартные гид-репозитории, версионные архивы решений и четкое ветвление.

00:11:18.440 --> 00:11:20.940
Но их конвейер постоянно ломался на этапе развертывания.

00:11:21.100 --> 00:11:26.760
Почему? Они не утруждались с заменой переменных среды или обновлением ссылок на коннекторы перед импортом в продакшен.

00:11:26.900 --> 00:11:31.660
В итоге ключевые потоки указывали не на те конечные точки, а данные попадали не в те системы.

00:11:31.780 --> 00:11:38.020
Решением стали скриптовые шаги в их GitHub-конвейере, которые подменяли переменные и перенастраивали все коннекторы при импорте.

00:11:38.200 --> 00:11:40.880
Собственные рекомендации Microsoft говорят об этом прямо.

00:11:40.880 --> 00:11:48.180
Используйте файлы решений для перемещения объектов между средами, но всегда учитывайте ссылки на коннекторы и сопоставление ролей в вашем конвейере.

00:11:48.320 --> 00:11:54.380
Они подчеркивают, что пропуск этих шагов – главная причина поломки приложений, особенно в сильно защищенных средах.

00:11:54.500 --> 00:12:01.440
Когда вы воспринимаете исходный код, сборку, тестирование и развертывание как взаимосвязанные части, а не изолированные этапы, проще понять,

00:12:01.620 --> 00:12:06.640
почему многие попытки внедрения ELM проваливаются и как решать проблемы, а не просто надеяться на удачу.

00:12:06.640 --> 00:12:17.040
Далее мы разберем, как GitHub Actions координирует этот процесс, трикгеры, ветвление и разделение задач, делая автоматизацию Power Platform гибкой и безопасной.

00:12:17.220 --> 00:12:20.880
GitHub Actions соединяем все воедино с помощью триггеров и задач.

00:12:20.880 --> 00:12:28.840
Если вы хоть раз ждали завершение конвейера GitHub Actions после обновления Power App, то знаете, что автоматизация – это не мгновенно и точно не магия.

00:12:29.020 --> 00:12:34.060
Большинство команд сталкиваются с этой реальностью сразу после восторга от первого запуска рабочего процесса.

00:12:34.180 --> 00:12:41.300
Вы настраиваете скрипт, подключаете его к репозиторию и ждете, что каждый новый коммит будет гладко разворачиваться во всех средах.

00:12:41.400 --> 00:12:43.240
А потом наступает суровая реальность.

00:12:43.240 --> 00:12:50.880
Вместо простого запуска скрипта, GitHub Actions использует логическую цепочку, построенную на триггерах, заданиях и передаче данных между средами.

00:12:51.020 --> 00:12:56.780
Этот порядок и структура позволяют развертыванием не превращаться в путаницу из неудачных шагов и странных ошибок.

00:12:56.940 --> 00:12:59.580
Отправной точкой в этой системе является триггер.

00:13:00.240 --> 00:13:07.620
Большинство новичков создают рабочий процесс, который запускается при каждом пуш или при слиянии пул-рекист в основную ветку.

00:13:07.780 --> 00:13:10.020
На первый взгляд, это кажется лучшей практикой.

00:13:10.020 --> 00:13:12.740
Почему бы не запускать конвейер каждый раз, когда вносятся изменения?

00:13:12.880 --> 00:13:13.800
Но есть один нюанс.

00:13:13.980 --> 00:13:17.320
Когда вы устанавливаете триггер только на основную ветку, все проходит через один канал.

00:13:17.520 --> 00:13:20.720
Что, если изменения должны попасть в разработку, но не в тестирование или продакшн?

00:13:20.840 --> 00:13:24.740
Что, если вы готовы к развертыванию в продакшне, но в тестовой среде еще идет проверка?

00:13:24.900 --> 00:13:28.980
Команды, которые используют универсальные триггеры, часто сталкиваются с проблемами,

00:13:29.100 --> 00:13:34.900
когда функции для разработки попадают в продакшн или тестовые развертывания внезапно переопределяют рабочие настройки.

00:13:34.900 --> 00:13:39.640
Вы можете разделить рабочие процессы для каждой среды, разработки, тестирования и продакшна,

00:13:39.860 --> 00:13:42.240
и настроить специфические триггеры для каждой из них.

00:13:42.380 --> 00:13:46.760
Например, настройте процесс, который запускается только при пуш в ветку разработки,

00:13:46.940 --> 00:13:50.380
или другой процесс, когда кто-то делает слияние в ветку релиза.

00:13:50.480 --> 00:13:55.560
Этот подход дает больше контроля и создает четкую границу между текущей работой и изменениями в реальной среде,

00:13:55.680 --> 00:13:58.720
но многие команды никогда не пересматривают триггеры после их создания.

00:13:58.720 --> 00:14:02.160
Именно так секреты из одной среды могут просочиться в другую,

00:14:02.300 --> 00:14:05.520
а конфигурация для разработки случайно попадет в продакшн.

00:14:05.640 --> 00:14:10.680
Одна команда, с которой я работал, пыталась запустить весь свой ELM-процесс через один рабочий процесс.

00:14:10.860 --> 00:14:13.860
Какое-то время все было нормально, пока кто-то не заметил,

00:14:14.120 --> 00:14:17.880
что строка подключения к продакшн-базе данных появилась в среде разработки.

00:14:18.020 --> 00:14:21.180
Они не осознавали, что их секреты были общими для всех заданий.

00:14:21.320 --> 00:14:24.800
И как только код перемещался между средами, эти секреты утекали вместе с ним.

00:14:24.940 --> 00:14:26.840
Это не было очевидным сбоем или ошибкой.

00:14:26.840 --> 00:14:30.780
Все произошло незаметно. Такая утечка данных встречается чаще, чем вы думаете,

00:14:31.000 --> 00:14:35.160
особенно если вы не настроили свои процессы так, чтобы разделять секреты и переменные окружения.

00:14:35.320 --> 00:14:39.940
Каждое задание в рабочем процессе GitHub Actions отвечает за отдельный этап процесса.

00:14:40.500 --> 00:14:44.260
Одно задание может отвечать за экспорт решения из исходной среды,

00:14:44.460 --> 00:14:47.840
другое берет на себя проверку, распаковку, сканирование метаданных,

00:14:48.620 --> 00:14:51.580
проверку зависимости и наличие ссылок на коннекторы.

00:14:51.580 --> 00:14:56.380
Затем следует задание, которое подготавливает переменные среды,

00:14:56.600 --> 00:14:58.720
адаптируя решение под целевую среду.

00:14:58.800 --> 00:15:01.100
Последнее задание запускает процесс импорта,

00:15:01.300 --> 00:15:05.040
используя сервисные учетные записи для внесения изменений в нужную среду.

00:15:05.200 --> 00:15:09.080
Можно подумать, что переменные среды и секреты – это просто заполнители,

00:15:09.260 --> 00:15:12.000
но на практике это клей, который удерживает все вместе.

00:15:12.260 --> 00:15:15.020
Строки подключения, ключи API, общие пароли –

00:15:15.020 --> 00:15:17.020
все это нужно переключать между заданиями,

00:15:17.020 --> 00:15:19.980
но они ни в коем случае не должны выходить за свои границы.

00:15:20.180 --> 00:15:24.100
В ALM для Power Platform у вас может быть разное подключение к датаверс для каждой среды,

00:15:24.260 --> 00:15:27.460
или вам может потребоваться переключать конечные точки в зависимости от того,

00:15:27.600 --> 00:15:29.420
какой поток или PowerApp вы используете.

00:15:29.620 --> 00:15:32.720
Если вы повторно используете переменные или прописываете секреты в коде,

00:15:32.880 --> 00:15:36.860
вы получаете либо хрупкий конвейер, либо, что еще хуже, серьезные риски безопасности.

00:15:37.000 --> 00:15:40.460
Процесс импорта зависит от получения секретов только из нужного хранилища,

00:15:40.660 --> 00:15:44.240
чтобы рабочая среда не пострадала из-за ошибок в тест-авы или среде разработки.

00:15:44.240 --> 00:15:47.180
Хорошая модель для понимания секретов в GitHub Actions –

00:15:47.180 --> 00:15:50.320
представить, что каждая среда имеет собственное цифровое хранилище,

00:15:50.500 --> 00:15:52.880
закрытый ящик, доступный только нужным заданиям.

00:15:53.040 --> 00:15:55.540
GitHub предоставляет вам точные элементы управления.

00:15:55.760 --> 00:15:59.380
Вы можете ограничить секреты средами, чтобы задание, выполняемое в разработке,

00:15:59.560 --> 00:16:02.440
не могло получить доступ к учетным данным рабочей среды и наоборот.

00:16:02.600 --> 00:16:05.820
Настройте эти хранилища, и даже если кто-то, настраивая конвейер,

00:16:05.980 --> 00:16:09.840
попробует что-то рискованное, правила защиты среды не дадут ошибки распространиться.

00:16:10.100 --> 00:16:13.600
Документация Microsoft и GitHub делает особый упор на этом моменте.

00:16:13.600 --> 00:16:17.540
Они рекомендуют использовать правила защиты среды и строгую область действия секретов,

00:16:17.660 --> 00:16:20.320
чтобы предотвратить утечки между средами еще до их появления.

00:16:20.540 --> 00:16:24.800
Без такой защиты даже самые продуманные рабочие процессы и ELM могут развалиться.

00:16:25.000 --> 00:16:27.780
Представьте рабочий процесс, развертывающийся в продуктивную среду,

00:16:27.860 --> 00:16:30.760
но использующий строку подключения разработки или тестовую среду,

00:16:30.880 --> 00:16:32.800
внезапно получившую доступ к продуктивным данным.

00:16:32.940 --> 00:16:34.720
Это не всегда приводит к видимым сбоям.

00:16:34.900 --> 00:16:37.380
Иногда это означает, что срабатывают флаги соответствия требованиям,

00:16:37.420 --> 00:16:39.120
или журналы заполняются едва заметными ошибками,

00:16:39.240 --> 00:16:40.900
которые постепенно перерастают в большие проблемы.

00:16:40.900 --> 00:16:44.120
Вот почему ветвление рабочих процессов и ограничение в области действия секретов –

00:16:44.120 --> 00:16:45.140
это не просто продвинутые темы.

00:16:45.240 --> 00:16:49.000
Это страховочная сетка, которая не дает вашей автоматизации незаметно выйти из строя.

00:16:49.120 --> 00:16:53.800
Также есть смысл разделять рабочие процессы не только по среде, но и по зонам ответственности.

00:16:53.960 --> 00:16:56.120
Код, который экспортирует и проверяет решения,

00:16:56.360 --> 00:16:59.920
даже не должен знать, как выполнять развертывание или переключать секреты.

00:17:00.100 --> 00:17:02.900
Если каждое задание выполняет одну часть головоломки,

00:17:03.180 --> 00:17:05.080
становится намного проще обнаружить сбой,

00:17:05.360 --> 00:17:08.220
выполнить откат и провести аудит изменений после факта.

00:17:08.220 --> 00:17:12.440
Секреты остаются в хранилищах, задания следуют четко ограниченным разрешением,

00:17:12.600 --> 00:17:16.060
а сбои конвейера указывают прямо на ту часть, которую нужно исправить.

00:17:16.180 --> 00:17:20.360
Понимание того, как гид Хаб Акшенс передает работу от одного задания к другому,

00:17:20.540 --> 00:17:24.400
сохраняя при этом узкую область действия секретов и четко определенные трикгеры,

00:17:24.620 --> 00:17:29.040
превращает РЛМ из эксперимента в надежную, безопасную и предсказуемую практику.

00:17:29.320 --> 00:17:33.540
Эта сегментация рабочих процессов – не просто следование передовым методам.

00:17:33.540 --> 00:17:37.360
Она блокирует тихие утечки безопасности и случайные перезаписи,

00:17:37.520 --> 00:17:42.380
а также устраняет целый класс невидимых ошибок, прежде чем они начнут вредить вашим средам.

00:17:42.540 --> 00:17:46.580
Теперь, когда компоненты работают вместе благодаря правильно настроенной автоматизации,

00:17:46.880 --> 00:17:49.180
пришло время устранить еще одну проблемную зону.

00:17:49.280 --> 00:17:53.180
Коннекторы, сервисные принципалы и небольшие, но критические ловушки,

00:17:53.400 --> 00:17:56.800
которые могут остановить развертывание, когда вы уже обрели уверенность.

00:17:56.980 --> 00:17:59.980
Секретные принципы обслуживания и проблемы с коннекторами.

00:17:59.980 --> 00:18:04.240
Если вы хоть раз пытались перенести PowerApp или Flow из среды разработки в продакшн,

00:18:04.420 --> 00:18:05.520
вы знаете эту историю.

00:18:05.720 --> 00:18:09.620
Все безупречно работает в одной среде, но как только вы переключаетесь,

00:18:09.760 --> 00:18:12.940
все замирает или выдает загадочные ошибки подключения.

00:18:13.120 --> 00:18:15.540
Это случается не только в какой-то одной команде.

00:18:15.760 --> 00:18:19.660
Рано или поздно каждый администратор Power Platform сталкивается с этой стеной.

00:18:19.820 --> 00:18:24.440
Корень проблемы кроется в том, как коннекторы и секреты ведут себя под капотом.

00:18:24.600 --> 00:18:28.140
Нельзя просто экспортировать цип-файл решения из разработки и ожидать,

00:18:28.140 --> 00:18:32.880
что он заработает в другом месте, ведь связи, от которых он зависит, меняются в каждой среде.

00:18:33.060 --> 00:18:35.280
Возьмем, к примеру, ссылки на коннекторы.

00:18:35.460 --> 00:18:39.240
В Power Platform Connector это никогда не просто статический фрагмент информации,

00:18:39.480 --> 00:18:40.620
встроенный в ваше приложение.

00:18:40.780 --> 00:18:44.000
Он динамичен, изменчив и часто уникален для каждой среды.

00:18:44.120 --> 00:18:47.780
При экспорте решения ссылки на коннекторы работают почти как закладки.

00:18:47.940 --> 00:18:52.600
Они указывают на объекты соединений, которые существуют только в той среде, где были созданы.

00:18:52.600 --> 00:18:58.580
Поэтому при импорте в тестовую или рабочую среду, ваше продвинутое HTTP, конечная точка или ссылка Dataverse

00:18:58.580 --> 00:19:00.700
не обязательно воссоздадутся так же или вообще.

00:19:00.920 --> 00:19:03.100
Именно здесь команды попадаются в ловушку.

00:19:03.300 --> 00:19:06.500
Если в разработке используется коннектор к тестовым данным,

00:19:06.780 --> 00:19:09.720
а в продакшене эта конфигурация не продублирована,

00:19:09.960 --> 00:19:12.860
ваш поток или приложение либо тихо сбоят,

00:19:13.160 --> 00:19:15.620
либо зависают при первой попытке подключения.

00:19:16.040 --> 00:19:20.920
Многие пытаются обойти это, используя одни и те же учетные данные пользователей в разных средах.

00:19:20.920 --> 00:19:25.320
Они думают, если использовать тот же аккаунт или пароль, что создал соединение в разработке,

00:19:25.480 --> 00:19:27.520
возможно, в продакшене все заработает само.

00:19:27.680 --> 00:19:32.620
На деле это влечет массу проблем от отказа в доступе до инициации проверок на соответствие требованиям.

00:19:32.740 --> 00:19:34.200
Рекомендации Microsoft однозначны,

00:19:34.300 --> 00:19:37.440
использование личных учетных данных пользователей для автоматизированного развертывания

00:19:37.440 --> 00:19:39.200
не является жизнеспособным или безопасным.

00:19:39.320 --> 00:19:41.980
Это ставит автоматизацию в зависимость от смены паролей

00:19:41.980 --> 00:19:44.520
и оставляет грязные следы в журналах аудита.

00:19:44.740 --> 00:19:48.940
Нет четкой ответственности, и в конечном итоге право доступа блокирует конвейер,

00:19:48.940 --> 00:19:53.200
когда исходный пользователь помечается как неактивный, удаляется или теряет доступ.

00:19:53.340 --> 00:19:55.260
На помощь приходят сервисные принципалы.

00:19:55.460 --> 00:19:58.160
Если вы с ними не работали, представьте сервисный принципал

00:19:58.160 --> 00:20:01.700
как цифровую пару дополнительных рук, созданных специально для автоматизации.

00:20:01.880 --> 00:20:03.540
В отличие от обычного пользователя,

00:20:03.840 --> 00:20:07.040
сервисный принципал привязан к регистрации приложения в Azure Red,

00:20:07.260 --> 00:20:08.460
а не к реальному человеку.

00:20:08.600 --> 00:20:10.500
Вы предоставляете ему минимальные разрешения,

00:20:10.720 --> 00:20:12.820
необходимые для выполнения задач по развертыванию.

00:20:13.060 --> 00:20:14.880
Звучит просто, но отдача огромна.

00:20:14.880 --> 00:20:18.480
Вместо зависимости от пользователя, который может уволиться или сменить должность,

00:20:18.660 --> 00:20:21.940
развертывания остаются последовательными, проверяемыми и очлеживаемыми.

00:20:22.080 --> 00:20:25.420
Каждая среда получает доступ только к нужным подключениям и ресурсам,

00:20:25.620 --> 00:20:28.480
а все изменения фиксируются для этой учетной записи робота.

00:20:28.620 --> 00:20:31.000
В случае сбоя у вас остается четкий журнал аудита,

00:20:31.180 --> 00:20:34.540
и вы не остаетесь осиротевшими потоками, которые никому исправить.

00:20:34.700 --> 00:20:36.940
Рассматривая проблему сопоставления коннекторов,

00:20:37.120 --> 00:20:40.140
подумайте, что происходит, когда среды начинают расходиться.

00:20:40.340 --> 00:20:43.800
Допустим, команда разработчиков получила одобрение на новый пользовательский коннектор.

00:20:43.800 --> 00:20:46.440
Предположим, он обращается к API «Песочнице».

00:20:46.440 --> 00:20:49.560
Когда приходит время перехода в прот, этот коннектор не просто отсутствует,

00:20:49.660 --> 00:20:52.700
он может быть даже запрещен политиками безопасности данных организации.

00:20:52.880 --> 00:20:54.380
Если вы забудете перенастроить его,

00:20:54.580 --> 00:20:58.140
приложение будет обращаться к неверной конечной точке или вовсе перестанет работать.

00:20:58.320 --> 00:21:01.600
Недавно я видел, как это обернулось серьезными проблемами для одной медицинской организации.

00:21:01.780 --> 00:21:05.240
Одна упущенная настройка коннектора привела к использованию тестовых данных в продакшене

00:21:05.240 --> 00:21:07.340
и едва не вызвала инцидент с нарушением комплайенса.

00:21:07.340 --> 00:21:10.300
Их автоматизированный конвейер экспортировал все по плану,

00:21:10.300 --> 00:21:14.660
но ссылка на коннектор внутри решения все еще указывала на старую тестовую базу данных,

00:21:14.820 --> 00:21:17.320
которую Power Platform не пометила как ошибочную,

00:21:17.440 --> 00:21:19.920
пока реальные данные не потекли по неверным каналам.

00:21:20.380 --> 00:21:22.780
Переменные среды призваны облегчить эту боль.

00:21:22.940 --> 00:21:25.920
В отличие от жестко прописанных конечных точек или API-ключей,

00:21:26.060 --> 00:21:29.100
переменные среды позволяют отделить то, что меняется в разных средах,

00:21:29.220 --> 00:21:30.840
от того, что остается неизменным.

00:21:30.980 --> 00:21:35.540
Вы можете менять конечные точки, API-ключи или другие секреты при каждом развертывании,

00:21:35.540 --> 00:21:37.680
не переписывая приложение или поток.

00:21:37.840 --> 00:21:41.540
Например, поток, работающий с таблицей Dataverse для разработки,

00:21:41.740 --> 00:21:44.440
при импорте можно перенастроить на рабочую таблицу,

00:21:44.720 --> 00:21:47.760
просто изменив переменную среды в процессе развертывания.

00:21:47.940 --> 00:21:50.620
Конвейеры GitHub Actions делают это практичным.

00:21:50.780 --> 00:21:53.860
Каждое задание может внедрить нужное значение в нужное время.

00:21:54.040 --> 00:21:55.900
Но даже здесь важна дисциплина.

00:21:56.000 --> 00:22:00.200
Стоит забыть обновить переменную или допустить утечку секретов между средами,

00:22:00.460 --> 00:22:02.880
и ваш рабочий процесс оказывается под угрозой.

00:22:02.880 --> 00:22:07.100
Microsoft подчеркивает необходимость тщательного определения области действия секретов

00:22:07.100 --> 00:22:09.300
и осознанного сопоставления ссылок на коннекторы.

00:22:09.500 --> 00:22:13.340
Их политики предотвращения потери данных, DLP, существуют не просто так.

00:22:13.500 --> 00:22:16.520
Они не дают конфиденциальной информации перемещаться между средами

00:22:16.520 --> 00:22:18.340
или появляться там, где не положено.

00:22:18.520 --> 00:22:22.780
Если попытаться обойти их, предоставляя общий доступ к переменным или подключениям,

00:22:22.820 --> 00:22:26.540
вы столкнетесь с проблемами корпоративной безопасности или комплайнс-контроля.

00:22:26.720 --> 00:22:28.760
Что еще важнее, вы теряете предсказуемость,

00:22:28.760 --> 00:22:33.100
так как стирается грань между тем, что предназначено для разработки, тестирования или продакшена.

00:22:33.220 --> 00:22:36.940
Трудно переоценить преимущества, которые вы получаете, если все настроено верно.

00:22:37.100 --> 00:22:40.100
Сервисные принципалы в сочетании с грамотно управляемыми переменными средой

00:22:40.100 --> 00:22:42.740
и правильно сопоставленными коннекторами преображают ваш конвейер.

00:22:42.880 --> 00:22:44.880
Ваши развертывания становятся предсказуемыми.

00:22:45.040 --> 00:22:47.600
Когда что-то ломается, у вас есть четкая цепочка ответственности,

00:22:47.680 --> 00:22:49.100
и вы точно знаете, где искать.

00:22:49.300 --> 00:22:52.580
Дело было в сопоставлении коннектора, переменной или упущенном разрешении.

00:22:52.780 --> 00:22:55.400
Аудиторы могут отследить изменения, и вам не придется волноваться,

00:22:55.400 --> 00:22:57.820
когда кто-то покидает организацию или меняет пароли.

00:22:57.940 --> 00:23:01.240
Все сводится к тому, чтобы относиться к секретам, коннекторам и сервисным принципалам

00:23:01.240 --> 00:23:02.560
как к чему-то по-настоящему важному.