Zarządzane a niezarządzane rozwiązania Power Platform: kompletny przewodnik

By Mirko Peters · 2026-10-21

Poznaj kluczowe różnice między zarządzanymi a niezarządzanymi rozwiązaniami Power Platform, zasady wdrażania oraz najlepsze praktyki ALM dla Twoich aplikacji.

Automatically translated with AI from the original post. Read the English original

Zrozumienie różnicy między zarządzanymi a niezarządzanymi rozwiązaniami Power Platform jest kluczowe, aby uniknąć katastrofalnych usunięć aplikacji i nieudanych wdrożeń. Ten przewodnik wyjaśnia, jak niezarządzane warstwy działają jako edytowalna przestrzeń robocza, a zarządzane rozwiązania służą jako zamrożone pakiety gotowe do wdrożenia w środowiskach deweloperskich, testowych i produkcyjnych.

Najważniejsze wnioski

• Niezarządzane rozwiązania to Twoja robocza kopia w środowiskach deweloperskich, w których aktywnie tworzysz, edytujesz i eksperymentujesz.
• Zarządzane rozwiązania to zamrożone, gotowe do wdrożenia kopie przeznaczone wyłącznie do środowisk testowych i produkcyjnych, aby zachować stabilność.
• Usunięcie niezarządzanego rozwiązania usuwa tylko kontener, a komponenty pozostają nienaruszone, natomiast odinstalowanie zarządzanego rozwiązania usuwa powiązane niestandardowe tabele i dane.
• Nie można zaimportować zarządzanego rozwiązania z powrotem do tego samego środowiska deweloperskiego, w którym utworzono jego niezarządzaną wersję nadrzędną.
• Traktowanie niezarządzanych rozwiązań jak kodu źródłowego, a zarządzanych jak artefaktów buildu, sprawia, że Twoje ALM w Power Platform jest zgodne ze standardowymi praktykami wytwarzania oprogramowania.

Podstawowe różnice między zarządzanymi a niezarządzanymi rozwiązaniami

Kiedy zaczynasz tworzyć aplikacje, przepływy i tabele w Microsoft Power Platform, łatwo potraktować środowiska jak wielkie cyfrowe brudnopisy. Klikasz, tworzysz niestandardowe encje i konfigurujesz przepływy w chmurze bezpośrednio w domyślnej lub współdzielonej przestrzeni roboczej. Jednak gdy projekt wykracza poza etap proof of concept, to swobodne podejście szybko prowadzi do kodu, którego nie da się utrzymać, oraz do przypadkowej utraty danych. Aby budować niezawodne aplikacje, musisz opanować podstawowy podział na rozwiązania niezarządzane i zarządzane.

W istocie rozwiązanie to po prostu kontener – jak specyfikacja przesyłki, która grupuje komponenty aplikacji, tak aby mogły bezpiecznie przenosić się między środowiskami. Wewnątrz tego kontenera istnieje jednak ścisły podział: niezarządzane kontra zarządzane. Zapamiętanie tego prostego hasła pomaga zrozumieć ich odrębne przeznaczenie: niezarządzane służy do edytowania tutaj, a zarządzane do wdrażania tam.

Rozwiązania niezarządzane: Twoja przestrzeń robocza deweloperska

Rozwiązanie niezarządzane to Twoja aktywna, edytowalna kopia robocza. Ilekroć projektujesz aplikację kanwy, piszesz reguły biznesowe lub modyfikujesz tabele Dataverse, pracujesz w niezarządzanym rozwiązaniu w swoim środowisku deweloperskim. Każda zmiana, zmiana koloru i modyfikacja schematu od razu trafia do bazowej aplikacji.

Co się dzieje, gdy usuniesz niezarządzane rozwiązanie?

Jedną z najważniejszych cech bezpieczeństwa rozwiązań niezarządzanych jest sposób, w jaki obsługują usuwanie. Jeśli usuniesz niezarządzane rozwiązanie ze swojego środowiska deweloperskiego, znika wyłącznie sam kontener. Rzeczywiste dostosowania, aplikacje i tabele, które zbudowałeś, nie znikają; zamiast tego po cichu trafiają do domyślnego rozwiązania. Chroni to przed przypadkowym totalnym zniszczeniem podczas developmentu, ale jeśli nie zachowasz ostrożności, może zaśmiecić domyślną przestrzeń roboczą.

