Podstawowe informacje o ALM, dzięki Microsoft Power Platform
W tym artykule opisano składniki, narzędzia i procesy potrzebne do zaimplementowania procesu zarządzania cyklem życia aplikacji (ALM).
Środowiska
Środowiska to przestrzeń do przechowywania i udostępniania danych biznesowych, aplikacji i procesów biznesowych organizacji oraz zarządzania nimi. Pełni ono również rolę pojemnika oddzielającego aplikacje, które mogą mieć różne role, wymagania dotyczące zabezpieczeń lub odbiorców docelowych. Każde środowisko może mieć tylko jedną bazę danych Microsoft Dataverse. Więcej informacji: Omówienie środowisk
Ważne
Podczas tworzenia środowiska można zainstalować aplikacje Dynamics 365, takie jak Dynamics 365 Sales i Dynamics 365 Marketing. Ważne jest, aby na tym etapie określić, czy te aplikacje są wymagane czy nie, ponieważ nie można ich odinstalować ani zainstalować później. Jeśli nie używasz tych aplikacji podczas kompilowania i nie będziesz ich używać w przyszłości, zaleca się, aby nie instalować ich w środowiskach. Ułatwi to uniknięcie komplikacji zależnych podczas dystrybuowania rozwiązań między środowiskami.
Typy środowisk używanych w programie ALM
Z poziomu centrum administracyjnego usługi Power Platform, można tworzyć następujące środowiska Power Platform:
Piaskownica Środowisko piaskownicy jest jakimkolwiek środowiskiem, które nie jest środowiskiem produkcyjnym programu Dataverse. Ponieważ jest ono odizolowane od produkcji, środowisko piaskownicy jest miejscem do bezpiecznego projektowania i testowania zmian w aplikacji. Środowiska piaskownicy zawierają funkcje, które byłyby szkodliwe w środowisku produkcyjnym, takie jak operacje resetowania, usuwania i kopiowania. Więcej informacji: Zarządzanie środowiskami piaskownicy
Produkcja Środowiska, w którym aplikacje i inne programy są wprowadzane do użytku w celu ich zamierzonego zastosowania.
Developer (formalnie zwana Wspólnotą). Plan dla programistów Power Apps daje Ci dostęp do funkcjonalności premium Power Apps, Dataverse, oraz Power Automate do użytku indywidualnego. Ten plan jest przeznaczony głównie do budowania i testowania z Power Apps, Power Automate i Microsoft Dataverse lub do celów edukacyjnych. Środowisko dewelopera jest środowiskiem pojedynczego użytkownika i nie może służyć do uruchamiania lub udostępniania aplikacji produkcyjnych.
Domyślnie Automatycznie jest tworzone pojedyncze środowisko domyślne dla każdego dzierżawcy i udostępniane wszystkim użytkownikom tego dzierżawcy. Dzierżawca identyfikuje klienta, który może mieć skojarzoną co najmniej jedną subskrypcję i usługę firmy Microsoft. Nowo zarejestrowany użytkownik w usłudze Power Apps zostaje automatycznie dodany do roli twórcy środowiska domyślnego. Domyślne środowisko jest tworzone w najbliższym regionie domyślnemu regionowi usługi Microsoft Entra i ma nazwę „{Nazwa dzierżawcy Microsoft Entra} (domyślna)”
Twórz i używaj odpowiedniego środowiska do określonego celu, takiego jak programowanie, testowanie lub produkcja.
Więcej informacji na temat środowisk: Zobacz Omówienie środowisk.
Kto powinien mieć dostęp?
Dzięki Microsoft Dataverse możesz określać i zarządzać ustawieniami zabezpieczeń zasobów i danych. Usługa Microsoft Power Platform zapewnia role administratorów na poziomie środowiska do wykonywania zadań. Dataverse zawiera role zabezpieczeń, które definiują poziom dostępu do aplikacji, składników aplikacji i zasobów przyrzielanych aplikacjom i użytkownikom w ramach Dataverse.
| Przeznaczenie środowiska | Role z dostępem | Komentarze |
|---|---|---|
| Projektowanie | Twórcy aplikacji i deweloperzy. | Użytkownicy aplikacji nie powinni mieć dostępu. Aby tworzenie zasobów było konieczne, deweloperzy muszą mieć przypisaną co najmniej rolę zabezpieczeń twórca środowiska. |
| Przetestuj | Administratorzy i osoby, które przeprowadzają testy. | Twórcy aplikacji, deweloperzy i użytkownicy aplikacji produkcyjnych nie powinni mieć dostępu. Użytkownicy przeprowadzający testy powinni mieć tylko tyle uprawnień, aby przeprowadzić testowanie. |
| Wersja produkcyjna | Wszyscy administratorzy i użytkownicy aplikacji. Użytkownicy powinni mieć tylko wystarczający dostęp do wykonywania swoich zadań w ramach używanych przez nich aplikacji. | Twórcy lub projektanci aplikacji nie powinni mieć dostępu oraz nie powinni posiadać uprawnień na poziomie użytkownika. |
| Wartość domyślna | Domyślnie każdy użytkownik w dzierżawie może tworzyć i edytować aplikacje w środowisku domyśllnym Dataverse, w którym znajduje się baza danych programu. | Stanowczo zaleca się utworzenie środowisk dla określonego celu i przyznawanie odpowiednich ról i uprawnień tylko tym osobom, które ich potrzebują. |
Więcej informacji:
- Omówienie środowisk
- Kontrolowanie dostępu użytkowników do środowisk: grupy zabezpieczeń i licencje
- Tworzenie użytkowników i przypisywanie ról zabezpieczeń
- Tworzenie środowisk
Rozwiązania
Rozwiązania są używane do transportu aplikacji i składników z jednego środowiska do innego lub do zastosowania zestawu dostosowań do istniejących aplikacji.
Rozwiązania mają następujące funkcje:
Zawierają metadane i niektóre encje z danymi konfiguracji. Rozwiązania nie zawierają żadnych danych biznesowych.
Mogą zawierać wiele różnych składników Microsoft Power Platform, takich jak aplikacje oparte na modelowaniu, aplikacje kanwowe, mapy witryny, przepływy, encje, formularze, niestandardowe łączniki, zasoby sieci Web, zestawy opcji, wykresy i pola. Należy zauważyć, że nie wszystkie obiekty są uwzględnione w rozwiązaniu. Na przykład, tabele systemowe Użytkownik aplikacji, Niestandardowe API i Ustawienia organizacji nie mogą być dodane do rozwiązania.
Pakiety są umieszczane w postaci jednostek, które mają być wyeksportowane i zaimportowane do innych środowisk, lub dekonstruowane i przenoszone do kontroli źródła jako kod źródłowy dla zasobów. Rozwiązania służą także do stosowania zmian w istniejących rozwiązaniach.
Rozwiązania zarządzane są używane do wdrażania w ramach dowolnego środowiska, które nie jest środowiskiem programistycznym tego rozwiązania. Dotyczy to zarówno testowania, jak i testowania akceptacji użytkowników (UAT), testowania integracji systemu (SIT) oraz środowisk produkcji. Rozwiązania zarządzane można obsłużyć (uaktualnianie, poprawianie i usuwanie) niezależnie od innych rozwiązań zarządzanych w środowisku. Zaleca się, aby rozwiązania zarządzane zostały wygenerowane przez serwer kompilacji i traktowane jako artefakty kompilacji, celem uzyskania najlepszego ALM.
Aktualizacje do rozwiązań zarządzanych zostaną wdrożone na poprzedniej wersji rozwiązania zarządzanego. Nie powoduje to utworzenia dodatkowej warstwy rozwiązania. Nie można usuwać składników za pomocą aktualizacji.
Poprawka zawiera tylko zmiany dotyczące rozwiązania zarządzanego nadrzędnie. Łatek należy używać tylko do wykonywania niewielkich aktualizacji (np. poprawek) i musisz dopuszczać możliwość ich dezinstalacji. W przypadku zaimportowania poprawek są one nakładane na rozwiązanie nadrzędne. Nie można usuwać składników za pomocą łatki.
Uaktualnianie rozwiązania instaluje nową warstwę rozwiązania bezpośrednio nad warstwą podstawową i wszelkimi istniejącymi łatkami.
Zastosowanie uaktualnień rozwiązania polega na usunięciu wszystkich istniejących poprawek i warstwy bazowej.
Uaktualnienia rozwiązania usuną istniejące składniki, które nie są już uwzględnione w uaktualnionej wersji.
Więcej informacji: Koncepcje rozwiązań
Kontrola źródła
Kontrola źródła, znana także jako Kontrola wersji, jest systemem, który w sposób trwały lub bezpieczny zawiera zasoby programistyczne i śledzi zmiany wprowadzone w tych elementach. Śledzenie zmian ma znaczenie szczególnie wtedy, gdy wielu twórców aplikacji i deweloperów pracuje nad tym samym zestawem plików. System kontroli źródła umożliwia również wycofanie zmian i przywrócenie usuniętych plików.
System kontroli źródła pomaga organizacjom osiągnąć zdrowe ALM, ponieważ środki trwałe przechowywane w systemie kontroli źródła są "pojedynczym źródłem prawdy" — lub innymi słowy, jedynym punktem dostępu i jedynym źródłem modyfikacji rozwiązań.
Strategia rozgałęziania i łączenia
Niemal każdy system kontroli źródła korzysta z jakiejś formy obsługi rozgałęziania i scalania. Rozgałęzianie polega na tym, że użytkownik nie odchodzi od głównej linii programowania i pracuje bez jej zmieniania. Proces scalania polega na połączeniu jednej odnogi z drugą, na przykład odgałęzienia projektowania z główną gałęzią wiersza. Niektóre typowe strategie rozgałęzień są oparte na pniach, rozgałęzieniach przy nowych wersjach aplikacji czy odgałęzieniach funkcji. Więcej informacji: zatwierdzanie strategii rozgałęziania git
Proces kontroli źródła przy użyciu rozwiązania
Podczas pracy z rozwiązaniami w systemie kontroli źródła można używać dwóch podstawowych podejść:
- Eksportować rozwiązanie niezarządzane i rozpakować je w systemie kontroli źródła. Proces kompilacji powoduje zaimportowanie spakowanego rozwiązania jako niezarządzanego do tymczasowego środowiska budowania (środowiska piaskownicy). Następnie należy wyeksportować rozwiązanie jako zarządzane i zapisać jako skonstruowany artefakt w systemie kontroli źródła.
- Eksport rozwiązania jako niezarządzanego oraz zarządzanego i umieszczenie obydwu wersji w systemie kontroli źródła. Mimo że ta metoda nie wymaga środowiska kompilacji, wymaga ona zachowywania dwóch kopii wszystkich składników (jednej kopii wszystkich niezarządzanych składników w rozwiązaniu niezarządzanym oraz jednej kopii wszystkich składników zarządzanych w rozwiązaniu zarządzanym).
Więcej informacji: Tworzenie zadań w narzędziu
Automatyzacja
Automatyzacja to kluczowa część cyklu życia aplikacji, która poprawia wydajność, niezawodność, jakość i wydajność samego ALM. Narzędzia i zadania automatyzujące służą do sprawdzania poprawności, eksportowania, pakowania, rozpakowywania i eksportowania rozwiązań programu, a także tworzenia i resetowania środowiska piaskownicy.
Więcej informacji: Co to są narzędzia kompilacji Microsoft Power Platform Build Tools?
Wspólny dewelopment za pomocą współużytkowanej kontroli źródła
Należy uważać, w jaki sposób dział zespołu projektowego będzie współpracować przy konstruowaniu projektu. Rozdzielenie grup i sprzyjanie atmosferze wymiany poglądów i opinii sprawi że Twój zespół będzie tworzył lepsze oprogramowanie. Niektóre narzędzia i przepływy pracy — takie jak programy dostępne w narzędziu Git, GitHub i Azure DevOps — zostały zaprojektowane w taki sposób, aby usprawnić komunikację i jakość oprogramowania. Warto pamiętać, że praca z konfiguracją w systemie rozwiązań może stworzyć wyzwania dla zespołu. Organizacje muszą koordynowa pracę różnych programistów, aby uniknąć konfliktów scalania w najszerszym możliwym zakresie, ponieważ w systemach kontroli źródła istneiją ograniczenia dot. scalania. Zaleca się, aby uniknąć sytuacji, w których wiele osób wprowadza zmiany w złożonych składnikach — takich jak formularze, przepływy i aplikacje kanwy — w tym samym czasie.
Więcej informacji: Scenariusz 5: wsparcie wspólnego dewelopmentu
Obsługa ciągłej integracji i ciągłego wdrażania
Można użyć dowolnego systemu kontroli źródła i zbudować potok, który zaczyna się od ciągłej integracji i ciągłego wdrażania (CI/CD). Niniejszy przewodnik koncentruje się natomiast na GitHub i Azure DevOps. GitHub jest platformą programistyczną używaną przez miliony deweloperów. Program Azure DevOps oferuje deweloperom możliwość obsługi zespołów w celu planowania pracy, współpracy w zakresie projektowania kodu oraz budowania i wdrażania aplikacji.
Aby rozpocząć, musisz:
Posiadać konto GitHub – to tam utworzone zostanie repozytorium. Jeśli nie masz konta, możesz je utworzyć teraz za darmo.
Organizacja: Azure DevOps. Jeśli nie masz konta, możesz je utworzyć teraz za darmo.
Więcej informacji: Tworzenie pierwszego potoku
Licencjonowanie
Aby tworzyć lub edytować aplikacje i przepływy za pomocą programu Power Apps i Power Automate, użytkownicy muszą dysponować licencją na użytkownika Power Apps lub Power Automate lub odpowiednią licencją aplikacji Dynamics 365. Aby uzyskać więcej informacji, zapoznaj się z dokumentem Omówienie licencji dla Microsoft Power Platform. Zalecamy też skontaktowanie się z przedstawicielem konta Microsoft w celu omówienia potrzeb licencyjnych.
Kwestie dot. ALM wymagające rozważenia
Jeśli wziąć pod uwagę ALM jako integralną cześć tworzenia aplikacji Microsoft Power Platform, może to radykalnie poprawić szybkość, niezawodność i sposób obsługi aplikacji. Zapewnia również, że wielu deweloperów, zarówno tradycyjnych, którzy tworzą kod programu, jak i programistów spoza działu IT, może wspólnie tworzyć aplikacje.
Zapoznaj się z następującymi artykułami, w których omówiono kilka zagadnień, które należy uwzględnić na początku dowolnego projektu tworzenia aplikacji: