Migracja aplikacji i przepływów ze środowiska domyślnego

W tym opracowaniu technicznym wyjaśniono, w jaki sposób organizacje i administratorzy mogą zaplanować migrację swoich aplikacji i przepływów z domyślnego środowiska.

Autorzy: Ravi Chada (Microsoft), Rui Santos (Microsoft)

Uwaga

Możesz zapisać lub wydrukować ten oficjalny dokument przez wybranie pozycji Drukuj w przeglądarce, a następnie wybranie pozycji Zapisz jako plik PDF.

Środowisko domyślne

Jedno domyślne środowisko jest tworzone dla każdej dzierżawy i jest dostępne dla wszystkich użytkowników w tej dzierżawie. Domyślne środowisko jest tworzone w regionie najbliższym do regionu domyślnego dzierżawcy Microsoft Entra i nosi nazwę: [nazwa dzierżawcy usługi Microsoft Entra (domyślna)]. Nowo zarejestrowany użytkownik w usłudze Power Apps lub Power Automate zostaje automatycznie dodany do roli twórcy środowiska domyślnego. Żaden użytkownik nie jest automatycznie dodawany do roli administratora środowiska w środowisku domyślnym.

Nie można usunąć domyślnego środowiska i nie można ręcznie utworzyć jego kopii zapasowej. Systemowe kopie zapasowe są sporządzane w trybie ciągłym. Wartość domyślna środowiska jest ograniczona do 1 TB pojemności magazynowania. Domyślne środowisko ma następujące możliwości:

• Pojemność bazy danych Dataverse: 3 GB
• Pojemność plików Dataverse: 3 GB
• Pojemność dziennika Dataverse: 1 GB

Sprawdzenie pojemności przeprowadzone przed utworzeniem nowych środowisk spowoduje wyłączenie uwzględnionej pojemności pamięci środowiska domyślnego podczas obliczania, czy dostępna jest wystarczająca pojemność do utworzenia nowego środowiska. Do przechowywania większej ilości danych można utworzyć środowisko produkcyjne.

W domyślnym środowisku pracownicy organizacji z licencją Microsoft 365 mogą tworzyć aplikacje i przepływy w chmurze. Domyślne środowisko staje się pierwszym studiem zabaw dla tych pracowników, którzy zaczynają tworzyć swoje aplikacje i przepływy. Ponieważ nie jest możliwe usunięcie roli twórcy środowiska z domyślnego środowiska, twórcy zaczynają tworzyć osobiste aplikacje i przepływy produktywności i udostępniać je w swoich zespołach, aby inni mogli z nich korzystać. Większość organizacji często zmienia nazwę domyślnego środowiska na Produkcja personalna.

Administratorzy reaktywnie odkrywają, że wiele aplikacji i przepływów jest tworzonych w środowisku domyślnym. Aplikacja lub przepływ może nie być odpowiedni w domyślnym środowisku w scenariuszach takich jak:

• Aplikacja jest udostępniana wielu użytkownikom w trybie produkcyjnym.
• Aplikacja korzysta ze skoroszytów programu Excel zawierających poufne dane.
• Aplikacja oparta na listach SharePoint otrzymuje wiele interakcji danych, takich jak wstawianie lub aktualizacje.
• Aplikacja lub przepływ korzysta z łączników, które nie są dozwolone w nowych zasadach zapobiegania utracie danych (DLP).
• Niestandardowe łączniki są włączone i używane w domyślnym środowisku, zamiast być zabezpieczone w dedykowanym środowisku.

Powyższe scenariusze są warte rozważenia i stanowią wskazówkę, że należy rozpocząć przenoszenie tych aplikacji i przepływów z domyślnego środowiska do ich własnego, deweloperskiego lub innego współdzielonego środowiska. Inne czynniki, które wchodzą w grę, to ograniczenia związane z domyślnym środowiskiem.

Zespoły Centrum doskonałości (CoE), które monitorują Power Platform, są zmuszone do reagowania po osiągnięciu limitów, co negatywnie wpływa na aplikacje działające w domyślnym środowisku. Ograniczenie to może być również czymś, co administrator lub zespół CoE musi regularnie wykonywać. Istnieją trzy szerokie etapy:

• Identyfikacja obiektów Power Platform
• Przenoszenie obiektów Power Platform
• Czyszczenie obiektów Power Platform

Istnieją różne sposoby eksportowania aplikacji i przepływów w celu przeniesienia ich do nowego środowiska. Rozwiązania to pojedynczy plik, który może zawierać prawie wszystko, co twórcy tworzą w Power Platform i przenosić je razem. Aplikacje oparte na kanwie i przepływy w chmurze można eksportować bezpośrednio.

Z biegiem czasu obiekty Power Platform ewoluowały, aby być świadomymi rozwiązań. Teraz aplikacje i przepływy mogą być domyślnie świadome rozwiązań, choć wymaga to ręcznej aktywacji. Twórcy mogą nadal tworzyć aplikacje i przepływy z witryn make.powerapps.com i make.powerautomate.com, które można sklasyfikować jako nieuwzględniające rozwiązania, i można je eksportować indywidualnie lub dodawać do rozwiązania. Dodając rozwiązanie, twórca może skorzystać ze zmiennych środowiskowych i odwołań do połączeń, aby skonfigurować i wdrożyć punkty końcowe w różnych środowiskach.

Celem jest dodanie wszystkich składników Power Platform do jednego rozwiązania, które umożliwia łatwe przenoszenie wielu składników jako jednej jednostki między środowiskami.

Identyfikacja obiektów Power Platform

Pierwszym krokiem jest zidentyfikowanie aplikacji, przepływów i zasobów, które należy przenieść lub wyczyścić. Zestaw startowy CoE zawiera spis wszystkich aplikacji i przepływów, a raporty Power BI pomagają określić ich wykorzystanie. Ten krok pomaga ocenić wykorzystanie aplikacji i powinien pomóc w ich oznaczeniu. Podczas wykonywania ćwiczenia należy pamiętać o etykiecie aplikacji i przepływów, które powinny zostać przeniesione do innego środowiska. Etykieta może być oparta na używanych łącznikach, lokalizacji użytkownika, dziale użytkownika itd. W tym artykule przedstawiono również metodę rozpoznawania elementów, które powinny zostać wyczyszczone lub przeniesione w oparciu o praktyki zapobiegania utracie danych (DLP).

Przenoszenie obiektów Power Platform

Jeśli składnik ma etykietę umożliwiającą przeniesienie do innego środowiska, dostępne są opcje przeniesienia aplikacji. Przeprowadzka jest procesem interaktywnym i wymaga pewnego poziomu interakcji ze strony twórcy. Poziom złożoności przenoszenia aplikacji lub przepływu wzrasta wraz z mieszanką składników użytych do zbudowania aplikacji lub przepływu.

Na przykład aplikacja z sześcioma ekranami ma 10 przycisków na wielu ekranach. Załóżmy, że każdy z tych 10 przycisków wywołuje indywidualny przepływ. Istnieje również kilka przepływów, które są uruchamiane codziennie w celu naprawy danych lub integracji danych z innym systemem. Załóżmy również, że istnieje model przetwarzania obrazu AI Builder, który jest wykorzystywany jako część automatyzacji. Aby przenieść taką aplikację, wszystkie składniki muszą zostać dodane do rozwiązania, a odniesienia do połączeń muszą zostać poprawnie dostosowane i przetestowane przed potwierdzeniem ukończenia.

W innym przypadku załóżmy, że istnieje aplikacja oparta na kanwie, która korzysta z połączenia Office 365. W takim przypadku twórca musi dodać do rozwiązania tylko aplikację opartą na kanwie.

Czyszczenie obiektów Power Platform

Jeśli składnik posiada etykietę do oczyszczenia, istnieją dwie główne opcje. Pierwszą opcją jest usunięcie go bezpośrednio, a drugą po wykonaniu kopii zapasowej. W drugim przypadku tworzenia kopii zapasowych może dojść do nakładania się kroków pokrywających się z poruszającymi się obiektami.

Przykładowo, administratorzy CoE Team uważają, że większość twórców tworzy aplikacje testowe i przepływy do celów edukacyjnych. Następnie twórcy porzucają aplikacje i przepływy, co można potwierdzić, patrząc na wskaźniki użytkowania. Innym sposobem jest poddanie aplikacji kwarantannie. Jeśli nikt nie zwróci się do Ciebie w sprawie aplikacji, można ją również usunąć.

Utrzymanie strategii komunikacji odgrywa kluczową rolę. Administratorzy powinni planować komunikację:

• Ustanowienie połączeń, na które twórcy muszą zezwolić podczas uruchamiania aplikacji w nowym środowisku.
• Nowy adres URL aplikacji ze środowiska docelowego.
• Nawigacja do właściwego środowiska.

Niektóre z tych rozwiązań do przenoszenia obiektów są gotowe i mogą wymagać samodzielnej Power Apps i Power Automate, które zapewniają użytkownikom możliwość tworzenia i uruchamiania aplikacji w źródłach danych wykraczających poza Microsoft 365.

Strategie

Cały proces identyfikacji i przenoszenia aplikacji i przepływów z domyślnego środowiska ma większe szanse powodzenia, gdy jest oparty na strategii. Należy rozważyć kilka strategii.

Strategia DLP

Zasady zapobiegania utracie danych (DLP) działają jak barierki, które pomagają zapobiegać niezamierzonemu ujawnianiu danych organizacyjnych przez użytkowników i chronić bezpieczeństwo informacji w dzierżawie. Zasady DLP wymuszają reguły, dla których są włączone łączniki dla poszczególnych środowisk oraz które złącza mogą być używane razem. Łączniki są klasyfikowane wyłącznie dane biznesowe, żadne dane biznesowe nie są dozwolone lub zablokowane. Łącznik w grupie "tylko dane biznesowe" może być używany z innymi łącznikami z tej grupy w ramach tej samej aplikacji lub przepływu. Zalecamy posiadanie co najmniej jednej polisy.

Identyfikacja obiektów przy użyciu DLP

Identyfikacja oparta na zasadach DLP jest pomocna w definiowaniu środowisk docelowych dla aplikacji i przepływów. Mogą istnieć aplikacje lub przepływy korzystające z łącznika, który jest blokowany przez DLP lub połączenie łączników biznesowych i niebiznesowych, które po aktywacji DLP przestają działać.

Aby zapobiec przestojom potencjalnie krytycznych obiektów, dzięki DLP, w zestawie startowym CoE można znaleźć narzędzie Edytor kodu DLP (analiza wpływu). Celem edytora kodu DLP jest umożliwienie administratorom zobaczenia wpływu istniejących zasad lub potencjalnego wpływu zmian zasad. Zapewnia administratorom wgląd w aplikacje i przepływy, na które ma wpływ, a także zasoby, które zostałyby wyłączone w przypadku wymuszenia nowych lub zaktualizowanych zasad. Aplikacja może być wykorzystywana do przeglądu istniejących zasad, zmiany istniejących zasad i ograniczania ryzyka poprzez kontaktowanie się z twórcami i informowanie ich o najlepszym sposobie działania dla ich aplikacji lub przepływu.

Zaktualizuj istniejące zasady DLP, aby przejrzeć wpływ. Więcej informacji na temat edytora kodu DLP można znaleźć w artykule Ustanawianie higieny dzierżawy za pomocą zestawu startowego CoE.

Przed włączeniem funkcji DLP można zidentyfikować, które aplikacje i przepływy są dotknięte i ostrzec twórców. Edytor DLP może wysyłać listę wszystkich aplikacji i przepływów, których to dotyczy, na adres e-mail, który generuje plik .csv dla każdego typu obiektu.

Korzystając z edytora DLP w wersji 2.0, w obszarze Analiza wpływu wybierz opcję Eksportuj aplikacje i przepływy, których dotyczy wpływ, do pliku CSV.

Każdy wygenerowany plik csv (flow.csv i apps.csv) zawiera informacje dotyczące:

1. Nazwy aplikacji i przepływów.
2. Właściciel aplikacji i przepływów.
3. OwnerEmail aplikacji i przepływów.
4. Wszystkie połączenia używane przez aplikacje i przepływy.
5. Identyfikator aplikacji i przepływów w celu identyfikacji obiektu.
6. Identyfikator środowiska, w którym znajdują się aplikacje i przepływy.

Zauważ, że Połączenia zawierają listę wszystkich połączeń używanych przez aplikację lub przepływ. Jeśli trzeba dokładnie określić, na który łącznik ma wpływ dany DLP, w tym momencie potrzebna jest automatyzacja. Rozważamy zmianę tej sytuacji w narzędziu.

Przykład implementacji w celu identyfikacji połączenia:

1. Utwórz przepływ Power Automate.

2. Użyj łącznika Pobierz politykę DLP dzierżawy określając DLP, o którym mowa.

3. Wynikiem są dwie tablice, dane biznesowe i dane niebiznesowe. Jako przykład, łącznik Twittera pokazuje ten kod:

   [
     {
       "id": "/providers/Microsoft.PowerApps/apis/shared_twitter",
       "name": "Twitter",
       "type": "Microsoft.PowerApps/apis"
     }
   ……
   ]
   

4. Z tej listy można uzyskać dostęp do nazwy łącznika, która jest zgodna z listą nazw aplikacji csv lub kolumny przepływu Łącznik.

5. Konwertując plik csv do formatu Excel i umieszczając go w usłudze OneDrive, można odczytać wszystkie aplikacje i przepływy, na które ma to wpływ, z następujących źródeł Power Automate. Sprawdza, które połączenie jest dotknięte na podstawie logiki, która porównuje połączenia z nazwami łączników.

6. Po ustaleniu, które połączenie powoduje wpływ, należy wygenerować nową listę zawierającą identyfikator aplikacji lub przepływu oraz łącznik, którego dotyczy DLP.

7. Wykorzystaj wcześniejsze informacje, aby powiadomić twórcę o przyszłym wpływie. Możesz użyć Power Cards, aby zebrać informacje zwrotne od twórcy, jeśli aplikacja lub przepływ mogą zostać usunięte lub wymagają migracji do innego środowiska.

Na podstawie przeprowadzonej analizy, jeśli okaże się, że przepływy, których to dotyczy, nie są używane, można umieścić je w kwarantannie i wysłać wiadomość e-mail do twórcy z instrukcjami, jak przenieść je do innego środowiska. Zachęca to do kultury "zrób to sam" (DIY) i usuwa cień IT. W niektórych sytuacjach może być konieczne wyłączenie niektórych obiektów z DLP. Na przykład, możesz chcieć zastosować określoną DLP tylko dla nowych zasobów, które zostały utworzone i zwolnić bieżące zasoby. Aby uzyskać więcej informacji na temat wyłączenia zasobów DLP, zobacz Wyłączenie zasobów DLP.

W rzeczywistości strategia środowiska jest definiowana za pomocą DLP i zapewnia miejsce docelowe dla aplikacji i przepływów opracowanych w środowisku domyślnym.

Strategia dotycząca środowisk

Opracowanie strategii środowiska wymaga skonfigurowania środowisk i innych warstw bezpieczeństwa danych w sposób, który wspiera produktywny rozwój w organizacji, jednocześnie zabezpieczając i organizując zasoby. Strategia zarządzania udostępnianiem środowiska, zarządzaniem dostępem i kontrolowaniem zasobów w ich obrębie jest ważna:

• Zabezpieczenie danych i dostęp.
• Zarządzaj domyślnym środowiskiem w sposób zgodny z przepisami.
• Zarządzaj prawidłową liczbą środowisk, aby uniknąć Sprawl i oszczędzać wydajność.
• Ułatwienie i wdrożenie zdrowego zarządzania cyklem życia aplikacji (ALM).
• Organizowanie zasobów na partycjach logicznych.
• Operacje pomocy technicznej (i działy pomocy) umożliwiające identyfikowanie aplikacji w produkcji, dzięki czemu są one używane w środowiskach dedykowanych.
• Zagwarantować, że dane są przechowywane i przesyłane do dopuszczalnych regionów geograficznych (ze względów wydajności i zgodności).
• Zapewnianie izolacji opracowywanych aplikacji.
• Włączenie wewnętrznych usług fakturowania dla użytkowników końcowych lub jednostek biznesowych korzystających z usług.

Powinieneś mieć dobrze ugruntowane działy, które mogą być samowystarczalne i mają istniejące procesy ALM. W takich przypadkach środowiska zapewniają izolację i organizują zasoby w oparciu o dział. Opartą na tym strategię można osiągnąć, tworząc oddzielne środowiska dla każdego działu. Środowiska te stają się następnie miejscem docelowym dla aplikacji i przepływów w środowisku domyślnym.

Strategia komunikacji

Skuteczna komunikacja ma kluczowe znaczenie podczas procesu migracji. Komunikacja odbywa się na wszystkich etapach procesu migracji. Jasna komunikacja sprzyja zrozumieniu i współpracy między interesariuszami. Umożliwia płynny przepływ informacji, zapewniając, że wszyscy zaangażowani są dobrze poinformowani o planach migracji, postępach i wszelkich potencjalnych wyzwaniach.

W ramach migracji i oczyszczania należy upewnić się, że proces ten przebiega sprawnie dla twórców, interesariuszy i kierownictwa. Opracuj strategię dotyczącą tego, jak najlepiej się komunikować i w jakich momentach należy się komunikować, co zapewni spójność celów i pomoże w komunikacji dla wszystkich zaangażowanych stron. Niektóre opcje do rozważenia obejmują:

• Użyj zestawu startowego CoE jako narzędzia do śledzenia zasobów.
• Dodaj niestandardowe przepływy w chmurze, aby wysyłać powiadomienia na różnych etapach.
• Twórz szablony wiadomości e-mail, które będą wysyłane w celu komunikacji z twórcami.

Należy pamiętać o następujących kwestiach:

• Zmiana adresu URL aplikacji. Użytkownicy aplikacji muszą zaktualizować wszelkie zakładki do aplikacji w domyślnym środowisku.
• Jeśli istnieje przepływ wyzwalania protokołu HTTP oparty na adresie URL, który należy zaktualizować w przepływach zależnych, aby upewnić się, że wciąż działa jako link sieci web.
• Zapewnij szczegółowe kroki w celu ustanowienia połączeń po zakończeniu przenoszenia zarówno dla twórców, jak i użytkowników aplikacji. Użytkownicy nie powinni martwić się o tworzenie połączenia, gdy uruchamiają aplikację po raz pierwszy z nowego środowiska.

Dobry początek konfiguracji komunikacji wymaga modelu samoobsługowego, aby skalować i być bardziej realnym dla użytkowników niż pozostawienie go tylko dla poczty e-mail pojedynczego użytkownika lub listy dystrybucyjnej. Jeśli planujesz utworzyć witrynę SharePoint, dostępny jest szablon, którego możesz użyć do utworzenia wewnętrznego huba Microsoft Power Platform. Centrum staje się wspólnym miejscem do poznawania strategii i wskazówek, dzięki czemu twórcy mogą podejmować właściwe decyzje dotyczące tego, co zamierzają zbudować i gdzie powinni to zrobić.

Istnieją pewne istniejące składniki rozwiązań, takie jak konfigurowanie składników powiadomień o braku aktywności i konfigurowanie składników zgodności deweloperów w zestawie startowym CoE, z których można skorzystać. składniki te są dostarczane z szablonami wiadomości e-mail i można je powielać, aby dopasować je do celu i potrzeby migracji z domyślnego środowiska. Dobrym dodatkiem jest również rejestrowanie historii sukcesu na stronie komunikacyjnej.

Odbiorcy

W procesie migracji w komunikację zaangażowani są zazwyczaj różni odbiorcy. Oto najbardziej typowi kluczowi interesariusze i ich role:

• Właściciele aplikacji: Właściciele aplikacji to osoby lub zespoły odpowiedzialne za tworzenie, konserwację i zarządzanie określonymi aplikacjami. Posiadają dogłębną wiedzę na temat funkcjonalności, przepływu pracy i konfiguracji swoich aplikacji. Komunikacja z właścicielami aplikacji ma kluczowe znaczenie dla zrozumienia ich specyficznych wymagań, zbierania opinii, rozwiązywania wątpliwości i zapewnienia płynnej migracji ich aplikacji do nowego środowiska.
• Użytkownicy aplikacji: Użytkownicy aplikacji to osoby, które regularnie korzystają z aplikacji do wykonywania swoich zadań lub przepływów pracy. Mogą oni mieć różny poziom wiedzy technicznej i znajomości aplikacji. Komunikacja z użytkownikami aplikacji jest ważna, aby poinformować ich o migracji, zapewnić aktualizacje dotyczące wszelkich zmian lub zakłóceń, które mogą wystąpić, zaoferować szkolenia lub wsparcie w celu zapewnienia płynnego przejścia i zminimalizować wpływ na ich codzienne operacje.
• Szefowie lub kierownicy działów: Kierownicy lub kierownicy działów odgrywają znaczącą rolę w procesie migracji, ponieważ nadzorują operacje i cele strategiczne swoich działów. Muszą oni zostać poinformowani o harmonogramie migracji, potencjalnych skutkach i korzyściach. Komunikacja z kierownikami działów pozwala im zapewnić niezbędne wskazówki, dostosować migrację do celów działów i zapewnić płynną koordynację w ich zespołach.
• Zespoły IT lub techniczne: zespoły IT lub techniczne są odpowiedzialne za infrastrukturę, systemy i ogólne aspekty techniczne migracji. Są oni zaangażowani w planowanie, realizację i wsparcie procesu migracji. Komunikacja z zespołami IT jest niezbędna do omówienia wymagań technicznych, zależności, kwestii bezpieczeństwa oraz wszelkich niezbędnych zmian w infrastrukturze lub konfiguracji, które należy wdrożyć w celu pomyślnej migracji.
• Zespoły ds. zabezpieczeń i zgodności: Zespoły ds. zabezpieczeń i zgodności odgrywają kluczową rolę w zapewnianiu bezpieczeństwa danych, prywatności i zgodności z przepisami podczas migracji. Dostarczają wskazówek i zapewniają, że stosowane są odpowiednie środki w celu ochrony wrażliwych informacji. Komunikacja z zespołami ds. bezpieczeństwa i zgodności obejmuje omawianie wymagań bezpieczeństwa, protokołów szyfrowania, kontroli dostępu i wszelkich kwestii związanych ze zgodnością w trakcie całego procesu migracji.
• Kadra kierownicza: Kadra kierownicza, w tym kadra kierownicza wyższego szczebla lub kadra kierownicza wyższego szczebla, powinna być na bieżąco informowana o procesie migracji. Mogą nie wymagać szczegółowych, technicznych informacji, ale powinni być świadomi celów projektu, postępów i potencjalnego wpływu na organizację. Komunikacja z kadrą kierowniczą pomaga zapewnić jej wsparcie, zgodność z celami strategicznymi i alokację zasobów na potrzeby migracji.

Ważne jest, aby dostosować strategie komunikacji i komunikaty dla każdego odbiorcy, biorąc pod uwagę jego specyficzne potrzeby, obawy i poziom zrozumienia technicznego. Jasna i terminowa komunikacja ze wszystkimi zainteresowanymi stronami sprzyja współpracy, zapewnia płynną koordynację i łagodzi wszelkie potencjalne wyzwania podczas procesu migracji.

Tempo

Kadencja lub częstotliwość komunikacji z interesariuszami podczas procesu migracji różni się w zależności od konkretnych potrzeb i dynamiki projektu. Ważne jest, aby ustanowić regularną i spójną komunikację, aby informować interesariuszy, rozwiązywać obawy i utrzymywać zgodność podczas migracji. Oto kilka kwestii, które należy wziąć pod uwagę przy ustalaniu częstotliwości komunikacji z różnymi interesariuszami:

• Właściciele aplikacji: Utrzymywanie częstej komunikacji z właścicielami aplikacji przez cały proces migracji jest ważne. Obejmuje to regularne aktualizacje dotyczące postępów migracji, rozwiązywanie wszelkich wątpliwości i angażowanie właścicieli aplikacji w podejmowanie decyzji, gdy jest to konieczne. Częstotliwość komunikacji może się różnić w zależności od złożoności i krytyczności aplikacji, ale zaleca się regularne sprawdzanie i terminowe odpowiadanie na zapytania.
• Użytkownicy aplikacji: Angażuj użytkowników aplikacji za pośrednictwem regularnych kanałów komunikacji, aby informować ich o migracji. Powinno to obejmować ogłoszenia, e-maile, biuletyny, a nawet dedykowane sesje szkoleniowe lub warsztaty. Częstotliwość komunikacji z użytkownikami aplikacji może być różna, ale kluczowe jest dostarczanie aktualizacji w kluczowych punktach kontrolnych, informowanie ich o wszelkich zmianach lub zakłóceniach, które mogą mieć na nich wpływ, a także oferowanie wsparcia i wskazówek w trakcie całego procesu.
• Szefowie działów i kierownicy: Komunikacja z szefami działów i kierownikami może odbywać się w regularnych odstępach czasu lub w razie potrzeby, w zależności od znaczenia migracji do ich działów. Zapewnianie okresowych aktualizacji dotyczących ogólnych postępów, harmonogramów i wpływu na ich zespoły.
• Zespoły IT lub techniczne: Angażuj się w regularną komunikację z zespołami IT i technicznymi zaangażowanymi w migrację. Obejmuje to bieżącą współpracę, dzielenie się aktualizacjami dotyczącymi pytań lub kwestii technicznych oraz koordynowanie wszelkich niezbędnych konfiguracji lub zmian. Częstotliwość komunikacji jest zazwyczaj wyższa w fazie planowania i analizy. Na etapie wdrażania należy organizować regularne punkty kontaktowe lub spotkania, aby zapewnić płynną koordynację.

Zasoby

Efektywne zarządzanie zasobami ma kluczowe znaczenie dla udanej migracji. Oto kilka kluczowych aspektów, które należy wziąć pod uwagę, jeśli chodzi o zarządzanie zasobami podczas migracji:

• Identyfikacja zasobów: Zidentyfikuj zasoby wymagane do projektu migracji, w tym osoby lub zespoły odpowiedzialne za zadania, takie jak przygotowania przed migracją, migracja danych, testowanie, wdrażanie, konfiguracja i wsparcie po migracji. Określ konkretne umiejętności, wiedzę i dyspozycyjność potrzebne do pełnienia każdej roli.
• Alokacja zasobów: Przypisywanie zasobów do ról i zadań na podstawie umiejętności, dostępności i obciążenia zasobu. Zapewnienie odpowiedniego przydziału zasobów w celu zrównoważenia obciążenia pracą i dotrzymania terminów projektów. Rozważ wszelkie zależności lub ograniczenia, które mogą mieć wpływ na alokację zasobów, takie jak wspólne zasoby w wielu projektach.
• Rozwój umiejętności i szkolenie: Oceń umiejętności i luki w wiedzy w zespole i zapewnij niezbędne szkolenia lub możliwości podnoszenia kwalifikacji, aby zapewnić, że zasoby są odpowiednio wyposażone do przydzielonych im zadań. Może to obejmować zapewnienie sesji szkoleniowych, warsztatów lub dostępu do odpowiednich zasobów i dokumentacji.
• Komunikacja i współpraca: Wspieranie skutecznej komunikacji i współpracy między zasobami zaangażowanymi w migrację. Zachęcanie do regularnych aktualizacji statusu, spotkań koordynacyjnych i dzielenia się wiedzą, aby zapewnić, że wszyscy członkowie zespołu są zgodni, poinformowani i pracują razem na rzecz wspólnych celów.
• Planowanie awaryjne: Przewiduj potencjalne ograniczenia zasobów lub ryzyko i opracowuj plany awaryjne. Zidentyfikuj zasoby zapasowe lub przekwalifikuj się na krytyczne role, aby złagodzić wszelkie nieprzewidziane wyzwania, takie jak nieoczekiwane nieobecności lub ograniczenia zasobów.
• Zaangażowanie interesariuszy: Informuj interesariuszy, takich jak właściciele aplikacji, szefowie działów i kierownictwo, o alokacji zasobów i potencjalnym wpływie na harmonogramy lub produkty końcowe. Regularne informowanie o aktualizacjach zasobów, raportach z postępów i wszelkich zmianach w planach zasobów w celu zarządzania oczekiwaniami i utrzymania przejrzystości.

Indywidualna migracja obiektów

Rozróżnienie między aplikacją a rozwiązaniem jest bardzo ważne. Eksportowanie i importowanie aplikacji ma wpływ tylko na ten obiekt. Rozwiązanie to kontener, który może zawierać wiele aplikacji, przepływów i innych obiektów.

Eksportowanie i importowanie aplikacji opartej na kanwie (starszy sposób)

Szczegółowe kroki zostały udokumentowane w Eksportowanie pakietu aplikacji opartej na kanwie oraz Importowanie pakietu aplikacji opartej na kanwie.

Ta metoda eksportowania aplikacji jest starszą metodą. Chociaż jest to obsługiwane, zalecamy korzystanie z rozwiązań. Rozwiązania umożliwiają migrację wielu składników zamiast tylko jednego zasobu.

Przepływ eksportu i importu (dotychczasowy sposób)

Poniższe kroki opisują sposób eksportowania przepływu.

1. Wybierz menu "...", wybierz Eksportuj, a następnie wybierz Pakiet (.zip).
2. Wprowadź nazwę i opis pakietu. Następnie można skonfigurować ustawienia domyślne i dodać komentarze, które będą dostępne w fazie importu.
3. Naciśnij przycisk Eksport widoczny w prawym dolnym rogu ekranu, aby pobrać pakiet. Jeśli pobieranie nie rozpocznie się automatycznie, możesz wybrać przycisk Pobierz.

Poniższe kroki opisują sposób importowania przepływu.

1. Wybieranie przycisku importu.
2. Prześlij plik pakietu i poczekaj, aż na ekranie pojawią się szczegóły pakietu.
3. Podczas konfigurowania ustawień przepływu można utworzyć nowy przepływ lub zaktualizować istniejący za pomocą definicji przepływu z pakietu.
4. Wybierz połączenia wymagane do skonfigurowania przepływu. Przycisk Importuj powinien być dostępny po pomyślnym skonfigurowaniu wszystkich wymaganych ustawień.

Po zaimportowaniu przepływu należy go aktywować. Jeśli przepływ ma jakiekolwiek odniesienia do połączeń, aktywujący go użytkownik musi mieć dostęp do tych połączeń. Jeśli nie, właściciel połączenia może przyznać dostęp użytkownikowi aktywującemu.

Ta metoda eksportowania przepływów w chmurze jest starszą metodą. Chociaż jest to obsługiwane, zalecamy korzystanie z rozwiązań, które umożliwiają migrację wielu składników zamiast tylko jednego zasobu.

Eksportowanie i importowanie aplikacji opartej na modelu

Aplikacja oparta na modelu jest zawsze częścią rozwiązania. Spakowana aplikacja, zawarta w pliku rozwiązania (.zip), może być udostępniana użytkownikom w oparciu o ich role zabezpieczeń po pomyślnym wyeksportowaniu ze środowiska źródłowego i zaimportowaniu do środowiska docelowego.

