სიახლეები და ანალიზი
დანერგვების ისტორია: შენახვის ვადა აღდგენის გეგმას უნდა შეესაბამებოდეს
Vercel-ის შენახვის ცვლილებები და GitLab Artifact Central-ის ბეტა რელიზების ისტორიას, არტეფაქტების ხელმისაწვდომობასა და პასუხისმგებლობას აკავშირებს.
აპლიკაციის წინა ვერსია მხოლოდ მანამდეა გამოსადეგი, სანამ გუნდს მისი პოვნა და გამოყენება შეუძლია. როცა პლატფორმა დანერგვების ისტორიას ამოკლებს, აღდგენის გეგმაც იცვლება. Vercel-ისა და GitLab-ის ოქტომბრის განცხადებები აჩვენებს, რატომ უნდა იყოს არტეფაქტების შენახვა საოპერაციო დაგეგმვის ნაწილი და არა ნაგულისხმევად დატოვებული პარამეტრი.
რა იცვლება Vercel-ში
9 ოქტომბრის განცხადებაში არსებული Pro გუნდებისთვის Vercel აღწერს Deployment and Functions Storage-ის დარიცხვას და 30-დღიან შენახვის პერიოდს. ძველი დანერგვების წაშლა 23 ოქტომბერს დაიწყება, თუ გუნდები მანამდე შენახვის პარამეტრებს არ შეცვლიან. დარიცხვის დაწყების ზუსტ თარიღს თითოეულ გუნდს ცალკე ელფოსტით ატყობინებენ.
იმავე თარიღის მეორე განცხადება ეხება ახალ Pro გუნდებს, სადაც ნაგულისხმევი ვადა 30 დღე ხდება. წაშლილი დანერგვის აღდგენა ან უკან დაბრუნებისთვის გამოყენება შეუძლებელია. შეტყობინებები სხვადასხვა ჯგუფს ეხება; პირობების შემოწმების გარეშე ერთ ვადას ყველა ანგარიშზე ნუ გაავრცელებთ.
მფლობელისთვის ახლანდელი ნაბიჯი კონკრეტულია: დაადგინოს პროექტის პოლიტიკა და რომელი შემოწმებული რელიზები დარჩება წაშლის შემდეგ. ისტორიას ბრმად ნუ შეამოკლებთ. ჯერ შეთანხმდით, რამდენი დრო სჭირდება გუნდს პრობლემის აღმოსაჩენად და ვინ წყვეტს წინა ვერსიაზე დაბრუნებას.
პაკეტების რეესტრს სხვა პოლიტიკა აქვს
6 ოქტომბერს GitLab-მა Artifact Central უფასო ბეტას სახით წარადგინა: ორგანიზაციის დონის რეესტრი როლებით, კვოტებითა და შენახვის წესებით, npm, Maven და Docker/OCI საცავების ჩათვლით. მისი ბეტა სტატუსი საოპერაციო მოთხოვნებთან მიმართებით ცალკე უნდა შეფასდეს.
კავშირი არ ნიშნავს, რომ ეს პროდუქტები ერთმანეთს ცვლის. დანერგვები და პაკეტები შეიძლება სხვადასხვა ადგილას სხვადასხვა ვადით ინახებოდეს. თუ პაკეტი გაქრება, მხოლოდ რელიზის ჩანაწერი არ ნიშნავს, რომ გუნდი იმავე შედეგს ისევ განათავსებს. მეორე მხრივ, შენახული იმიჯი მასთან დაკავშირებულ კონფიგურაციას ან მონაცემთა მდგომარეობას არ ხსნის.
რელიზების შენახვისა და აღდგენის მასალების კონცეპტუალური AI ილუსტრაცია.
შეამოწმეთ, ისტორიის რომელი ნაწილია რეალურად გამოსადეგი
შექმენით მოკლე ინვენტარი: აპლიკაციის რელიზი, კოდის რევიზია, პაკეტი ან იმიჯი, გარემოს პარამეტრები და მონაცემთა შესაბამისი ცვლილებები. თითოეულისთვის მიუთითეთ საცავი და შენახვის ვადა. მონაცემთა ბაზის სარეზერვო ასლები აპლიკაციის ისტორიისგან გამიჯნეთ, რადგან სხვადასხვა პრობლემას წყვეტს.
ცალკე გარემოში სცადეთ შერჩეული შემოწმებული რელიზის აღდგენა რეალურად შენახული მასალებით. დაადგინეთ, რომ პროცედურა წაშლილ დანერგვაზე ან ვინმეს ლეპტოპში შემთხვევით დარჩენილ ფაილზე არ არის დამოკიდებული. პოლიტიკას პასუხისმგებელი მიუჩინეთ და ცვლილებისას შემოწმება გაიმეორეთ.
ჩვენი სერვერის, როგორც სისტემის ბირთვის გზამკვლევი გაშვებას შენარჩუნებული მდგომარეობისგან განასხვავებს. ინფრასტრუქტურის საარქივო მასალა აღდგენის მოთხოვნებს აღწერს ყველა კომპონენტის მიმდინარე მუშაობის დადასტურების გარეშე. თქვენი მხარდაჭერის გეგმისთვის განვიხილოთ გამოსადეგი ისტორია და რელიზის აღდგენის შემოწმება.