Organizowanie rozwiązań

Zanim utworzysz rozwiązania, pośmiń trochę czasu, aby zaplanować strategię środowiska i strategię rozwiązania. Rozważ następujące aspekty:

Aspekt	Kwestie wymagające rozważenia
Zakres aplikacji	Czy implementacja obejmuje wiele aplikacji, takich jak Sales, Customer Service, Field Service, Finance itp.?
Częstotliwość wydań	Jak często planujesz wdrożyć aktualizacje w środowisku produkcyjnym? Czy metodologia dostarczania opiera się na praktykach zwinnych, takich jak cykle sprintu?
Wsparcie produkcji	Jak radzić sobie z pilnymi poprawkami w środowisku produkcyjnym, nie wprowadzając przedwcześnie nowych funkcji?
Architektura rozwiązania	Ile rozwiązań, którymi zarządzasz? Czy te rozwiązania współdzielą składniki lub zależą od siebie?
Planowanie środowiska	Ile środowisk usługi Microsoft Dataverse jest potrzebnych do obsługi cyklu projektowania? Czy potrzebujesz oddzielnych środowisk do tworzenia, testowania i produkcji? Czy deweloperzy pracują wspólnie w środowisku udostępnionym, czy wymagają niezależnej pracy w izolowanych środowiskach?

W poniższych sekcjach opisano trzy strategie uporządkowane od najprostszych do najbardziej złożonych i podkreśla ich zalety i wady.

Strategia pojedynczego rozwiązania

Wszystkie dostosowania są pogrupowane w jedno niezarządzane rozwiązanie podczas opracowywania, które jest później eksportowane jako pojedyncze rozwiązanie zarządzane do wdrożenia.

Zalecane w przypadku:

• Implementacje na małą średnią skalę
• Scenariusze, w których przyszłe modularyzacja jest mało prawdopodobna

Korzyść	Niekorzystny
Uproszczona konfiguracja środowiska i zarządzanie nim.	Wymaga większego nakładu pracy w celu skalowania lub modularyzacji później, jeśli to konieczne.
Uproszczone wdrożenie. W przypadku tylko jednego rozwiązania do zarządzania eksportowanie i importowanie w środowiskach jest proste i mniej podatne na błędy.	Pojedyncze rozwiązanie zawierające dużą liczbę dostosowań może spowodować wydłużenie czasu wdrażania. Aby zmniejszyć rozmiar rozwiązania, użyj segmentacji tabeli. Aby skrócić czas importowania, przejdź do zaleceń dotyczących wydajności.
Łatwiejsze do lokalizowania, inspekcji i zarządzania zmianami.	Gdy wielu deweloperów pracuje w tym samym środowisku deweloperskim, ryzykują nadpisywanie zmian dokonanych przez innych. To ryzyko można zmniejszyć, implementując przechowywanie wersji kodu źródłowego, przyjmując strategię rozgałęziania i używając dedykowanego środowiska deweloperskiego dla każdej gałęzi. Strategia przechowywania wersji kodu źródłowego i rozgałęziania zapewnia śledzenie zmian, obsługę współpracy i mechanizmy rozwiązywania konfliktów. Więcej informacji: Przyjęcie strategii rozgałęziania Git.

Uwaga

Ostatnie ulepszenia platformy Microsoft Power Platform zmniejszyły czas importowania dla rozwiązań zarządzanych, w tym tych, które korzystają z opcji uaktualnienia. Te optymalizacje obejmują lepszą obsługę zależności składników i mniejsze obciążenie dla niezmienionych składników. Aby dowiedzieć się, jak korzystać z tych ulepszeń, przejdź do zaleceń dotyczących wydajności.

Wiele rozwiązań w tym samym środowisku projektowym

Wiele rozwiązań niezarządzanych jest utrzymywanych w jednym środowisku projektowym, z których każdy jest zwykle przeznaczony dla niepowiązanych funkcji lub modułów.

Zalecane w przypadku:

• Implementacje na małą średnią skalę z odrębnymi i niezależnymi obszarami funkcjonalnymi, które nie współużytkują składników.

Korzyść	Wada
Uproszczona konfiguracja środowiska i zarządzanie nim.	Obsługa wielu niezarządzanych rozwiązań w tym samym środowisku programistycznym zwiększa prawdopodobieństwo konfliktów zależności. Na przykład może wystąpić sytuacja, w której nie można zaimportować rozwiązania A, ponieważ jest to zależne od rozwiązania B, podczas gdy nie można zaimportować rozwiązania B, ponieważ zależy od rozwiązania A.
Obszary funkcjonalne można wdrażać niezależnie od siebie.	Wielu deweloperów pracujących nad tym samym środowiskiem projektowym może nadpisywać zmiany dokonane przez innych. Praca w rozwiązaniu niezarządzanym nie zapewnia izolacji. Każda modyfikacja jest stosowana bezpośrednio w środowisku, niezależnie od tego, które rozwiązanie jest edytowane.

Uwaga

Jeśli masz wiele rozwiązań w tym samym środowisku projektowym, po zaimportowaniu rozwiązań zarządzanych do środowiska docelowego często tworzysz warstwy. Więcej informacji: Warstwy rozwiązań i zachowanie scalania

Ważne jest, aby:

• Nie dołączaj tego samego składnika niezarządzanego w więcej niż jednym rozwiązaniu.
• Masz tylko jedno rozwiązanie, które zawiera wszystkie tabele. Nie ma dwóch różnych rozwiązań, w których obie zawierają tabele. Dlatego, że często występuje relacja między tabelami, która tworzy zależność między rozwiązaniami i powoduje uaktualnianie rozwiązania lub usuwanie błędów w środowisku docelowym w późniejszym czasie.
• Użyj tylko jednego wydawcy rozwiązań. Wydawca rozwiązania jest właścicielem składników rozwiązania zarządzanego i nie można później zmienić jego skojarzenia. Jeśli na przykład tabela niestandardowa jest importowana jako zarządzana za pomocą rozwiązania A z programem Publisher X, nie można później przenieść tej tabeli do rozwiązania B z programem Publisher Y. Jedyną opcją jest usunięcie tabeli, uaktualnienie rozwiązania A w celu usunięcia tabeli z systemu docelowego, a następnie ponowne utworzenie tabeli w rozwiązaniu B za pomocą programu Publisher Y i zaimportowanie rozwiązania B. Ten proces powoduje utratę wszystkich danych przechowywanych w tabeli niestandardowej, chyba że zostały zmigrowane wcześniej.
• Unikaj tworzenia zależności między rozwiązaniami. Zależności wymuszają kolejność importowania i mogą powodować problemy. Jeśli na przykład masz jedno rozwiązanie dla tabel i drugie dla przepływów w chmurze, a przepływ opiera się na kolumnie niestandardowej, działa to w środowisku programistycznym, ponieważ kolumna istnieje. Jeśli jednak tylko rozwiązanie przepływu w chmurze zostanie zaimportowane do środowiska docelowego, proces importowania może nie rozpoznać zależności od kolumny niestandardowej. W rezultacie rozwiązanie przepływu instaluje się pomyślnie, ale sam przepływ nie działa. Więcej informacji: Przykłady zależności utworzonych przez wiele rozwiązań

Przykłady zależności utworzonych przez wiele rozwiązań

• Wstążki aplikacji. Gdy wiele rozwiązań modyfikuje wstążkę aplikacji lub mapę witryny tej samej aplikacji.
• Wtyczki lub przepływy w chmurze. Jeśli wtyczka lub przepływ jest wyzwalana w kolumnie niestandardowej lub aktualizuje tabelę niestandardową, obiekt zależy od tych tabel niestandardowych.
• Role zabezpieczeń. Gdy istnieją tabele niestandardowe, role zabezpieczeń zwykle zależą od tych tabel na potrzeby dostępu użytkowników.

Wiele rozwiązań z dedykowanymi środowiskami projektowymi

Ta strategia obejmuje opracowanie każdego niezarządzanego rozwiązania we własnym izolowanym środowisku deweloperskim Dataverse. Ta strategia jest często używana w architekturach modułowych, w których na przykład różne aplikacje , takie jak Sales, Customer Service lub Field Service, są tworzone i obsługiwane niezależnie. Podstawowe rozwiązanie zawierające typowe składniki (na przykład tabele kont i kontaktów) jest tworzone i wdrażane jako rozwiązanie zarządzane w każdym środowisku projektowym specyficznym dla aplikacji. Każda aplikacja ma własne rozwiązanie niezarządzane, warstwowe na podstawie podstawowego rozwiązania zarządzanego, dzięki czemu zespoły mogą rozszerzać funkcje bez zmiany podstawy podstawowej.

Zalecane w przypadku:

• Projekty w przedsiębiorstwie na dużą skalę.
• Zespoły z wieloma deweloperami lub partnerami
• Scenariusze wymagające ścisłego zarządzania i potoków ciągłej integracji/ciągłego wdrażania.

Korzyść	Wada
Łatwiejsze zwiększanie i rozwijanie systemu przez dodawanie lub aktualizowanie modułów bez wpływu na inne osoby.	Wyższe koszty związane z infrastrukturą i konserwacją.
Wiele zespołów może pracować równolegle nad różnymi modułami, nie kolidując wzajemnie ze swoimi zmianami.	Wymaga solidnej strategii dotyczącej środowiska i ładu zarządczego.
Łatwiejsze do zaimplementowania zautomatyzowanych testów i praktyk DevOps.	Bardziej złożone wdrożenie.
Mniejsze rozwiązania są szybsze do wdrożenia, szczególnie w pipeline'ach CI/CD, jeśli trzeba wdrożyć tylko określoną aplikację.
Usterki lub regresje są łatwiejsze do śledzenia, gdy zmiany są izolowane do określonych modułów.

Jak utworzyć warstwy rozwiązania

Uwaga

Przed utworzeniem rozwiązań w poniższych krokach należy użyć tego samego wydawcy dla wszystkich rozwiązań w środowiskach. Więcej informacji: Wydawca rozwiązania

1. W środowisku projektowym "base" masz podstawowe rozwiązanie ze wspólnymi tabelami niezarządzanymi i nie ma innych tabel. Następnie wyeksportuj to rozwiązanie jako zarządzane.
2. Skonfigurujesz drugie środowisko programistyczne dla warstwy rozszerzenia lub "aplikacji", która będzie później znajdować się na górze warstwy podstawowej.
3. Zaimportujesz zarządzaną warstwę podstawową do środowiska deweloperskiego warstwy aplikacji i utworzysz niezarządzane rozwiązanie dla warstwy aplikacji.
4. Teraz możesz rozszerzyć model danych, dodając dodatkowe tabele, kolumny, relacje tabel, wtyczki, przepływy itd., do konkretnego rozwiązania "aplikacji". Następnie eksportuje się rozwiązanie dla aplikacji jako zarządzane. Zwróć uwagę, że rozwiązanie aplikacji nadal zależy od rozwiązania warstwy podstawowej, ale zarządzanie wieloma rozwiązaniami w ten sposób jest lepszym podejściem. Rozważmy wspomniany wcześniej przykład przepływu, który opiera się na kolumnie niestandardowej. W większości przypadków kolumna niestandardowa i przepływ znajdują się w tym samym rozwiązaniu aplikacji. Ale nawet jeśli kolumna niestandardowa jest częścią rozwiązania podstawowego, najpierw musisz ukończyć i wdrożyć to rozwiązanie podstawowe jako zarządzane, w przeciwnym razie nie można nawet utworzyć przepływu wewnątrz rozwiązania aplikacji.
5. W środowisku produkcyjnym należy zaimportować zarządzaną warstwę podstawową, a następnie zaimportować zarządzaną warstwę aplikacji. Spowoduje to utworzenie dwóch warstw zarządzanych w środowisku z wyraźnymi zależnościami między rozwiązaniami zarządzanymi.
6. Powtórz ten wzorzec, aby mieć dowolną liczbę różnych rozwiązań, które możesz utrzymywać. Zaleca się jednak, aby zachować jak najmniejszą liczbę rozwiązań, aby można było zarządzać warstwami rozwiązań.

Powiązane artykuły

Używanie segmentacji tabeli
Scenariusz 5: Wspieranie programowania w zespole