Microsoft zaleca przechowywanie rozwiązań niezarządzanych bezpośrednio w systemach kontroli źródła, takich jak GitHub lub Azure DevOps. Traktując rozwiązanie niezarządzane jako główne repozytorium kodu źródłowego, zachowujesz pełny, historyczny ślad audytu każdej zmiany wprowadzonej przez zespół deweloperski.

Rozwiązania zarządzane: pakiet wdrożeniowy dla środowiska produkcyjnego

Rozwiązania zarządzane to ukończona, skompilowana i zamrożona kopia Twojej aplikacji. Nie edytujesz rozwiązania zarządzanego bezpośrednio. Zamiast tego eksportujesz rozwiązanie niezarządzane jako zarządzane i wdrażasz ten pakiet w kolejnych środowiskach, takich jak testy akceptacyjne użytkowników (UAT), testy integracji systemów (SIT), a ostatecznie produkcja.

Rzeczywistość usuwania rozwiązań zarządzanych, gdzie stawka jest wysoka

W przeciwieństwie do rozwiązań niezarządzanych, rozwiązania zarządzane są z założenia mocno zablokowane. Nie możesz bezpośrednio edytować komponentów w rozwiązaniu zarządzanym. Co ważniejsze, odinstalowanie rozwiązania zarządzanego powoduje dokładnie odwrotne zachowanie niż w przypadku rozwiązania niezarządzanego: ponieważ wszystko w pakiecie jest powiązane z tym konkretnym wdrożeniem, usunięcie rozwiązania usuwa wszystkie jego komponenty.

Co istotne, odinstalowanie obejmuje także dane przechowywane w niestandardowych tabelach, które były częścią rozwiązania, oraz dane w niestandardowych kolumnach dodanych do istniejących tabel. Po odinstalowaniu rozwiązania zarządzanego z środowiska powiązane dane są trwale utracone. Nie ma natywnej funkcji cofnięcia, dlatego zrozumienie architektury wdrożeń jest krytycznym obowiązkiem administratora.

Architektura środowisk i zasady testowania

Mechanika platformy Power Platform wymusza ścisłe granice środowisk w zależności od tego, jak obsługujesz te dwa typy rozwiązań. Na przykład nie możesz zaimportować rozwiązania zarządzanego z powrotem do środowiska deweloperskiego, w którym znajduje się rozwiązanie niezarządzane, z którego je zbudowano. Testowanie wdrożenia zarządzanego wymaga osobnego środowiska, dlatego najlepsze praktyki zalecają konfigurację dedykowanego, wielośrodowiskowego potoku już od pierwszego dnia.

Standardowa, zdrowa konfiguracja ALM (Application Lifecycle Management) składa się z co najmniej trzech odrębnych środowisk:

• Deweloperskie: tutaj twórcy budują i modyfikują rozwiązania niezarządzane.
• Testowe (UAT): tutaj importujesz rozwiązanie zarządzane, aby sprawdzić, czy zarówno proces wdrożenia, jak i działanie aplikacji są poprawne.
• Produkcyjne: tutaj prawdziwi użytkownicy codziennie korzystają ze stabilnego, zamrożonego rozwiązania zarządzanego.

Opanowanie strategii wdrożeń w Power Platform

Ścisłe rozdzielenie niezarządzanych obszarów deweloperskich od zarządzanych wdrożeń produkcyjnych przekształca Twoją strategię Power Platform z zbioru kruchych rozwiązań prowizorycznych w inżynierię oprogramowania klasy korporacyjnej. Respektując granice rozwiązań, chroniąc środowiska produkcyjne przed doraźnymi zmianami i utrzymując czyste nawyki w kontroli źródła, zapewniasz, że krytyczne dla biznesu aplikacje pozostaną stabilne i odporne w miarę ich skalowania.

Aby zgłębić mechanikę komponentów Power Platform, wydawców, prefiksów i warstw rozwiązań, koniecznie posłuchaj pełnego odcinka i zasubskrybuj podcast, aby na bieżąco śledzić spostrzeżenia dotyczące ekosystemu chmury Microsoft.