Szczegółowe procesy krok po kroku opisano w Eksportowaniu rozwiązania i Importowaniu rozwiązania.

Eksportowanie i importowanie bota Microsoft Copilot Studio

Boty można eksportować i importować za pomocą rozwiązań. Szczegółowa lista kroków została opisana w Eksportowanie i importowanie botów przy użyciu rozwiązań.

Eksport i import witryny Power Pages

Migracja obejmuje eksportowane istniejącej konfiguracji ze źródłowego środowiska Microsoft Dataverse, a następnie importowanie jej do docelowego środowiska Dataverse. Istnieją pewne kroki wstępne, które muszą zostać wykonane w środowisku docelowym. Po zakończeniu prac przygotowawczych dane konfiguracyjne portalu można wyeksportować za pomocą narzędzia do migracji konfiguracji.

Aplikacja SharePoint Form - przypadek specjalny dla środowiska domyślnego

SharePoint Aplikacje formularzy mogą być skojarzone tylko z jednym środowiskiem, a jeśli nie są skonfigurowane w inny sposób, znajdują się w środowisku domyślnym. Migracja wszystkich aplikacji wymaga ustawienia miejsca docelowego jako innego środowiska zamiast środowiska domyślnego. Istniejące niestandardowe formularze nie są automatycznie migrowane do nowego środowiska. Dla niestandardowych formularzy programu SharePoint można wyznaczać tylko środowiska produkcyjne. Następuje proces ręczny, podobnie jak przenoszenie aplikacji opartej na kanwie.

Tworzenie kopii zapasowych obiektów Microsoft Power Platform

Większość obiektów Microsoft Power Platform jest eksportowana jako pliki zip. Jeśli nie, mają co najmniej jeden format pliku. Pliki te w oryginalnym formacie, jako plik zip lub z dowolnym rozszerzeniem, można dodać do dowolnej lokalizacji przechowywania plików lub wybranego repozytorium. Kilka opcji, o których warto wspomnieć, to Azure DevOps, GitHub, SharePoint, One Drive lub inne rozwiązanie obsługujące wszystkie formaty plików.

Opcje masowej migracji

Migracja aplikacji lub przepływu jest udana, jeśli działa ona w taki sam sposób jak wcześniej. Istnieją jednak pewne elementy, których nie można przenieść:

• Dane przebiegu przepływu dotyczące poprzednich przebiegów przepływu — dane dotyczące przebiegów przepływu są przechowywane tylko przez 28 dni. Jeśli potrzebujesz danych, możesz je wyeksportować i zapisać za pomocą zestawu startowego CoE lub jeśli masz ustawiony eksport do data lake. Najnowsza wersja zestawu startowego CoE zawiera dane przebiegu przepływu, jeśli jest używana z funkcją Data Export.
• Wersje aplikacji kanwy — w miarę iteracji twórców w procesie tworzenia może być tworzonych wiele wersji. Wcześniejsze wersje nie mogą być migrowane. Migrować można tylko najnowszą wersję.
• Dane, do których uzyskuje się dostęp przez aplikację lub przepływ albo przy użyciu łączników — w ramach eksportu są uwzględniane tylko metadane aplikacji.

Wszelkie komentarze dotyczące współpracy dokonane w aplikacji lub przepływie również nie są uwzględniane.

Niniejszy artykuł przedstawia kilka możliwości. Ważne jest, aby przed podjęciem decyzji dokładnie rozważyć konsekwencje i zalety każdej z możliwości.

Migruj wszystko – opcja tworzenia kopii zapasowej i przywracania bazy danych

Podobnie jak w przypadku większości typów środowisk, domyślne środowisko jest również archiwizowane. Kopie zapasowe systemu są wykonywane automatycznie. Nie ma opcji na żądanie dla domyślnego środowiska, więc wymaga to zgłoszenia do pomocy technicznej. Kopia zapasowa może zostać przywrócona do nowego środowiska z zachowaniem wszystkich danych Dataverse. Ta opcja ma na celu jedynie pokazanie czytelnikowi jej istnienia i poinformowanie go, kiedy należy ją rozważyć. Nie powinno to być głównym wyborem, ponieważ przyniosłoby to tylko częściową migrację.

• Obsługiwane: Dataverse, Aplikacje Dynamics
• Nie w pełni obsługiwane: aplikacja Canvas, biblioteka składników, strony niestandardowe, Power Automate Microsoft Copilot Studio

Brak pełnej obsługi oznacza, że podczas migracji może dojść do potencjalnej utraty danych i wymagane są dalsze kroki.

Migracja metadanych, a następnie danych

Zalecanym podejściem jest użycie rozwiązań do przenoszenia metadanych, a następnie do przesyłania danych można użyć przepływów danych, Azure Data Factory lub innego preferowanego narzędzia. Pełna automatyzacja od początku do końca może nie być osiągalna we wszystkich przypadkach ze względu na różnorodne łączniki, ale możliwe jest bliskie przybliżenie.

Na wysokim poziomie kroki te są następujące:

1. Dodaj aplikację do rozwiązania.
2. Dodaj przepływ do rozwiązania.
3. Dodaj istniejące boty.
4. Dostosowywanie odniesień do połączeń w aplikacjach i przepływach.
5. Sprawdź zależności rozwiązania i dodaj obiekty.
6. Wyeksportuj rozwiązanie
7. Importuj rozwiązanie.
8. Przesyłanie danych.

Sprawdzanie zależności rozwiązania

Powodzenie importu rozwiązania w środowisku docelowym można zapewnić tylko wtedy, gdy wszystkie powiązane składniki zostały dodane do rozwiązania lub są dostępne w środowisku docelowym. Jeśli brakuje składników, import rozwiązania może się nie powieść. Aby zapewnić obecność wszystkich wymaganych składników, istnieją opcje, które najlepiej stosować w połączeniu:

• Ręczne dodawanie wybranych składników do rozwiązania. W tym przypadku zakłada się, że wszystkie zależne składniki są już dostępne w środowisku docelowym.

• Użyj przycisku pokaż zależności z poziomu rozwiązania, aby umożliwić systemowi identyfikację zależności. Można dodać wszystkie zależności lub selektywnie dodać tylko te zależności, które nie istnieją w środowisku docelowym.

  

Dodawanie składnika do rozwiązania (ręcznie)

Zakładając, że rozwiązanie zostało utworzone, twórca będzie używać opcji menu dodawania istniejącego składnika w celu dodania istniejącej aplikacji, przepływu lub bota.

Dostosuj referencje połączenia

Aplikacje kanwy i przepływy obsługują połączenia w różny sposób. Przepływy używają odwołań do połączeń dla wszystkich łączników, podczas gdy aplikacje kanwy używają ich tylko dla niejawnie udostępnionych (nieOAuth) połączeń, takich jak SQL Uwierzytelnianie serwera.

Aktualizacja aplikacji w celu używania odwołań do połączeń zamiast połączeń

Aplikacje oparte na kanwie, które nie obsługują rozwiązań po dodaniu do rozwiązania, nie zostaną automatycznie zaktualizowane do korzystania z odwołań do połączeń. Odwołania do połączeń są kojarzone z aplikacjami kanwy tylko w momencie dodawania źródła danych do aplikacji. Aby zaktualizować aplikacje, należy:

1. Dodaj do rozwiązania aplikację, która nie jest świadoma rozwiązania.
2. Usuń połączenie z aplikacji.
3. Utwórz nowe odniesienie do połączenia w rozwiązaniu.
4. Dodaje połączenie zawierające odniesienie do powiązanego połączenia pracownika.

Aktualizowanie przepływu w celu używania odwołań do połączenia zamiast połączeń

Jeśli przepływ nie znajduje się w rozwiązaniu, używa połączeń. Jeśli ten przepływ zostanie następnie dodany do roztworu, będzie on nadal początkowo wykorzystywał połączenia. Przepływy można zaktualizować tak, aby używały odwołań do połączeń zamiast połączeń, na jeden z dwóch sposobów:

• Jeśli przepływ zostanie wyeksportowany w rozwiązaniu niezarządzanym i zaimportowany, połączenia zostaną usunięte wraz z odniesieniami do połączeń.

• Po otwarciu przepływu rozwiązania narzędzie do sprawdzania przepływu na stronie szczegółów przepływu wyświetla ostrzeżenie o używaniu odwołań do połączeń. Komunikat ostrzegawczy zawiera akcję, którą można wybrać, aby Usuń połączenia, aby można było dodać odniesienia do połączeń. Wybranie tej akcji spowoduje usunięcie połączeń z wyzwalacza i akcji w przepływie oraz umożliwi wybranie i utworzenie referencji połączeń.

Dodawanie obiektu do rozwiązania (automatyzacja)

Za pomocą poleceń PowerShell można zbiorczo przenosić aplikacje do rozwiązania. Dodawanie wcześniej istniejących aplikacji opartych na kanwie i przepływów w chmurze do rozwiązań można również wykonać za pomocą wiersza poleceń. Zainstaluj najnowsze moduły PowerShell, aby wypróbować tę opcję. Dwa główne polecenia to Set-PowerAppAsSolutionAware and Set-FlowAsSolutionAware.

Po zainstalowaniu modułów wprowadź własny identyfikator środowiska, identyfikator aplikacji, identyfikator przepływu i identyfikator rozwiązania.

Dla aplikacji opartej na kanwie:

Set-PowerAppAsSolutionAware -EnvironmentName {Environment ID} -AppName {App ID} -SolutionId {Solution ID}

Dla przepływu:

Set-FlowAsSolutionAware -EnvironmentName {Environment ID} -FlowName {Flow ID} - SolutionId {Solution ID}

Odwołania do połączeń są wpisami danych do tabeli odwołania do połączenia. Użycie odniesienia do połączenia jako części aplikacji lub przepływu wymaga modyfikacji głównej definicji aplikacji lub przepływu. Musisz zastąpić węzeł connectionReferences odniesieniem do połączenia.

Importowanie i eksportowanie rozwiązania

Zakładając, że rozwiązania są gotowe, kolejny etap automatyzacji można przeprowadzić na wiele sposobów:

• Ręcznie eksportuj i importuj rozwiązania do środowiska docelowego.

• Użyj pakietów, aby przenieść wiele rozwiązań w jednym przebiegu.

• Użyj zadań narzędzi budowania Power Platform, aby wykonać wiele operacji, takich jak pakowanie rozwiązania, rozpakowywanie rozwiązania, eksportowanie rozwiązania i importowanie rozwiązania. DevOps zapewnia możliwość automatyzacji zarządzania cyklem życia aplikacji (ALM), a wszystkie te zadania są tworzone w celu wsparcia ALM dla Microsoft Power Platform.

Interfejs wiersza poleceń (CLI) Power Platform zapewnia również opcje eksportu i importu rozwiązań. Wszystkie związane z rozwiązaniem polecenia mogą być używane do budowania, eksportowania i importowania rozwiązań. Można również użyć CLI do przesyłania danych do i z platformy.

Opcją przyjazną dla twórców jest użycie potoków, które mają na celu demokratyzację ALM dla Power Platform. Połączenie automatyzacji ALM i możliwości ciągłej integracji/ciągłego wdrażania (CI/CD) w jedną usługę jest bardziej przystępne dla wszystkich twórców, administratorów i programistów.

Tworzenie połączeń (ręcznie)

W środowisku docelowym przed ustawieniem operacji importu utwórz brakujące połączenia, które są wymagane przez aplikację lub przepływ. Aby uzyskać więcej informacji na temat tworzenia połączeń, zobacz Zarządzanie połączeniami w Power Automate.

Migracja danych

Dostępnych jest wiele opcji migracji danych, od ręcznej po pełną automatyzację.

• Ręczny eksport i import danych przy użyciu skoroszytów programu Excel.
• Przepływ w chmurze Power Automate można opracować w celu wyodrębniania danych z tabel źródłowych i zapisywania ich bezpośrednio w miejscu docelowym. Wymaga to jednak od producenta korzystania z Dynamics 365 Connector lub Dataverse (starszego) łącznika. Obecnie łącznik Dataverse nie obsługuje połączeń między środowiskami. Ta funkcja jest planowana na przyszłość, a po jej wydaniu może być używana do przenoszenia danych z jednego do drugiego.
• Narzędzie do migracji konfiguracji (CMT) to narzędzie, które służy do migracji portalu, ale może być również używane do zwykłej migracji danych. CMT może być również używany z PowerShell. Narzędzie PAC CLI daje możliwość wywołania CMT.
• Przepływy danych mogą być wykorzystywane do tworzenia mapowań między środowiskami i używane do przenoszenia danych. Łącznik HTTP Web może być używany jako alternatywa dla Dataverse.
• Azure Data Factory może być używany z łącznikiem Dataverse do pobierania danych ze źródła i wstawiania ich do miejsca docelowego.

