Wprowadzenie do bezpiecznych rozwiązań dotyczących uaktualniania

W tym artykule przedstawiono praktyki bezpiecznego uaktualniania (SUP) programu Azure Operator Service Manager (AOSM). Zestaw funkcji umożliwia aktualizacje złożonej funkcji sieciowej kontenera (CNF) hostowanej na platformie Azure Operator Nexus. Te uaktualnienia zwykle obsługują metody i wymagania partnera w ramach uaktualniania oprogramowania usługi (ISSU). Chociaż w tym artykule przedstawiono podstawowe pojęcia, poszukaj innych artykułów, które rozwijają zaawansowane funkcje i możliwości SUP.

Wprowadzenie do bezpiecznych uaktualnień

Dana usługa sieciowa obsługiwana przez rozwiązanie AOSM, składająca się z jednego do wielu plików CNFs, obejmuje składniki, które w czasie wymagają zmian oprogramowania i/lub konfiguracji. Aby wprowadzić te zmiany na poziomie składnika, należy uruchomić jedną do wielu operacji Helm, aktualizując każdą aplikację funkcji sieciowej (nfApp) w określonej kolejności i w sposób, który minimalnie wpływa na usługę sieciową. Rozwiązania dotyczące bezpiecznego uaktualniania systemu AOSM stosują następujące funkcje wysokiego poziomu w celu obsługi wymagań dotyczących procesu uaktualniania i przepływu pracy:

Obsługa snS Reput — wykonaj operację uaktualniania narzędzia Helm we wszystkich aplikacjach nfApps w wersji projektowania funkcji sieciowej (NFDV).
Platforma Nexus — wsparcie dla operacji reputacji SNS na docelowych platformach Nexus.
Limity czasu operacji — możliwość ustawiania limitów czasu operacyjnego dla każdej operacji nfApp.
Operacje synchroniczne — możliwość uruchamiania jednej szeregowej operacji nfApp naraz.
Zarządzanie kolejnością uaktualnienia - określ inną sekwencję nfApp dla instalacji i aktualizacji.
Pauza w przypadku niepowodzenia — domyślne zachowanie to pauza po niepowodzeniu operacji nfApp.
Wycofywanie po awarii — opcjonalne zachowanie, wycofanie ukończonych nfApps przed niepowodzeniem nfApp.
Weryfikacja testu pojedynczego wykresu — przeprowadzanie operacji testowej za pomocą komendy helm po utworzeniu lub aktualizacji.
Pomiń nfApp w przypadku braku zmian — pomiń przetwarzanie aplikacji nfApps, gdzie nie ma żadnych zmian.
Wstępne ładowanie obrazów — możliwość wstępnego ładowania obrazów do repozytorium brzegowego.

Bezpieczne podejście do uaktualniania

Aby zaktualizować istniejącą usługę sieciową systemu AOSM (SNS), operator wykonuje zapytanie reputujące względem wdrożonego zasobu SNS. Jeśli SNS zawiera CNF z wieloma aplikacjami nfApps, żądanie jest rozpowszechniane we wszystkich aplikacjach nfApps zdefiniowanych w wersji definicji funkcji sieciowej (NFDV). Domyślnie w kolejności, w jakiej są wyświetlane, lub opcjonalnie w kolejności zdefiniowanej przez updateDependsOn parametr.

Dla każdej nfApp żądanie reputacji obsługuje różne zmiany, w tym zwiększenie wersji wykresu Helm, dodawanie lub usuwanie wartości Helm oraz dodawanie lub usuwanie dowolnych nfApp. Chociaż limity czasu można ustawić dla nfApp na podstawie znanych dozwolonych czasów działania, nfApps można przetwarzać tylko w kolejności szeregowej, jeden po drugim. Aktualizacja reputacji implementuje następującą logikę przetwarzania:

Aplikacje nfApps są przetwarzane zgodnie z określoną updateDependsOn kolejnością lub w kolejności, w jakiej się pojawiają.
Pominięto aplikacje nfApps z parametrem applicationEnabled ustawionym na wyłączony.
nfApps z parametrem skipUpgrade ustawionym na enabled są pomijane, jeśli nie wykryto żadnych zmian.
nfApps, które są wspólne dla starego i nowego NFDV, są uaktualniane przy pomocy helm upgrade.
nfApps, które znajdują się tylko w nowym systemie plików NFDV, są instalowane przy użyciu polecenia helm install.
Wdrożone nfApps, które nie są przywoływane przez nowy NFDV, zostaną usunięte przy użyciu helm delete.

