WordPress მიგრაციის staging და cutover გეგმა

მოკლე პასუხი (TL;DR): WordPress-ის staging და cutover გეგმა გამოყოფს საცდელ გარემოს, საბოლოო შემოწმებას და ცოცხალ დომენზე გადართვას. გეგმა უნდა აღწერდეს რა იყინება, ვინ ამტკიცებს, როგორ იტესტება ფორმა და URL, ვინ ცვლის DNS-ს და რა პირობით ბრუნდება გუნდი ძველ გარემოში.

„საიტი მზად არის“ მხოლოდ ვიზუალურ შეფასებად არ უნდა დარჩეს. aiWEB-ის პროექტში სამუშაო ფარგლები, ვადები, გადაცემის წესი და ტექნიკური მოვლა წინასწარ შეთანხმდება, ხოლო გადართვის გადაწყვეტილება შემოწმების ჩანაწერებს ეყრდნობა.

გეგმის 3 ეტაპი

1. მომზადება: კონტენტის, URL-ების, წვდომებისა და ასლების დადასტურება;
2. staging: ახალი გარემოს, ფორმების, გვერდების, რედაქტირების და გადამისამართებების ტესტი;
3. cutover: ცვლილების ფანჯარა, DNS ან ჰოსტინგის გადართვა, ცოცხალი შემოწმება და მონიტორინგი.

ეს ეტაპები შეიძლება ერთ სამუშაო დღეში შესრულდეს ან უფრო დიდ პროექტში გაიყოს, მაგრამ თითოეულის დასრულება ცალკე უნდა იყოს დადასტურებული. staging-ზე წარმატებული ტესტი ავტომატურად არ ნიშნავს, რომ დომენი სწორ გარემოს აჩვენებს.

რა უნდა ემთხვეოდეს staging-ს

საცდელ გარემოში შეამოწმეთ რეალური კონტენტის მოდელი, გვერდის შაბლონები, სურათები, ფორმის მიმღებები, ელფოსტის გაგზავნა, ავტორიზაცია, ენის ვერსიები, canonical, sitemap და redirect წესები. ტექნიკურ გარემოსა და ცოცხალ გარემოს შორის განსხვავება დოკუმენტში ჩაწერეთ.

staging არ უნდა იყოს საძიებო სისტემისთვის შემთხვევით ღია სამუშაო ასლი. აკონტროლეთ ავტორიზაცია და ინდექსაციის პარამეტრები, შემდეგ გადართვამდე ცალკე გადაამოწმეთ, რომ ცოცხალ საიტს staging-ის წესები არ გაჰყვა.

კონტენტის გაყინვა

განსაზღვრეთ დრო, რომლის შემდეგაც WordPress-ის ძველ საიტზე ცვლილებები აღარ შედის ან მხოლოდ ერთ პასუხისმგებელზე გადის. გაყინვის სიაში ჩაწერეთ სტატია, გვერდი, სურათი, ფორმა, მომხმარებელი და შეკვეთა, თუ საიტს ასეთი ფუნქცია აქვს. ყველა გამონაკლისი უნდა ჩაიწეროს, რომ ახალი გარემო ძველ ვერსიას არ გადააწეროს.

თუ კონტენტის გაყინვა შეუძლებელია, შეათანხმეთ ბოლო მონაცემების გადმოტანის გზა და მისი შემოწმება. WordPress-ის მიგრაციის დოკუმენტაცია გვახსენებს, რომ ფაილებისა და მონაცემთა ბაზის გადატანა ცალკე ნაწილებად უნდა დაიგეგმოს.

ტესტის მატრიცა

Cutover-ის runbook

გადართვის დღეს ერთ დოკუმენტში ჩაწერეთ მოქმედებების თანმიმდევრობა: ბოლო ასლი, საჭირო გაყინვა, DNS ან ჰოსტინგის ცვლილება, cache-ის მართვა, SSL-ის შემოწმება, ფორმის ტესტი, ძირითადი URL-ები, redirect-ები და პასუხისმგებელი ადამიანები. მიუთითეთ ვინ იღებს გადაწყვეტილებას და სად ინახება შეცდომის ჩანაწერი.

თუ დომენი ან URL იცვლება, Google-ის რეკომენდაციით წინასწარ მოამზადეთ შესაბამისობის რუკა, სერვერული 301 ან 308, canonical, შიდა ბმულები და sitemap. ეს სამუშაო redirect ჩეკლისტთან ერთად უნდა შემოწმდეს.

დაბრუნების გეგმა

დაბრუნების გეგმა აღწერს, რომელი პირობების დადგომისას შეწყდება cutover. მაგალითად, ფორმა არ იგზავნება, კრიტიკული სერვისი იხსნება შეცდომით, ძველი URL-ები არასწორ გვერდზე გადადის ან ბიზნესის მფლობელი ვერ ამოწმებს მთავარ მოქმედებას. დაბრუნების გადაწყვეტილებას ორი პასუხისმგებელი წინასწარ უნდა იცნობდეს, რათა დუმილი მიღებად არ ჩაითვალოს.

დაბრუნების ცდა ცალკე უნდა იყოს შემოწმებული. ასლი, რომელიც არსებობს, მაგრამ ვერ აღდგა, დაბრუნების გეგმა ვერ არის. დომენისა და ჰოსტინგის მფლობელობის რუკა დაგეხმარებათ გაირკვეს, ვის აქვს რეალური ცვლილების უფლება.

სცენარი: კომპანიის ახალი საიტის გადართვა

წარმოიდგინეთ კომპანია, რომელმაც ახალი საიტი staging-ზე დაამტკიცა, მაგრამ ძველ WordPress-ზე ბოლო კვირაში კიდევ დაემატა რამდენიმე სტატია და შეიცვალა ფორმის მიმღები. გუნდი cutover-ს არ იწყებს მხოლოდ იმიტომ, რომ დიზაინი მზადაა.

ჯერ ადგენს ბოლო კონტენტის სიის სხვაობას, იღებს ახალ ასლს, იმეორებს ფორმის ტესტს და ცვლის runbook-ს. დომენის ცვლილების შემდეგ ამოწმებს რამდენიმე ძველ URL-ს, ახალ გვერდებს, ელფოსტას და მობილურ მენიუს. თუ ერთი კრიტიკული ფორმა არ მოდის, rollback-ის პირობა აქტიურდება და შეცდომა დოკუმენტირდება.

შედარება: ერთბაშად გადართვა და ეტაპობრივი გაშვება

რისი გარანტია არ არის staging

staging-ზე ყველა შემოწმების გავლა ვერ იძლევა იმას, რომ DNS-ის გავრცელება, გარე ელფოსტა, მესამე მხარის API ან რეალური მომხმარებლის ყველა გზა ზუსტად იგივე იქნება. ტექნიკური გარემოს სხვაობა ცალკე უნდა აღინიშნოს. გადართვის შემდეგ crawl და ინდექსაცია შეიძლება დროში გაიწელოს.

runbook არ ცვლის ბიზნესის დამტკიცებას. თუ ფორმის მიმღები, ფასის ტექსტი, ენის ვერსია ან მფლობელობა გაურკვეველია, ტექნიკური დასრულება საკმარისი არ არის. aiWEB-ის მოვლისა და გადაცემის პირობები პროექტის ფარგლებში წინასწარ უნდა იყოს გარკვეული.

დაკავშირებული მასალა

• ძველი საიტის სამაშველო გეგმა
• SEO redirect ჩეკლისტი
• დომენისა და ჰოსტინგის კონტროლი
• ფორმებისა და მოთხოვნების ტესტი
• რედაქტორის გადაცემა
• კონტენტის აუდიტი
• aiWEB პროექტის განხილვა

<li><a href="https://developer.wordpress.org/advanced-administration/upgrade/migrating/">ოფიციალური დოკუმენტაცია: მიგრაცია</a></li>
<li><a href="https://developers.google.com/search/docs/crawling-indexing/301-redirects">ოფიციალური მითითება: მუდმივი გადამისამართება</a></li>
<li><a href="https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes">ოფიციალური მითითება: საიტის გადატანა</a></li></ul>

ხშირი კითხვები

რა განსხვავებაა staging-სა და ძველ საიტს შორის?

Staging არის ახალი ან შეცვლილი გარემოს საცდელი ასლი, სადაც ფუნქციებსა და კონტენტს ამოწმებთ. ძველი საიტი ამ დროს არსებული საჯარო წყაროა, სანამ cutover ოფიციალურად არ დასრულდება.

როდის უნდა გაიყინოს კონტენტი?

როცა staging-ზე დასამტკიცებელი ვერსია მზად არის და ბოლო ცვლილებების გადატანის წესი შეთანხმებულია. გაყინვის დრო და გამონაკლისები runbook-ში უნდა ჩაიწეროს.

რა შემთხვევაში უნდა დავბრუნდეთ ძველ საიტზე?

კრიტიკული ფორმის, ნავიგაციის, ავტორიზაციის, მონაცემის ან მთავარი URL-ის გაუმართაობისას, თუ პრობლემის სწრაფად გასწორება ვერ ხერხდება. ეს პირობა cutover-მდე უნდა იყოს შეთანხმებული.

ვინ იღებს გადართვის საბოლოო გადაწყვეტილებას?

წინასწარ დასახელებულმა პასუხისმგებელმა უნდა შეადაროს ტესტის მტკიცებულებები და მიღების პირობები. ტექნიკური შემსრულებელი შეიძლება დაეხმაროს, მაგრამ გადაწყვეტილების მფლობელი ბიზნესმა დაასახელოს.

გამჭვირვალობა: ეს მასალა AI-ის დახმარებით მომზადდა და წყაროები ცალკე მითითებულია. რეკომენდაციები ეყრდნობა WordPress-ისა და Google-ის საჯარო დოკუმენტაციას; კონკრეტული პროექტის staging გარემო და შეცდომის შემთხვევები ცალკე უნდა დადასტურდეს.

შემდეგი ნაბიჯი: შექმენით runbook ტესტის, DNS-ის, ფორმის, დაბრუნებისა და პასუხისმგებლების სვეტებით და შემდეგ განიხილეთ იგი aiWEB-ის გუნდთან.