Biorąc pod uwagę, że domyślne środowisko ma ograniczony rozmiar, jedna z powyższych opcji powinna wystarczyć do przeniesienia danych poza domyślne środowisko.

Uwagi dotyczące czyszczenia

Czyszczenie jest dobrym pomysłem w przypadku aplikacji i przepływów, które nie były używane i aktualizowane od dłuższego czasu. Istnieją różne ścieżki, które administrator może rozważyć, jeśli chodzi o czyszczenie.

• Wybierz kolejność importowania danych. Najmniej zależne tabele znajdują się na początku, a najbardziej zależne na końcu.
• Nie wszystkie pola muszą być mapowane. Pola takie jak Wersja, Data modyfikacji, Data utworzenia i niektóre inne pola systemowe nie muszą być mapowane.
• Jeśli chcesz zachować oryginalną wartość Data utworzenia, zamapuj źródłowe pole Data utworzenia na pole OverRiddenCreatedOn w tabeli docelowej.
• Dane audytu nie mogą być migrowane.
• Nie włączaj żadnych przepływów pracy ani przepływów, które są wyzwalane na podstawie wstawiania danych, chyba że jest to zamierzone. Wydłuża to czas migracji danych.

Opcje etykiety

Zestaw startowy CoE nie ma obecnie opcji etykiety. Może to być jednak dostosowanie, które można dodać do zestawu startowego.

Utwórz tabelę o nazwie Etkiety i skonfiguruj relację wiele-do-wielu (N:N) z aplikacją, przepływami i innymi tabelami zapasów. Następnie można utworzyć etykietę i powiązać te rekordy z odpowiednimi pozycjami zapasów. Aby zapewnić lepsze wrażenia użytkownika, można osadzić siatkę w formularzu Głównym aplikacji, przepływów i innych tabel zasobów. Ta opcja jest zalecana, ponieważ zapewnia spójność referencyjną.

Utwórz pole tekstowe w każdej tabeli zapasów i użyj go do przechwycenia tekstu (etykiety), którego możesz później użyć.

Jeśli chcesz mieć bardziej stałą listę, utwórz globalny zestaw opcji i dodaj go do wszystkich tabel zapasów i ich formularzy.

Opcja kwarantanny

Jeśli nie masz pewności co do konieczności korzystania z niektórych aplikacji, możesz spróbować odizolować je na jakiś czas i poddać kwarantannie w tym stanie. Aplikacja może być używana tylko przez właściciela. Po upływie odpowiedniego czasu i braku odpowiedzi ze strony właściciela, można usunąć je ze środowiska.

Przepływy nie obsługują stanu kwarantanny, ale można zastosować podobne podejście, zatrzymując przepływ i sprawdzając, czy zostanie on ponownie aktywowany przez właściciela.

W obu przypadkach ważna jest odpowiednia komunikacja z właścicielem.

Tylko opcja Usuń

Jeśli naprawdę nie ma utraty produktywności i ponownego wykorzystania obiektów, ta opcja jest najlepsza. Większość przepływów testowych i aplikacji należy do tej kategorii.

W takim przypadku, po zidentyfikowaniu listy obiektów, można opracować partię PowerShell i przekazać do niej listę csv, która następnie usunie wszystkie te zasoby.

Podczas przeglądania identyfikatorów aplikacji i przepływów można użyć następującego polecenia, aby usunąć je z domyślnego środowiska.

• Remove-AdminFlow -EnvironmentName Default-[Guid] -FlowName [Guid]
• Remove-AdminPowerApp -AppName [Guid] -EnvironmentName [Guid]

Kopia zapasowa obiektów i opcja usuwania

Jako przykład załóżmy, że przepływ Power Automate został utworzony w celu zaspokojenia określonej potrzeby sezonowej, ale nie był używany przez długi czas. W takim przypadku dobrze jest wykonać kopię zapasową składnika przed jego usunięciem.

Aby utworzyć kopię zapasową składnika, można użyć opcji migracji indywidualnej lub masowej w celu wygenerowania wyeksportowanego rozwiązania. Następnie można je dodać do wybranego repozytorium plików lub do lokalizacji OneDrive.

Po zabezpieczeniu kopii zapasowej można zastosować opcję Usuń, aby zakończyć proces czyszczenia.

W wielu przypadkach są to przepływy testowe i aplikacje stworzone przez twórców w ramach ich osobistej nauki produktywności i eksperymentowania.

Podsumowanie

Power Platform to narzędzie zarówno dla deweloperów obywatelskich, jak i profesjonalnych. Domyślne środowisko powinno koncentrować się przede wszystkim na osobistej produktywności przy użyciu produktów Microsoft 365. Wszystkie inne aplikacje i rozwój przepływu powinny odbywać się w wyznaczonych środowiskach współdzielonych, indywidualnych lub deweloperskich. Zdecydowanym zaleceniem jest opracowanie strategii niezależnego środowiska w oparciu o DLP, która może pomóc twórcom w rozwijaniu ich aplikacji i przepływów we właściwym środowisku. Ogromną korzyścią jest również ustanowienie strategii komunikacji i zapewnienie użytkownikom samoobsługowych modeli poznawania strategii, wdrażania rozwiązań i najlepszych praktyk w zakresie tworzenia aplikacji i przepływów. Dobrym dodatkiem jest umieszczenie na stronie komunikacyjnej kilku historii sukcesu. Historie sukcesu publikowane wewnętrznie pomagają twórcom łączyć się z pomysłami i otwierają ich na możliwości, które można osiągnąć za pomoc Power Platform.

Silna strategia zarządzania jest niezbędna podczas migracji lub przenoszenia określonych obiektów. Dostępne są różne strategie migracji obiektów, w tym migracja indywidualna i masowa. Wybór najlepszej opcji zależy od zasad naszej organizacji. Rozwiązania są najbardziej zalecanym sposobem organizacji składników aplikacji i ułatwienia migracji.