როგორ დავაყენოთ სატესტო გარემო (staging) თქვენი აპისთვის

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

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

განვითარება, სატესტო და წარმოება

ბევრ პატარა აპს სამი ადგილი სჭირდება, თუნდაც პირველი მხოლოდ თქვენი ბილდერის გადახედვა იყოს:

სატესტო გარემოს აზრი ისაა, რომ ის წარმოების მსგავსად იქცევა — იგივე კოდი, იგივე სტეკი, იგივე ტიპის პარამეტრები — მაგრამ იქ შეცდომა არავის აზიანებს.

ნაბიჯი 1: განსაზღვრეთ, რა უნდა ემთხვეოდეს სატესტო გარემო

სატესტო გარემო მხოლოდ მაშინ სარგებლობს, თუ პრობლემები იქ წარმოებამდე ჩნდება. შეადარეთ:

• იგივე კოდი, გამოშვებული იგივე წესით.
• იგივე სტეკი და ვერსიები — ფრეიმვორკი, გაშვების გარემო, მონაცემთა ბაზის ტიპი.
• იგივე ტიპის კონფიგურაცია — იგივე გარემოს ცვლადების სახელები, სატესტო მნიშვნელობებით.
• იგივე სერვისები — თუ წარმოებას აქვს ვებ აპი და API, სატესტოსაც უნდა ჰქონდეს ორივე.

შეიძლება განსხვავდებოდეს ზომით (პატარა მანქანაც კარგია) და მონაცემებით.

ნაბიჯი 2: შექმენით ასლი

ყველაზე მარტივი მიდგომა: იმავე პროექტის მეორე დეპლოიმენტი სხვა URL-ზე, მაგალითად staging.yourapp.com ან yourapp-staging.example.com.

როგორ გააკეთებთ, დამოკიდებულია თქვენს ჰოსტზე:

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

ნაბიჯი 3: მიანიჭეთ სატესტოს საკუთარი მონაცემთა ბაზა

ეს არის ნაბიჯი, რომელიც გიცავთ. თუ სატესტო და წარმოება ერთ მონაცემთა ბაზას იზიარებს, ტესტი, რომელიც ჩანაწერებს შლის, რეალურ ჩანაწერებს შლის.

• შექმენით ცალკე მონაცემთა ბაზა სატესტოსთვის.
• შეავსეთ იგი seed მონაცემებით — რეალისტური, გამოგონილი ჩანაწერებით, რომელთაც AI შეგიქმნით.
• თუ წარმოების მონაცემების ასლი გჭირდებათ, ჯერ წაშალეთ ან აურიეთ სახელები, ელფოსტები და ყველაფერი პერსონალური.

დაწერე seed სკრიპტი, რომელიც ცარიელ მონაცემთა ბაზას რეალისტური სატესტო მონაცემებით შეავსებს: 20 მომხმარებელი, 50 შეკვეთა სხვადასხვა მდგომარეობაში და ორი ადმინისტრატორი. გამოიყენე აშკარად ყალბი სახელები და example.com ელფოსტის მისამართები.

სანამ სეტაპს ენდობით, დაადასტურეთ, რომელ მონაცემთა ბაზას უკავშირდება თითოეული ასლი. პირდაპირ ჰკითხეთ:

რომელ მონაცემთა ბაზას უკავშირდება ეს აპი და საიდან მოდის ეს პარამეტრი? მაჩვენე ცვლადის სახელი, არა პაროლი.

ნაბიჯი 4: გამოიყენეთ სატესტო გასაღებები და ცალკე პარამეტრები

ყველაფერმა, რაც გარე სერვისს ეხება, სატესტო გარემოში უნდა გამოიყენოს სატესტო ავტორიზაცია:

• გადახდები სატესტო რეჟიმში (მაგალითად Stripe-ის სატესტო გასაღებები), რომ არცერთი ნამდვილი ბარათი არ მოიხსნას.
• ელფოსტა იგზავნება sandbox-ში ან მხოლოდ თქვენს მისამართზე, რომ მომხმარებლებმა არასდროს მიიღონ სატესტო შეტყობინება.
• AI და სხვა ფასიანი API-ები ცალკე გასაღებით და დაბალი ხარჯვის ლიმიტით.
• Webhook-ები სატესტო URL-ზე მიმართეთ, და არა წარმოებაზე.

შეინარჩუნეთ ცვლადების სახელები ორივე გარემოში ერთნაირი და შეცვალეთ მხოლოდ მნიშვნელობები. ასე კოდს არ სჭირდება იმის ცოდნა, სად მუშაობს. მეტი ამის შესახებ იხილეთ როგორ შევინახოთ API გასაღებები უსაფრთხოდ.

ნაბიჯი 5: შეინახეთ სატესტო კერძო