Aby zapewnić wyniki testów, testowanie aplikacji nfApp jest obsługiwane przy użyciu metod helm: testy mogą być wyzwalane przez pre- lub post-hooki helm, albo przy użyciu autonomicznego hooka testowego helm. W przypadku awarii haków przed lub po atomic parametr jest uwzględniany. W przypadku wartości niepodzielnej/true, wykres, który zakończył się niepowodzeniem, jest cofany. W przypadku wartości atomic/false nie jest wykonywane wycofywanie. W przypadku niezależnej awarii haka testowego narzędzia Helm zasada rollbackOnTestFailure jest respektowana, postępując zgodnie z podobną logiką jak atomowa. Aby uzyskać więcej informacji na temat autonomicznego testowania helm, zobacz następujący artykuł: Uruchamianie testów po zainstalowaniu lub uaktualnieniu

Gdy wystąpi błąd operacji nfApp i po obsłużeniu nieudanej aplikacji nfApp za pomocą parametrów atomic lub rollbackOnTestFailure, operator może kontrolować sposób postępowania z nfApps, które zostały zmienione przed awarią nfApp. Dzięki funkcji wstrzymywania po awarii operator może wymusić, aby AOSM zatrzymał się po rozwiązaniu problemów z nieudanym nfApp, zachowując środowisko wersji mieszanej. W przypadku niepowodzenia operator może wymusić na usłudze AOSM wycofanie dowolnej wcześniejszej aplikacji nfApp, co przywróci oryginalną migawkę środowiska. Aby uzyskać więcej informacji na temat kontrolowania zachowania niepowodzenia uaktualniania, zobacz następujący artykuł: Kontrolowanie zachowania niepowodzenia uaktualniania

Zagadnienia dotyczące uaktualnień w trakcie użytkowania

Program Azure Operator Service Manager ogólnie obsługuje uaktualnienia usług, czyli metodę uaktualniania, która rozwija wersję wdrożenia bez przerywania działania usługi. Niektóre zagadnienia dotyczące właściciela funkcji sieci są niezbędne do zapewnienia prawidłowego zachowania usługi AOSM podczas operacji ISSU.

Jeśli usługa AOSM wykonuje uaktualnienie względem uporządkowanego zestawu wielu aplikacji nfApps, usługa AOSM najpierw uaktualnia lub tworzy wszystkie nowe aplikacje nfApps, a następnie usuwa wszystkie stare aplikacje nfApps. Takie podejście zapewnia, że usługa nie będzie narażona na wpływ, dopóki wszystkie nowe aplikacje nfApps nie będą gotowe, ale wymaga dodatkowej pojemności platformy do przejściowego hostowania zarówno starych, jak i nowych aplikacji nfApps.
Jeśli usługa AOSM uaktualnia aplikację nfApp z wieloma replikami, usługa AOSM honoruje ustawienia profilu wdrożenia dla opcji stopniowego lub ponownego tworzenia. Jeśli stosowane jest rolowanie, udostępniaj wartości maxUnavailable i maxSurge jako parametry CGS, które następnie można ustawić za pomocą operatora CGV podczas działania programu.

Ostatecznie możliwość uaktualnienia danej usługi bez przerwy jest funkcją samej usługi. Skontaktuj się z wydawcą usługi, aby zrozumieć możliwości uaktualniania w usłudze i upewnić się, że są one dostosowane do odpowiednich opcji behawioralnych usługi AOSM.

Wymagania wstępne dotyczące bezpiecznego uaktualniania

Podczas planowania uaktualnienia przy użyciu programu AOSM należy spełnić następujące wymagania przed wykonaniem uaktualnienia, aby zoptymalizować czas spędzony na próbie i zapewnić powodzenie uaktualnienia.

Dołączanie zaktualizowanych artefaktów przy użyciu przepływów pracy wydawcy i/lub projektanta.
- W większości przypadków użyj istniejącego wydawcy do hostowania nowych artefaktów wersji.
  - Użycie istniejącego wydawcy wspiera helm upgrade aktualizację SNS na inną wersję.
  - Użycie nowego wydawcy wymaga helm delete na bieżącym SNS, a następnie helm install dla nowej wersji SNS.
- Repozytorium artefaktów, grupa projektowania usług sieciowych (NSDG) i grupa projektowania funkcji sieciowych (NFDG) są niezmienne.
  - Zmiana jednego z tych zasobów wymaga wdrożenia nowego protokołu SNS.
- Do przechowywania nowych wykresów i obrazów potrzebny jest nowy manifest artefaktu.
  - Zobacz dokumentację wdrażania aby uzyskać szczegółowe informacje na temat przekazywania nowych wykresów i obrazów.
- Wymagana jest nowa wersja NFDV i opcjonalnie wersja projektu usługi sieciowej (NSDV).
  - Zmiany NFDV mogą być złożone. W tym artykule omówiono tylko podstawowe zmiany.
  - Nowy NSDV jest wymagany tylko w przypadku wprowadzenia nowej wersji schematu grupy konfiguracji (CGS).
- W razie potrzeby nowe CGS.
  - Wymagane, jeśli uaktualnienie wprowadza nowe uwidocznione parametry konfiguracji.

Uwaga

NSDVs i NFDVs z różnymi wersjami głównymi mogą być obsługiwane w tym samym NSDG i NFDG.

Utwórz zaktualizowane artefakty w ramach przepływu pracy operatora.
- W razie potrzeby utwórz nowe wartości grupy konfiguracji (CGV) na podstawie nowych CGS.
- Ponownie wykorzystaj i skonfiguruj ładunek, potwierdzając istniejące obiekty usługi sieciowej lokacji i obiektów lokacyjnych.
Zaktualizuj szablony, aby upewnić się, że parametry aktualizacji są ustawione na podstawie zaufania do procesu aktualizacji i oczekiwanego zachowania w przypadku niepowodzenia.
- Ustawienia używane w środowisku produkcyjnym mogą pomijać szczegóły błędów, podczas gdy ustawienia używane do debugowania lub testowania mogą zdecydować się na ujawnienie tych szczegółów.

Procedura bezpiecznego uaktualniania

Postępuj zgodnie z poniższym procesem, aby wyzwolić uaktualnienie za pomocą programu AOSM.

Tworzenie nowego zasobu NFDV
- W przypadku nowych wersji NFDV musi mieć prawidłowy format SemVer. Nowa wersja może być uaktualnieniem, większą wartością w porównaniu z wdrożoną wersją lub obniżeniem, niższą wartością w porównaniu z wdrożoną wersją. Nowa wersja może różnić się pod względem wartości major, minor lub patch.
Aktualizowanie nowych parametrów NFDV
- Wersje wykresu programu Helm można zaktualizować lub zaktualizować lub sparametryzować w razie potrzeby. Nowe aplikacje nfApps można również dodać tam, gdzie nie istniały w dotychczasowej wersji wdrożenia.
Aktualizowanie NFDV dla żądanej kolejności nfApp
- UpdateDependsOn jest parametrem NFDV używanym do określania kolejności nfApps podczas operacji aktualizacji. Jeśli updateDependsOn nie zostanie podane, używane jest szeregowe uporządkowanie aplikacji CNF, jak pojawia się w NFDV.
Zaktualizuj szablon ARM pod kątem żądanego zachowania podczas uaktualniania
- Upewnij się, że ustawiono aplikację CNF timeout, parametr atomic oraz parametr rollbackOnTestFailure. Zmiana tych parametrów może być przydatna w miarę upływu czasu w miarę zwiększenia pewności podczas uaktualniania.
Problem z reputacją SNS
- Po zakończeniu wdrożenia jest przesyłana operacja reputacji. W zależności od liczby, rozmiaru i złożoności aplikacji nfApps, operacja powtórnego przetwarzania może zająć trochę czasu (wiele godzin).
Sprawdź wyniki reputacji
- Jeśli raport zgłasza pomyślny wynik, uaktualnienie jest zakończone, a użytkownik powinien zweryfikować stan i dostępność usługi. Jeśli raport zgłasza błąd, wykonaj kroki opisane w sekcji odzyskiwanie błędu uaktualniania, aby kontynuować.

Procedura ponawiania prób bezpiecznego uaktualniania

W przypadkach, gdy aktualizacja reputacji kończy się niepowodzeniem, można wykonać następujący proces, aby ponowić operację.

Zdiagnozuj awarię aplikacji nfApp
- Rozwiąż główną przyczynę niepowodzenia aplikacji nfApp, analizując dzienniki i inne informacje debugowania.
Ręczne pomijanie ukończonych wykresów
- Po naprawieniu nieudanej aplikacji nfApp, ale przed podjęciem próby uaktualnienia, rozważ zmianę parametru applicationEnablement w celu przyspieszenia zachowania ponawiania próby. Ten parametr można ustawić false, gdzie należy pominąć aplikację nfApp. Ten parametr może być przydatny, gdy aplikacja nfApp nie wymaga uaktualnienia.
Problemy z ponawianiem prób SNS (powtarzaj do skutku)
- Domyślnie system ponawia próby nfApps w zadeklarowanej kolejności aktualizacji, chyba że zostaną pominięte za pomocą flagi applicationEnablement.

Zarządzanie limitami czasu za pomocą opcji installOptions i UpgradeOptions

Gdy operacja SNS uruchamia helm install lub helm upgrade, jest używany domyślny limit czasu 27 minut. Chociaż tę wartość można dostosować na poziomie globalnej funkcji sieci (NF), zalecamy dostosowanie tej wartości na poziomie składnika NF przy użyciu roleOverrideValues szablonu ładunku NF. Dalsze eksponowanie komponentu roleOverrideValues w CGS/CGV pozwala operatorowi na kontrolę podczas działania. W poniższym przykładzie przedstawiono obsługiwane parametry installOptions i upgradeOptions stosowane w dwóch składnikach nfApp;

{
  "roleOverrideValues": [
    {
      "name": "nfApplication1",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            } } } } },
    {
      "name": "nfApplication2",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            } } } } }
  ]
}

Pomiń nfApps, używając applicationEnablement

W zasobie NFDV w obszarze deployParametersMappingRuleProfile znajduje się obsługiwana właściwość applicationEnablement wyliczenia typu, która przyjmuje wartości Nieznane, Włączone lub Wyłączone. Może służyć do ręcznego wykluczania operacji nfApp podczas wdrażania funkcji sieciowej. W poniższym przykładzie pokazano ogólną metodę parametryzacji applicationEnablement jako uwzględnionej wartości we roleOverrideValues właściwości.

Zmiany szablonu NFDV

Chociaż żadne zmiany NFDV nie są wymagane, opcjonalnie wydawca może użyć NFDV, aby ustawić wartość domyślną dla applicationEnablement właściwości. Wartość domyślna jest używana, chyba że została zmieniona za pośrednictwem roleOverrideValues. Użyj szablonu NFDV, aby ustawić wartość domyślną dla .applicationEnablement Poniższy przykład ustawia enabled stan jako wartość domyślną dla hellotest networkfunctionApplication.

      "location":"<location>", 
      "properties": {
      "networkFunctionTemplate": {
        "networkFunctionApplications": [
            "deployParametersMappingRuleProfile": {
              "applicationEnablement": "Enabled"
            },
            "name": "hellotest"
        ],
        "nfviType": "AzureArcKubernetes"
        },
      }

Aby zarządzać applicationEnablement wartością bardziej dynamicznie, Operator może przekazać wartość w czasie rzeczywistym przy użyciu właściwości szablonu roleOverrideValues NF. Chociaż operator może bezpośrednio manipulować szablonem NF, zaleca się zamiast tego sparametryzowanie elementu roleOverrideValues, aby wartości mogły być przekazywane za pośrednictwem szablonu CGV w czasie wykonywania. W poniższych przykładach pokazano wymagane modyfikacje szablonów CGS, NF, a na końcu CGV.

Zmiany szablonu usługi CGS

Szablon usługi CGS należy zaktualizować tak, aby zawierał jedną deklarację zmiennej dla każdego wiersza w celu sparametryzowania w obszarze roleOverrideValues. W poniższym przykładzie pokazano trzy wartości przesłonięcia.

        "roleOverrideValues0": {
          "type": "string"        
        },    
        "roleOverrideValues1": {
          "type": "string"        
        },        
        "roleOverrideValues2": {
          "type": "string"
        }

Zmiany szablonu ładunku NF

Szablon NF musi być aktualizowany na trzy sposoby. Najpierw niejawny parametr konfiguracji musi być zdefiniowany jako obiekt typu. Po drugie, roleOverrideValues0, roleOverrideValues1 i roleOverrideValues2 należy zadeklarować jako zmienne przypisane do parametru konfiguracji. Po trzecie, roleOverrideValues0, roleOverrideValues1 i roleOverrideValues2 muszą być uwzględnione do podstawienia w roleOverrideValues w odpowiedniej kolejności i zgodnie z właściwą składnią.

  "parameters": {
    "config": {
      "type": "object",
      "defaultValue": {}
    }
  }
  "variables": {
    "roleOverrideValues0": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues1": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues2": "[string(parameters('config').roleOverrideValues2)]"
  },
  "resources": [
  {
<snip>
     "roleOverrideValues": [
          "[variables('roleOverrideValues0')]",
          "[variables('roleOverrideValues1')]",
          "[variables('roleOverrideValues2')]"
        ]
   }

Zmiany szablonu CGV

Szablon CGV można teraz zaktualizować, aby uwzględnić treść każdej zmiennej, która ma zostać podstawiona do właściwości roleOverrideValues w czasie wykonywania. Poniższy przykład ustawia wartość rollbackEnabled true, a następnie zastępuje zestawy dla hellotest i hellotest1 nfApplications.

{
    "roleOverrideValues0": "{\"nfConfiguration\":{\"rollbackEnabled\":true}}",
    "roleOverrideValues1": "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\":\"Enabled\",\"helmMappingRuleProfile\":{\"releaseName\":\"override-release\",\"releaseNamespace\":\"override-namespace\",\"helmPackageVersion\":\"1.0.0\",\"values\":\"\",\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"}}}}}",
    "roleOverrideValues2": "{\"name\":\"hellotest1\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Enabled\"}}"
}

Dzięki tym ramom operator może zarządzać dowolnymi roleOverrideValues poprzez proste aktualizacje w CGV, a następnie dołączyć tę CGV do żądanej operacji SNS.

Pomiń nfApps, które nie mają żadnych zmian

Funkcja została zaprojektowana skipUpgrade tak, aby zoptymalizować czas potrzebny na uaktualnienia systemu CNF. Gdy wydawca włączy tę flagę w roleOverrideValues obszarze upgradeOptions, warstwa usługi AOSM wykonuje pewne wstępne kontrole, aby określić, czy można pominąć uaktualnienie dla określonego nfApplication elementu. Jeśli zostaną spełnione wszystkie kryteria wstępnej oceny, uaktualnienie zostanie pominięte dla tej aplikacji. W przeciwnym razie uaktualnienie jest wykonywane na poziomie klastra.

Kryteria wstępnej kontroli

Uaktualnienie można pominąć, jeśli spełnione są wszystkie następujące warunki:

Stan nfApplication aprowizacji jest Zakończony.
Brak zmian w nazwie lub wersji manifestu Helm.
Nie ma żadnych zmian w wartościach programu Helm.

Włączanie lub wyłączanie funkcji skipUpgrade

Funkcja skipUpgrade jest domyślnie wyłączona. Jeśli ten opcjonalny parametr nie jest określony w roleOverrideValues pod upgradeOptions, uaktualnienia CNF przebiegają w tradycyjny sposób, w którym nfApplications są uaktualniane na poziomie klastra.

Włączanie funkcji SkipUpgrade w zasobie funkcji sieciowych

Aby włączyć funkcję SkipUpgrade za pośrednictwem metody roleOverrideValues, zapoznaj się z poniższym przykładem.

{
    "location": "eastus2euap",
    "properties": {
        "publisherName": "xyAzureArcRunnerPublisher",
        "publisherScope": "Private",
        "networkFunctionDefinitionGroupName": "AzureArcRunnerNFDGroup",
        "networkFunctionDefinitionVersion": "1.0.0",
        "networkFunctionDefinitionOfferingLocation": "eastus2euap",
        "nfviType": "AzureArcKubernetes",
        "nfviId": "/subscriptions/4a0479c0-b795-4d0f-96fd-c7edd2a2928f/resourcegroups/ashutosh_test_rg/providers/microsoft.extendedlocation/customlocations/ashutosh_test_cl",
        "deploymentValues": "",
        "roleOverrideValues": [
            "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"1\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\",\"skipUpgrade\":\"true\"}}}}}",
            "{\"name\":\"runnerTest\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"5\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"5\"}}}}}"
        ]
    }
}

Wyjaśnienie przykładu

nfApplication: hellotest
- Flaga skipUpgrade jest włączona. Jeśli żądanie uaktualnienia spełnia hellotest kryteria wstępnego testowania, uaktualnienie zostanie pominięte.
nfApplication: runnerTest
- Flaga skipUpgrade nie jest określona. W związku z tym runnerTest wykonuje tradycyjne uaktualnienie Helm na poziomie klastra, nawet jeśli zostaną spełnione kryteria wstępnej oceny.

Kompletna dokumentacja opcji roleOverrideValues

Zbierając wszystkie przykłady z tego i innych artykułów, poniższa referencja przedstawia wszystkie obecnie obsługiwane opcje dostępne za pośrednictwem mechanizmu roleOverrideValues.

{
  "roleOverrideValues": [
    {
      "nfConfiguration": {
        "rollbackEnabled": "true"
      }
    },
    {
      "name": "nfApplication1",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "skipUpgrade": "true",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            }
          }
        }
      }
    },
    {
      "name": "nfApplication2",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "skipUpgrade": "true",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            }
          }
        }
      }
    }
  ]
}

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-05-21