Strategia środowiskowa ALM
Aby śledzić reguły zarządzania cyklem życia aplikacji (ALM), należy dysponować osobnymi środowiskami do opracowania i wydawania aplikacji. Pomimo tego, że podstawowe ALM można wykonywać w oddzielnym środowisku projektowania i produkcyjnym, zaleca się jednak, aby utrzymywać co najmniej jedno środowisko testowe, które jest niezależne od środowiska projektowego i produkcyjnego. Jeśli istnieje osobne środowisko testowe, można przeprowadzić sprawdzanie kompleksowe od początku do końca, w którym znajdują się rozwiązania dotyczące wdrażania rozwiązań i testowania aplikacji. Niektóre organizacje mogą również potrzebować więcej środowisk do testowania akceptacji użytkowników (UAT), testowania integracji systemów (SIT) i szkoleń.
Osobne środowiska programistyczne mogą pomóc w wyodrębnieniu zmian wprowadzonych w ramach jednego procesu związanego z pracą przed jego zakończeniem. Oddzielne środowiska programistyczne mogą również pomóc w zmniejszeniu sytuacji, gdy dana osoba negatywnie wpływa na inną przy wprowadzaniu zmian.
Każda organizacja jest inna, więc należy uważnie sprawdzać, jakie są wymagania w zakresie środowiska w organizacji użytkownika.
Środowiska projektowe
Należy odpowiedzieć na pytania, takie jak:
- Ile jest potrzebnych środowisk deweloperskich?
- Więcej informacji: Omówienie środowisk
- Jak mogę automatycznie wdrażać środowiska z poziomu kodu źródłowego?
- Więcej informacji: Narzędzia Microsoft Power Platform Build Tools dla Azure DevOps
- Jakie są zależności w środowiskach?
- Więcej informacji: Wiele warstw rozwiązań i zależności
Inne środowiska
Należy również odpowiedzieć na pytanie "Jakie typy środowisk innych niż deweloperskie są potrzebne?".
Na przykład oprócz środowiska produkcyjnego może być potrzebny osobne środowisko testowe, UAT, SIT i pre-produkcyjne. Należy zauważyć, że każde zdrowe działanie w ramach ALM powinno obejmować środowisko testowego przed wdrożeniem czegokolwiek do środowiska produkcyjnego. Dzięki temu można sprawdzić, czy aplikacja została przetestowana, ale także upewnić się, że samo wdrożenie będzie możliwe.
Więcej informacji: Ustanawianie strategii środowiskowej w Microsoft Power Platform
Problemy związane z różnymi lokalizacjami geograficznymi
Środowiska Power Platform są zgodne z określonym harmonogramem aktualizacji usług, ponieważ środowiska są aktualizowane na całym świecie. Łącznie jest sześć stacji, które są przede wszystkim określone przez położenie geograficzne. Aktualizacje usług są stosowane kolejno dla każdej stacji. W związku z tym aktualizacje usług w stacji 2 są instalowane przed zainstalowaniem ich w stacji 3. Dlatego często zdarza się, że środowiska, które znajdują się w różnych stacjach, mają w określonym czasie różne wersje. Aby uzyskać więcej informacji na temat harmonogramu aktualizacji usług środowiska, przejdź do strony Udostępnione wersje Microsoft Dataverse
Import rozwiązania i wersja środowiska
W przypadku posiadania kilku środowisk w różnych regionach, ważne jest, aby podczas importowania rozwiązania zrozumieć następujące kwestie:
- Można zaimportować rozwiązanie do środowiska, które jest nowszą wersją niż środowisko, z którego rozwiązanie zostało wyeksportowane.
- Nie można w sposób wiarygodny zaimportować rozwiązania do środowiska, które jest starszą wersją niż środowisko, z którego rozwiązanie zostało wyeksportowane. Wynika to z faktu, że w starszym środowisku może brakować składników lub wymaganych funkcji.
Przykład pomyślnego dostosowania środowisk do stacji aktualizacji usług
Wyobraź sobie, że masz środowiska produkcyjne w Kanadzie i Stanach Zjednoczonych. W takim przypadku środowiska programistyczne powinny znajdować się w Ameryce Północnej (stacja 5), a nie w Kanadzie (stacja 2). Środowiska programistyczne będą zawsze w tej samej lub wcześniejszej wersji niż środowiska produkcyjne, co ograniczy konflikty wersji importu rozwiązania.