სატესტო საჯარო არ უნდა იყოს:

• დააყენეთ შესვლის, პაროლის ან გუნდის ელფოსტების დაშვების სიის უკან.
• შეაჩერეთ საძიებო სისტემების ინდექსირება noindex მეტა-ტეგით ან X-Robots-Tag სათაურით.
• არ დააკავშიროთ იგი თქვენს საჯარო საიტთან.
• გაუკეთეთ განსხვავებული იერი — ფერადი „STAGING“ ბანერი ხელს უშლის არასწორ ჩანართში ტესტირებას.

დაამატე მკვეთრი ყვითელი ბანერი ყველა გვერდის ზემოთ წარწერით „STAGING — მხოლოდ სატესტო მონაცემები“, როცა APP_ENV გარემოს ცვლადი არის „staging“. ამ შემთხვევაში დაამატე ასევე noindex მეტა-ტეგი.

ნაბიჯი 6: შექმენით გამოშვების რუტინა

სატესტო გარემო მხოლოდ მაშინ გეხმარებათ, თუ მას ყოველთვის იყენებთ. მარტივი რუტინა:

1. შეიტანეთ ცვლილება განვითარებაში და შეამოწმეთ გადახედვაში.
2. გამოუშვით სატესტოზე.
3. გაიარეთ მთავარი პროცესები: რეგისტრაცია, შესვლა, მთავარი ფუნქცია, გადახდები, ყველაფერი, რაც ცვლილებამ შეეხო.
4. თუ რაიმე გაფუჭდა, გაასწორეთ და ხელახლა გამოუშვით სატესტოზე.
5. გამოაქვეყნეთ იგივე ვერსია წარმოებაზე.
6. სწრაფად შეამოწმეთ წარმოება — იგივე პროცესები, მოკლედ.

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

ნაბიჯი 7: მონაცემთა ბაზის ცვლილებებს ფრთხილად მოეკიდეთ

მონაცემთა ბაზის სტრუქტურის ცვლილებები — სვეტის დამატება, ცხრილის გადარქმევა — ის ადგილია, სადაც სატესტო გარემო განსაკუთრებით სარგებლობს.

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

მაგალითი მოთხოვნები

აგიხსენი, რა მოხდებოდა არსებულ მონაცემებს, თუ ამ მონაცემთა ბაზის ცვლილებას წარმოებაზე გავუშვებდით. წაიშლება ან გადაირქმევა რამე?

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

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

გავრცელებული შეცდომები

• საერთო მონაცემთა ბაზა. ყველაზე დამანგრეველი შეცდომა. სატესტოს ყოველთვის საკუთარი ბაზა უნდა ჰქონდეს.
• ნამდვილი გასაღებები სატესტოში. ნამდვილი ჩამოჭრები, ნამდვილი ელფოსტები ნამდვილ მომხმარებლებთან.
• სატესტო განსხვავდება წარმოებისგან. განსხვავებული ვერსიები ან პარამეტრები ნიშნავს, რომ სატესტო აღარ იჭერს პრობლემებს.
• საჯარო, ინდექსირებული სატესტო საიტი, რომელიც საძიებო შედეგებში თქვენს რეალურ საიტთან ერთად ჩნდება.
• სატესტოს გამოტოვება „პატარა“ ცვლილებებისთვის. პატარა ცვლილებებიც ანგრევს რაღაცას.
• არასწორ ჩანართში ტესტირება. ხილული ბანერი ამას აგვარებს.

ჩამონათვალი

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

სატესტო გარემო Mythex-ზე

Mythex-ის Publish-ს თითო აპზე ერთი ცოცხალი URL აქვს; ცალკე სატესტო გადამრთველი არ არსებობს. პრაქტიკულად ორი ვარიანტი გაქვთ:

• გადახედვა, როგორც გამოშვებამდე შემოწმება. ყოველი პროექტი მუშაობს კერძო ღრუბლოვან სამუშაო სივრცეში ცოცხალი Preview-ით. /test-ზე აგენტი მომხმარებლივით გადის მასში, ხოლო Share ბმული კლიენტს ან თანამშრომელს საშუალებას აძლევს, გადახედვა გამოქვეყნების გარეშე ნახოს. იხილეთ Preview და Code. ბევრი ინდივიდუალური პროექტისთვის ეს საკმარისია.
• მეორე პროექტი, როგორც სატესტო. Pro გეგმაზე პროექტი ექსპორტირდება და ახალ პროექტში შემოიტანება, მასს თავისი მონაცემთა ბაზა და სატესტო საიდუმლოებები მიენიჭება და საკუთარ slug-ზე გამოქვეყნდება. გამოუშვით მასზე, სანამ წარმოების პროექტს გამოაქვეყნებთ.

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

კითხვები