სიახლეები და ანალიზი
ცვლილების დამტკიცება: ვერსიები, კონფლიქტები და შენახული გადაწყვეტილება
Pulumi ESC ერთდროულ მოთხოვნებს უჭერს მხარს; Durable Task ხანგრძლივ ლოდინს განიხილავს. ერთად ისინი ინფრასტრუქტურის დამტკიცების საზღვრებს აზუსტებს.
ორი გუნდი ერთ გარემოს ცვლის: ერთი კავშირის პარამეტრს აახლებს, მეორე ფუნქციას ამზადებს. საბაზო კონფიგურაცია მანამდე იცვლება, სანამ მფლობელი ორივე მოთხოვნის განხილვას დაასრულებს. თუ პროცესში მხოლოდ „დამტკიცებულია“ შეტყობინება რჩება, გაურკვეველია, რომელ ვერსიას ეხება გადაწყვეტილება. Pulumi-სა და Microsoft-ის ოქტომბრის პუბლიკაციები სიტუაციის სხვადასხვა მხარეს ეხება.
ერთდროულ მოთხოვნებს ვერსიების მკაფიო შედარება სჭირდება
7 ოქტომბერს Pulumi-მ ESC-ში ერთდროული ცვლილების მოთხოვნები წარადგინა. როცა საბაზო რევიზია იცვლება, მონახაზის განახლება სამმხრივი შერწყმით შეიძლება; კონფლიქტები ხელით გადასაწყვეტად ჩანს. ფუნქცია Pro და Enterprise გამოცემების დამტკიცებაჩართულ გარემოებს ეხება.
მფლობელისთვის პარალელური მუშაობა სარგებლის მხოლოდ ნაწილია. გუშინ განხილული წინადადება დღეს სხვა საფუძველზე შეიძლება იდგეს. დამტკიცებამ წინადადების იდენტობა უნდა შეინარჩუნოს და განხილვის შემდეგ ცვლილებები აჩვენოს. თუ გუნდები ერთ პარამეტრს ეხება, მკაფიო გადაწყვეტილების გარეშე ავტომატურმა გაგრძელებამ არსებითი კონფლიქტი შეიძლება დამალოს.
ადამიანის გადაწყვეტილების ლოდინმა პროცესის შეწყვეტას უნდა გაუძლოს
12 ოქტომბერს Microsoft-მა Durable Task-ის პრაქტიკული სცენარები განიხილა, ადამიანის დამტკიცებისა და გარემოს მომზადების ჩათვლით. მდგრადი შესრულება მომლოდინე პროცესს ინახავს, თუმცა შემმოწმებლის უფლებამოსილება, სანდო გადაწყვეტილება და გარე მოქმედების შედეგი აპლიკაციის პასუხისმგებლობა რჩება. სტატიის მაგალითები არქიტექტურას ასახავს და სრულ შემოწმებულ პროექტს არ წარმოადგენს.
შედარება პირობით დიზაინდასკვნას გვაძლევს: პროცესს ცვლილების ამოსაცნობი ვერსიაც სჭირდება და ამ ვერსიის შენახული გადაწყვეტილებაც. შესრულების ისტორია გარე შედეგების ზუსტად ერთხელ მოხდენას არ გვპირდება. კონფიგურაციის შერწყმა არც იმას ადგენს, ვის აქვს ცვლილების დამტკიცების უფლება.
ვერსიებისა და შენახული დამტკიცების კონცეპტუალური AI ილუსტრაცია.
შეამოწმეთ გზა მოთხოვნიდან გამოყენებამდე
სატესტო გარემოში ერთი საფუძვლიდან ორი წინადადება შექმენით. ერთი გამოიყენეთ, მეორე ხელახლა გახსენით და დაადგინეთ, ხედავს თუ არა შემმოწმებელი განახლებულ საფუძველს. კონფლიქტური პარამეტრისთვის შეათანხმეთ, ვინ წყვეტს და სჭირდება თუ არა შეცვლილ წინადადებას ახალი განხილვა.
ცალკე გააჩერეთ შემსრულებელი დამტკიცების მოლოდინში. ხელახალი გაშვებისას მოთხოვნა, ვადა და შენახული გადაწყვეტილება უნდა აღადგინოს. გამოსცადეთ გადაწყვეტილება, რომელიც შეტყობინების მოსვლამდე ჩაიწერა. სანდო შენახული გადაწყვეტილება შეტყობინების დროს უფრო მნიშვნელოვანია.
მიღება კონკრეტული გახადეთ: გუნდს შეუძლია დაადგინოს ავტორი, განხილული ვერსია, გადაწყვეტილება და ცვლილების გამოყენების რეალური შედეგი. ახალი შესრულების გარემო ავტომატურად საჭირო არ არის, თუ არსებული პროცესი ამ თვისებებს უკვე უზრუნველყოფს.
ჩვენი ფონური სამუშაოებისა და განმეორებების გზამკვლევი მეზობელ პასუხისმგებლობას ეხება. ინფრასტრუქტურის საარქივო აღწერა სამუშაო მოთხოვნებს ჩამოთვლის ყველა კომპონენტის დანერგვის დადასტურების გარეშე. ინფრასტრუქტურის მოვლისთვის განვიხილოთ, რომელ ცვლილებებს სჭირდება დამტკიცება და სად კარგავს მიმდინარე პროცესი მდგომარეობას.