Nowy widżet postępu i ulepszone zabezpieczenia potoków — aktualizacja przebiegu 160
W aktualizacji Przebiegu 160 usługi Azure DevOps dodaliśmy nowy widżet postępu przebiegu, który obsługuje wypalanie według punktów scenariuszy, liczbę zadań i sumowanie pól niestandardowych. Ponadto ulepszyliśmy zabezpieczenia potoków, ograniczając zakres tokenów dostępu.
Zapoznaj się z listą funkcji poniżej, aby uzyskać więcej informacji.
Co nowego w usłudze Azure DevOps
Funkcje
Azure Repos:
Azure Pipelines:
- Wieloetapowy interfejs użytkownika potoków
- Organizowanie strategii wdrażania kanaarowego w środowisku dla platformy Kubernetes
- Zasady zatwierdzania dla potoków YAML
- Usługa ACR jako zasób potoku pierwszej klasy
- Metadane zasobów potoku jako wstępnie zdefiniowane zmienne
- Możliwość śledzenia potoków i zasobów usługi ACR
- Uproszczona autoryzacja zasobów w potokach YAML
- Zwiększanie zabezpieczeń potoku przez ograniczenie zakresu tokenów dostępu
- Ocena sprawdzania artefaktu
- Obsługa języka Markdown w komunikatach o błędach testów automatycznych
- Diagnozowanie harmonogramów cron w języku YAML
- Aktualizacje do zadania wdrożenia szablonu usługi ARM
- Zabezpieczenia na poziomie projektu dla połączeń usług
- Pula ubuntu 18.04
- Wdrożenia kanary oparte na interfejsie usługi Service Mesh w zadaniu KubernetesManifest
- Przeglądanie aplikacji w środowisku
Azure Artifacts:
- Zaktualizowano środowisko nawiązywania połączenia z kanałem informacyjnym
- Publiczne kanały informacyjne są teraz ogólnie dostępne z obsługą nadrzędną
- Tworzenie źródeł danych o zakresie projektu z poziomu portalu
Raportowanie:
Wiki:
Azure Repos
Administrowanie zasadami gałęzi między repozytoriami
Zasady gałęzi to jedna z zaawansowanych funkcji Azure Repos, które ułatwiają ochronę ważnych gałęzi. Chociaż w interfejsie API REST istnieje możliwość ustawiania zasad na poziomie projektu, nie było dla niego interfejsu użytkownika. Teraz administratorzy mogą ustawić zasady dla określonej gałęzi lub domyślnej gałęzi we wszystkich repozytoriach w projekcie. Na przykład administrator może wymagać dwóch minimalnych recenzentów dla wszystkich żądań ściągnięcia wysyłanych do każdej gałęzi głównej w każdym repozytorium w projekcie. Funkcję Dodaj ochronę gałęzi można znaleźć w obszarze Ustawienia projektu repozytoriów.
Azure Pipelines
Wieloetapowy interfejs użytkownika potoków
Pracujemy nad zaktualizowanym środowiskiem użytkownika w celu zarządzania potokami. Te aktualizacje sprawiają, że potoki są nowoczesne i spójne z kierunkiem usługi Azure DevOps. Ponadto te aktualizacje łączą klasyczne potoki kompilacji i wieloetapowe potoki YAML w jednym środowisku. Na przykład następujące możliwości są uwzględniane w nowym środowisku; wyświetlanie wielu etapów i zarządzanie nimi, zatwierdzanie przebiegów potoku, możliwość przewijania do końca dzienników, gdy potok jest nadal w toku, oraz kondycja poszczególnych gałęzi potoku.
Dziękujemy wszystkim, którzy próbowali nowego środowiska. Jeśli jeszcze tego nie próbowano, włącz potoki wieloetapowe w funkcjach w wersji zapoznawczej. Aby dowiedzieć się więcej na temat potoków wieloetapowych, zobacz dokumentację tutaj .
Dzięki Twojej opinii zwróciliśmy się do poniższych w dwóch ostatnich aktualizacjach.
- Możliwość odnajdywania widoku folderów.
- Gotowość do pracy w widoku dzienników.
- Łatwo wyświetlaj dzienniki z poprzednich i bieżących zadań nawet wtedy, gdy przebieg jest w toku.
- Ułatwiaj nawigowanie między zadaniami podczas przeglądania dzienników.
Uwaga
W następnej aktualizacji planujemy domyślnie włączyć tę funkcję dla wszystkich użytkowników. Nadal będziesz mieć możliwość rezygnacji z wersji zapoznawczej. Kilka tygodni później funkcja zostanie ogólnie udostępniona.
Organizowanie strategii wdrażania kanaarowego w środowisku dla platformy Kubernetes
Jedną z kluczowych zalet ciągłego dostarczania aktualizacji aplikacji jest możliwość szybkiego wypychania aktualizacji do środowiska produkcyjnego dla określonych mikrousług. Dzięki temu można szybko reagować na zmiany wymagań biznesowych. Środowisko zostało wprowadzone jako pierwszoklasowa koncepcja umożliwiająca organizowanie strategii wdrażania i ułatwianie wydawania bez przestojów. Wcześniej obsługiwaliśmy strategię runOnce , która wykonała kroki po sekwencyjnie. Dzięki obsłudze strategii kanarowej w potokach wieloetapowych można teraz zmniejszyć ryzyko, powoli wdrażając zmianę w małym podzestawie. Gdy zyskujesz większą pewność co do nowej wersji, możesz zacząć wdrażać ją na większej infrastruktury i kierować do niej większej liczby użytkowników.
jobs:
- deployment:
environment: musicCarnivalProd
pool:
name: musicCarnivalProdPool
strategy:
canary:
increments: [10,20]
preDeploy:
steps:
- script: initialize, cleanup....
deploy:
steps:
- script: echo deploy updates...
- task: KubernetesManifest@0
inputs:
action: $(strategy.action)
namespace: 'default'
strategy: $(strategy.name)
percentage: $(strategy.increment)
manifests: 'manifest.yml'
postRouteTaffic:
pool: server
steps:
- script: echo monitor application health...
on:
failure:
steps:
- script: echo clean-up, rollback...
success:
steps:
- script: echo checks passed, notify...
Strategia kanaryczna dla platformy Kuberenetes najpierw wdroży zmiany z 10% zasobnikami, a następnie 20% podczas monitorowania kondycji podczas postRouteTraffic. Jeśli wszystko pójdzie dobrze, będzie promować do 100%.
Szukamy wczesnych opinii na temat obsługi zasobów maszyny wirtualnej w środowiskach i przeprowadzania strategii wdrażania operacyjnego na wielu maszynach. Skontaktuj się z nami , aby zarejestrować się.
Zasady zatwierdzania dla potoków YAML
W potokach YAML stosujemy konfigurację zatwierdzania sterowaną przez właściciela zasobu. Właściciele zasobów konfigurują zatwierdzenia zasobu i wszystkich potoków, które korzystają z wstrzymania zasobu na potrzeby zatwierdzeń przed rozpoczęciem etapu zużywania zasobu. Właściciele aplikacji opartych na soX często ograniczają osoby żądające wdrożenia od zatwierdzania własnych wdrożeń.
Możesz teraz użyć zaawansowanych opcji zatwierdzania , aby skonfigurować zasady zatwierdzania, takie jak osoba żądająca, nie powinny zatwierdzać, wymagają zatwierdzenia z podzbioru użytkowników i limitu czasu zatwierdzania.
Usługa ACR jako zasób potoku pierwszej klasy
Jeśli musisz użyć obrazu kontenera opublikowanego w usłudze ACR (Azure Container Registry) w ramach potoku i wyzwolić potok za każdym razem, gdy nowy obraz został opublikowany, możesz użyć zasobu kontenera usługi ACR.
resources:
containers:
- container: MyACR #container resource alias
type: ACR
azureSubscription: RMPM #ARM service connection
resourceGroup: contosoRG
registry: contosodemo
repository: alphaworkz
trigger:
tags:
include:
- production
Ponadto dostęp do metadanych obrazu usługi ACR można uzyskać przy użyciu wstępnie zdefiniowanych zmiennych. Poniższa lista zawiera zmienne usługi ACR dostępne do definiowania zasobu kontenera usługi ACR w potoku.
resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location
Metadane zasobów potoku jako wstępnie zdefiniowane zmienne
Dodaliśmy wstępnie zdefiniowane zmienne dla zasobów potoków YAML w potoku. Oto lista dostępnych zmiennych zasobów potoku.
resources.pipeline.<Alias>.projectName
resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID
Możliwość śledzenia potoków i zasobów usługi ACR
Zapewniamy pełną możliwość śledzenia E2E, gdy potoki i zasoby kontenera usługi ACR są używane w potoku. Dla każdego zasobu używanego przez potok YAML można śledzić zatwierdzenia, elementy robocze i artefakty.
W widoku podsumowania przebiegu potoku można zobaczyć:
Wersja zasobu, która wyzwoliła przebieg. Teraz potok można wyzwolić po zakończeniu innego uruchomienia potoku platformy Azure lub wypchnięciu obrazu kontenera do usługi ACR.
Zatwierdzenia, które są używane przez potok. Podział zatwierdzeń można również znaleźć dla każdego zasobu używanego przez potok.
Elementy robocze skojarzone z poszczególnymi zasobami używanymi przez potok.
Artefakty, które są dostępne do użycia przez przebieg.
W widoku wdrożeń środowiska można zobaczyć zatwierdzenia i elementy robocze dla każdego zasobu wdrożonego w środowisku.
Uproszczona autoryzacja zasobów w potokach YAML
Zasób jest używany przez potok, który znajduje się poza potokiem. Zasoby muszą być autoryzowane, zanim będą mogły być używane. Wcześniej w przypadku korzystania z nieautoryzowanych zasobów w potoku YAML wystąpił błąd autoryzacji zasobu. Trzeba było autoryzować zasoby ze strony podsumowania przebiegu, który zakończył się niepowodzeniem. Ponadto potok nie powiódł się, jeśli używa zmiennej, która odwoływała się do nieautoryzowanego zasobu.
Teraz ułatwiamy zarządzanie autoryzacjami zasobów. Zamiast niepowodzenia przebiegu, przebieg będzie czekać na uprawnienia do zasobów na początku etapu zużywającego zasób. Właściciel zasobu może wyświetlić potok i autoryzować zasób na stronie Zabezpieczenia.
Zwiększanie zabezpieczeń potoku przez ograniczenie zakresu tokenów dostępu
Każde zadanie uruchamiane w usłudze Azure Pipelines otrzymuje token dostępu. Token dostępu jest używany przez zadania i skrypty do wywołania z powrotem do usługi Azure DevOps. Na przykład używamy tokenu dostępu do pobierania kodu źródłowego, przekazywania dzienników, wyników testów, artefaktów lub nawiązywania wywołań REST do usługi Azure DevOps. Nowy token dostępu jest generowany dla każdego zadania i wygasa po zakończeniu zadania. Dzięki tej aktualizacji dodaliśmy następujące ulepszenia.
Uniemożliwianie tokenowi uzyskiwania dostępu do zasobów poza projektem zespołowym
Do tej pory domyślnym zakresem wszystkich potoków była kolekcja projektów zespołowych. Zakres można zmienić tak, aby był projektem zespołowym w klasycznych potokach kompilacji. Nie masz jednak tej kontroli dla potoków klasycznych wydań ani YAML. Dzięki tej aktualizacji wprowadzamy ustawienie organizacji, aby wymusić na każdym zadaniu uzyskanie tokenu o zakresie projektu niezależnie od tego, co zostało skonfigurowane w potoku. Dodaliśmy również ustawienie na poziomie projektu. Teraz każdy nowy projekt i utworzona organizacja będą automatycznie miały włączone to ustawienie.
Uwaga
Ustawienie organizacji zastępuje ustawienie projektu.
Włączenie tego ustawienia w istniejących projektach i organizacjach może spowodować niepowodzenie niektórych potoków, jeśli potoki uzyskują dostęp do zasobów spoza projektu zespołowego przy użyciu tokenów dostępu. Aby wyeliminować błędy potoku, możesz jawnie przyznać usłudze Project Build Service Account dostęp do żądanego zasobu. Zdecydowanie zalecamy włączenie tych ustawień zabezpieczeń.
Usuwanie niektórych uprawnień dla tokenu dostępu
Domyślnie udzielamy wielu uprawnień do tokenu dostępu. Jednym z tych uprawnień jest kompilacja kolejki. Dzięki tej aktualizacji usunęliśmy to uprawnienie do tokenu dostępu. Jeśli potoki potrzebują tego uprawnienia, możesz jawnie udzielić go kontu usługi kompilacji projektu lub kontu usługi kompilacjikolekcji projektów w zależności od używanego tokenu.
Ocena sprawdzania artefaktu
Teraz można zdefiniować zestaw zasad i dodać ocenę zasad jako sprawdzenie środowiska dla artefaktów obrazu kontenera. Po uruchomieniu potoku wykonanie jest wstrzymywane przed rozpoczęciem etapu, który używa środowiska. Określone zasady są oceniane względem dostępnych metadanych dla wdrażanego obrazu. Sprawdzanie zakończy się powodzeniem i oznacza etap jako niepowodzenie, jeśli sprawdzanie zakończy się niepowodzeniem.
Obsługa języka Markdown w komunikatach o błędach testów automatycznych
Teraz obsługujemy język Markdown w komunikatach o błędach na potrzeby testów automatycznych. Możesz łatwo sformatować komunikaty o błędach zarówno dla przebiegu testu, jak i wyniku testu, aby zwiększyć czytelność i ułatwić rozwiązywanie problemów z błędem w usłudze Azure Pipelines. Obsługiwaną składnię języka Markdown można znaleźć tutaj.
Diagnozowanie harmonogramów cron w języku YAML
Zaobserwowaliśmy stały wzrost użycia składni cron do określania harmonogramów w potokach YAML. Podczas nasłuchiwania opinii słyszeliśmy, że trudno ci ustalić, czy usługa Azure Pipelines prawidłowo przetworzyła składnię. Wcześniej trzeba było poczekać na rzeczywisty czas zaplanowanego uruchomienia w celu debugowania problemów z harmonogramem. Aby ułatwić diagnozowanie błędów gałęzi/składni, dodaliśmy nowe menu akcji dla potoku. Zaplanowane przebiegi w menu Uruchom potok zapewni podgląd nadchodzących kilku zaplanowanych uruchomień potoku, aby ułatwić diagnozowanie błędów z harmonogramami cron.
Aktualizacje do zadania wdrożenia szablonu usługi ARM
Wcześniej nie filtrowaliśmy połączeń usług w zadaniu wdrażania szablonu usługi ARM. Może to spowodować niepowodzenie wdrożenia w przypadku wybrania połączenia usługi o niższym zakresie w celu wykonania wdrożeń szablonów usługi ARM w szerszym zakresie. Teraz dodaliśmy filtrowanie połączeń usług, aby odfiltrować połączenia usługi o niższym zakresie na podstawie wybranego zakresu wdrożenia.
Zabezpieczenia na poziomie projektu dla połączeń usług
W przypadku tej aktualizacji dodaliśmy zabezpieczenia na poziomie centrum dla połączeń usług. Teraz możesz dodawać/usuwać użytkowników, przypisywać role i zarządzać dostępem w scentralizowanym miejscu dla wszystkich połączeń usług.
Pula ubuntu 18.04
Usługa Azure Pipelines obsługuje teraz uruchamianie zadań w systemie Ubuntu 18.04. Zaktualizowaliśmy pulę usługi Azure Pipelines hostowaną przez firmę Microsoft w celu uwzględnienia obrazu Ubuntu-18.04. Teraz, gdy odwołujesz się do ubuntu-latest puli w potokach YAML, będzie to oznaczać ubuntu-18.04 , a nie ubuntu-16.04. Nadal można kierować obrazy 16.04 w zadaniach przy użyciu ubuntu-16.04 jawnie.
Wdrożenia kanary oparte na interfejsie usługi Service Mesh w zadaniu KubernetesManifest
Wcześniej, gdy strategia kanaryczna została określona w zadaniu KubernetesManifest, zadanie tworzyłoby obciążenia bazowe i kanary, których repliki były równe procentowi replik używanych na potrzeby stabilnych obciążeń. Nie było to dokładnie takie samo, jak dzielenie ruchu do żądanej wartości procentowej na poziomie żądania. Aby rozwiązać ten problem, dodaliśmy obsługę wdrożeń kanarowych opartych na interfejsie usługi Service Mesh do zadania KubernetesManifest.
Abstrakcja interfejsu usługi Service Mesh umożliwia konfigurowanie wtyczek i odtwarzania z dostawcami usługi, takimi jak Linkerd i Istio. Teraz zadanie KubernetesManifest eliminuje ciężką pracę mapowania obiektów TrafficSplit usługi SMI na stabilne, bazowe i kanary w cyklu życia strategii wdrażania. Żądany procent podziału ruchu między stabilnym, bazowym i kanarowym jest dokładniejszy, ponieważ procentowy podział ruchu jest kontrolowany na żądaniach na płaszczyźnie siatki usług.
Poniżej przedstawiono przykład wykonywania wdrożeń kanarowych opartych na protokole SMI w sposób stopniowy.
- deployment: Deployment
displayName: Deployment
pool:
vmImage: $(vmImage)
environment: ignite.smi
strategy:
canary:
increments: [25, 50]
preDeploy:
steps:
- task: KubernetesManifest@0
displayName: Create/update secret
inputs:
action: createSecret
namespace: smi
secretName: $(secretName)
dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
deploy:
steps:
- checkout: self
- task: KubernetesManifest@0
displayName: Deploy canary
inputs:
action: $(strategy.action)
namespace: smi
strategy: $(strategy.name)
trafficSplitMethod: smi
percentage: $(strategy.increment)
baselineAndCanaryReplicas: 1
manifests: |
manifests/deployment.yml
manifests/service.yml
imagePullSecrets: $(secretName)
containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
postRouteTraffic:
pool: server
steps:
- task: Delay@1
inputs:
delayForMinutes: '2'
Przeglądanie aplikacji w środowisku
Zobacz Aplikacja wdraża każde żądanie ściągnięcia z repozytorium Git w zasobie środowiska dynamicznego. Recenzenci mogą zobaczyć, jak wyglądają te zmiany, a także pracować z innymi usługami zależnymi przed scaleniem ich z gałęzią główną i wdrożoną w środowisku produkcyjnym. Ułatwi to tworzenie zasobów aplikacji i zarządzanie nimi, a także korzystanie ze wszystkich funkcji śledzenia i diagnostyki funkcji środowiska. Za pomocą słowa kluczowego reviewApp można utworzyć klon zasobu (dynamicznie utworzyć nowy zasób na podstawie istniejącego zasobu w środowisku) i dodać nowy zasób do środowiska.
Poniżej przedstawiono przykładowy fragment kodu YAML dotyczący używania funkcji reviewApp w środowiskach.
jobs:
- deployment:
environment:
name: smarthotel-dev
resourceName: $(System.PullRequest.PullRequestId)
pool:
name: 'ubuntu-latest'
strategy:
runOnce:
pre-deploy:
steps:
- reviewApp: MasterNamespace
Azure Artifacts
Zaktualizowano środowisko nawiązywania połączenia z kanałem informacyjnym
Okno dialogowe Łączenie z kanałem informacyjnym to wejście do korzystania z usługi Azure Artifacts; Zawiera informacje na temat konfigurowania klientów i repozytoriów w celu wypychania i ściągania pakietów ze źródeł danych w usłudze Azure DevOps. Zaktualizowaliśmy okno dialogowe, aby dodać szczegółowe informacje o konfiguracji i rozszerzyć narzędzia, dla których udostępniamy instrukcje.
Publiczne kanały informacyjne są teraz ogólnie dostępne z obsługą nadrzędną
Publiczna wersja zapoznawcza publicznych kanałów informacyjnych otrzymała wielką akceptację i opinie. W tej aktualizacji rozszerzyliśmy dodatkowe funkcje do ogólnej dostępności. Teraz możesz ustawić publiczne źródło danych jako źródło nadrzędne z prywatnego kanału informacyjnego. Pliki konfiguracji mogą być proste, ponieważ mogą być przesyłane strumieniowo zarówno do kanałów prywatnych, jak i z kanałów informacyjnych o zakresie projektu.
Tworzenie źródeł danych o zakresie projektu z poziomu portalu
Po udostępnieniu publicznych kanałów informacyjnych udostępniliśmy również kanały informacyjne o zakresie projektu. Do tej pory źródła danych o zakresie projektu można tworzyć za pośrednictwem interfejsów API REST lub przez utworzenie publicznego kanału informacyjnego, a następnie włączenie prywatnego projektu. Teraz możesz tworzyć źródła danych o zakresie projektu bezpośrednio w portalu z dowolnego projektu, jeśli masz wymagane uprawnienia. Możesz również zobaczyć, które źródła danych są projektami i które są objęte zakresem organizacji w selektorze kanału informacyjnego.
Raportowanie
Widżet Sprint Burndown z wszystkim, o co prosiłeś
Nowy widżet Postępu przebiegu obsługuje wypalanie według punktów historii, liczby zadań lub sumowania pól niestandardowych. Można nawet utworzyć przebieg dla funkcji lub epików. Widżet wyświetla średnie spalenie, procent ukończenia i zwiększenie zakresu. Możesz skonfigurować zespół, umożliwiając wyświetlanie postępu przebiegu dla wielu zespołów na tym samym pulpicie nawigacyjnym. Dzięki tym wszystkim doskonałym informacjom do wyświetlenia można zmienić jego rozmiar do 10x10 na pulpicie nawigacyjnym.
Aby go wypróbować, możesz dodać go z katalogu widżetów lub edytując konfigurację istniejącego widżetu Sprint Burndown i zaznaczając pole Wypróbuj nową wersję teraz .
Uwaga
Nowy widżet używa analizy. Zachowaliśmy starsze burndown przebiegu w przypadku, gdy nie masz dostępu do usługi Analytics.
Witryna Wiki
Synchroniczne przewijanie do edytowania stron typu wiki
Edytowanie stron typu wiki jest teraz łatwiejsze dzięki synchronicznej przewijaniu między edycją a okienkiem podglądu. Przewijanie po jednej stronie spowoduje automatyczne przewinięcie drugiej strony, aby zamapować odpowiednie sekcje. Możesz wyłączyć synchroniczne przewijanie za pomocą przycisku przełącznika.
Uwaga
Stan przełącznika przewijania synchronicznego jest zapisywany dla użytkownika i organizacji.
Wizyty na stronach typu wiki
Teraz możesz uzyskać szczegółowe informacje na temat wizyt na stronie dla stron typu wiki. Interfejs API REST umożliwia dostęp do informacji o odwiedzinach strony w ciągu ostatnich 30 dni. Te dane umożliwiają tworzenie raportów dla stron typu wiki. Ponadto możesz przechowywać te dane w źródle danych i tworzyć pulpity nawigacyjne, aby uzyskać szczegółowe informacje, takie jak najczęściej wyświetlane strony.
Na każdej stronie zostanie również wyświetlona zagregowana liczba wizyt na stronie z ostatnich 30 dni.
Uwaga
Wizyta strony jest definiowana jako widok strony przez danego użytkownika w 15-minutowym interwale.
Następne kroki
Uwaga
Te funkcje będą wdrażane w ciągu najbliższych dwóch do trzech tygodni.
Przejdź do usługi Azure DevOps i spójrz.
Jak przekazać opinię
Chcielibyśmy usłyszeć, co myślisz o tych funkcjach. Użyj menu Pomocy, aby zgłosić problem lub podać sugestię.
Możesz również uzyskać porady i pytania, na które odpowiada społeczność w witrynie Stack Overflow.
Dzięki,
Jeff Beehler
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla