Аппдаа staging орчин хэрхэн тохируулах вэ

Staging орчин тохируулахын тулд аппынхаа хоёр дахь хуулбарыг өөрийн хувийн URL дээр deploy хийж, түүнд өөрийн өгөгдлийн сан болон туршилтын API түлхүүр өг, мөн production-ийн тохиргоотой аль болох адил байлга. Дараа нь чухал өөрчлөлт бүрийг эхлээд staging руу гарга, гол урсгалуудаар нь явж, staging зөв харагдсаны дараа л production руу нийтэл.

Хэрэв энэ санаа танд шинэ бол staging орчин гэж юу вэ гэдгийг тайлбарласан. Энэ гарын авлага бол практик тохиргоо, DevOps баг ажиллуулдаггүй, AI хэрэгслээр бүтээж буй хүмүүст зориулсан.

Dev, staging ба production

Ихэнх жижиг апп гурван газар хэрэгтэй, эхнийх нь зөвхөн таны builder-ийн preview байсан ч гэсэн:

Staging-ийн зорилго бол production шиг ажиллах явдал — ижил код, ижил стек, ижил төрлийн тохиргоо — гэхдээ тэнд гарсан алдаа хэнд ч хор хүргэхгүй.

Алхам 1: Staging юунтай таарах ёстойг шийдэх

Staging нь асуудлууд production дээр гарахаас өмнө тэнд гарч байвал л ашигтай. Дараах зүйлсийг таарга:

• Ижил код, ижил аргаар гаргасан.
• Ижил стек ба хувилбарууд — framework, runtime, өгөгдлийн сангийн төрөл.
• Ижил төрлийн тохиргоо — орчны хувьсагчийн ижил нэрүүд, туршилтын утгуудтай.
• Ижил үйлчилгээнүүд — production-д web апп болон API байвал staging-д хоёулаа байна.

Хэмжээгээрээ ялгаатай байж болно (жижиг машин зүгээр) мөн өгөгдлөөрөө.

Алхам 2: Хуулбар үүсгэх

Хамгийн энгийн арга: ижил төслийн хоёр дахь deployment-ийг staging.yourapp.com эсвэл yourapp-staging.example.com зэрэг өөр URL дээр.

Энэ нь таны host-оос хамаарна:

• Built-in preview эсвэл staging deployment-тэй host-ууд Git branch-д зориулж автоматаар үүсгэж болно.
• Ийм байхгүй host-ууд: ижил кодоос хоёр дахь апп эсвэл төсөл үүсгээд, тусад нь deploy хийнэ.
• Git дээрх код: staging эсвэл main branch-ийг staging руу deploy хийдэг байлга, production-ийг release-ээс deploy хийнэ. AI-ээр бүтээсэн аппд Git хэрхэн ашиглах вэ-ийг үзнэ үү.

Алхам 3: Staging-д өөрийн өгөгдлийн сан өг

Энэ бол таныг хамгаалдаг алхам. Хэрэв staging болон production нэг өгөгдлийн сан хуваалцвал өгөгдөл устгадаг туршилт жинхэнэ бичлэгүүдийг устгана.

• Staging-д тусдаа өгөгдлийн сан үүсгэ.
• Үүнийг seed өгөгдөл-өөр дүүргэ — AI-д таны төлөө үүсгэж болох бодит мэт хуурамч бичлэгүүд.
• Production-ийн өгөгдлийн хуулбар хэрэгтэй бол эхлээд нэр, имэйл болон хувийн бусад зүйлсийг арилгах эсвэл холих.

Хоосон өгөгдлийн санг бодит туршилтын өгөгдлөөр дүүргэх seed script бич: 20 харилцагч, төлөв өөр 50 захиалга, хоёр admin хэрэглэгч. Гаж харагдахгүй хуурамч нэр, example.com имэйл хаяг ашигла.

Тохиргоонд итгэхээсээ өмнө хуулбар бүр аль өгөгдлийн санд холбогдож байгааг баталга. Шууд асуу:

Энэ апп аль өгөгдлийн санд холбогдож байгаа вэ, тэр тохиргоо хаанаас ирж байна вэ? Нууц үгийг биш, хувьсагчийн нэрийг харуул.

Алхам 4: Туршилтын түлхүүр ба тусдаа тохиргоо ашиглах

Гадны үйлчилгээтэй холбогддог бүх зүйл staging-д туршилтын итгэмжлэлийг ашиглах ёстой:

• Төлбөр туршилтын горимд (жишээ нь Stripe test key), ингэснээр жинхэнэ карт тооцогдохгүй.
• Имэйл sandbox руу эсвэл зөвхөн өөрийн хаяг руу, ингэснээр хэрэглэгчид туршилтын мессеж хэзээ ч авахгүй.
• AI болон бусад төлбөртэй API тусдаа түлхүүр, бага зарцуулалтын хязгаартай.
• Webhook-ууд production биш staging URL руу чиглэсэн.

Хоёр орчинд хувьсагчийн нэрсийг ижил байлгаж, зөвхөн утгыг нь солиорой. Ингэснээр код хаана ажиллаж байгааг мэдэх шаардлагагүй. Үүний талаар дэлгэрэнгүйг API түлхүүрээ хэрхэн хамгаалах вэ-аас үзнэ үү.

Алхам 5: Staging-ээ хувийн байлга

Staging нийтэд нээлттэй байх ёсгүй:

• Нэвтрэлт, нууц үг, эсвэл багийн имэйлийн зөвшөөрөгдсөн жагсаалтын ард байрлуул.
• noindex meta tag эсвэл X-Robots-Tag header-ээр хайлтын системд индекслэхээс сэргийлэ.
• Нийтийн сайтаасаа түүн рүү линк бүү хий.
• Өөр харагдуулаарай — өнгөт «STAGING» баннер нь буруу таб дээр туршихаас сэргийлнэ.

APP_ENV орчны хувьсагч «staging» байх үед хуудас бүрийн дээд талд «STAGING — зөвхөн туршилтын өгөгдөл» гэсэн тод шар баннер нэм. Мөн тэр тохиолдолд noindex meta tag нэм.

Алхам 6: Гаргах дэг журам бий болгох

Staging нь бүр мөсөн ашигласан үед л тусалдаг. Энгийн дэг журам:

1. Өөрчлөлтөө development дээр хийж, preview-д шалга.
2. Staging руу гарга.
3. Гол урсгалуудаар явах: бүртгүүлэх, нэвтрэх, гол функц, төлбөр, өөрчлөлтийн хүрсэн бүх зүйл.
4. Хэрэв юу нэгэн зүйл эвдэрвэл засаад дахин staging руу гарга.
5. Ижил хувилбарыг production руу нийтэл.
6. Production-аа хурдан шалга — ижил урсгалууд, товчхон.

Гол урсгалуудаа богино туршилтын скрипт болгон бич. Юуг оруулах вэ гэдгийг аппаа launch-ийн өмнө хэрхэн турших вэ-аас үзнэ үү.

Алхам 7: Өгөгдлийн сангийн өөрчлөлтийг болгоомжтой зохицуул

Өгөгдлийн санг бүтцийн өөрчлөлт — багана нэмэх, хүснэгтийн нэр солих — нь staging-ийн үнэ цэнэ илэрдэг газар юм.

• Бүх бүтцийн өөрчлөлтийг эхлээд staging дээр хийгээрэй.
• Шинэ функц ажиллаж байгаа эсэхээс гадна одоо байгаа өгөгдөл амьд үлдсэнийг шалга.
• Ижил өөрчлөлтийг production дээр хийхээсээ өмнө production-ий нөөц хуулбар авах. Аппынхаа өгөгдлийн санг хэрхэн нөөцлөх вэ-ийг үзнэ үү.
• Нэр солих эсвэл устгахаас илүү нэмэх өөрчлөлтийг илүүд үз, ингэснээр буцаах үед хуучин хувилбар хэвээр ажиллана.

Жишээ подсказууд

Энэ өгөгдлийн сангийн өөрчлөлтийг production дээр ажиллуулбал одоо байгаа өгөгдөлд юу болох вэ? Ямар нэг зүйл устгагдах эсвэл нэр солигдох уу?

API URL, түлхүүр, имэйл илгээгч, сайтын өөрийн URL зэрэг орчинтой холбоотой бүх тохиргоог staging болон production дээр ижил нэртэй орчны хувьсагчаас авдаг болго. Жагсаа.

Энэ аппын юу хийдгээс харуулан, гаргах бүрийн өмнө staging дээр туршиж мөн шалгах урсгалуудын товч чеклист бич.

Түгээмэл алдаанууд

• Хуваалцсан өгөгдлийн сан. Хамгийн их хохирол учруулдаг алдаа. Staging үргэлж өөрийн санг авдаг.
• Staging дээр жинхэнэ түлхүүр. Жинхэнэ төлбөр, бодит хэрэглэгчдэд жинхэнэ имэйл.
• Staging production-аас холдох. Өөр хувилбар эсвэл тохиргоо нь staging асуудлыг барихаа больдог.
• Нийтэд нээлттэй, индекслэгдсэн staging сайт, таны жинхэнэ сайтын хажууд хайлтын үр дүнд гарч ирдэг.
• «Жижиг» өөрчлөлтөд staging-ийг алгасах. Жижиг өөрчлөлт ч бас эвдэрдэг.
• Буруу таб дээр туршилт хийх. Харагдах баннер үүнийг засдаг.

Чеклист

• Staging нь production-тай ижил код, стек, үйлчилгээгээр ажилладаг.
• Staging-д туршилтын эсвэл цэвэрлэсэн өгөгдөлтэй өөрийн өгөгдлийн сан байдаг.
• Төлбөр, имэйл, төлбөртэй API нь staging-д туршилтын түлхүүр ашигладаг.
• Орчин бүрт хувьсагчийн нэрүүд таарч, зөвхөн утгууд нь ялгаатай.
• Staging нь нэвтрэлт эсвэл нууц үгийн ард байж, индекслэгддэггүй.
• Staging дээр байгаа үед баннер харагддаг.
• Гаргах бүр эхлээд staging руу, шалгах урсгалуудын бичгэн жагсаалттай очдог.
• Өгөгдлийн сангийн өөрчлөлтүүд эхлээд staging дээр, гаргахаас өмнө production-ийн нөөцтэй.

Mythex дээрх staging

Mythex-ийн Publish нь апп бүрт нэг л live URL өгдөг; тусдаа staging товчлуур байхгүй. Практикт танд хоёр сонголт байна:

• Preview-г гаргахын өмнөх шалгалт болгон ашиглах. Төсөл бүр хувийн cloud workspace дээр live Preview-тэй ажилладаг. /test дээр агент хэрэглэгчийн адил дарааллаар дарж шалгана, мөн Share линкээр үйлчлүүлэгч эсвэл хамт ажиллагч нийтлэлгүйгээр preview-г хянаж болно. Preview and Code-ийг үзнэ үү. Олон ганц төслийн хувьд энэ хангалттай.
• Хоёр дахь төслийг staging болгон ашиглах. Pro дээр төслөө экспортлоод шинэ төсөлд импортлож, тэр төсөлд өөрийн өгөгдлийн сан болон туршилтын түлхүүрийн нууцуудыг өг, мөн өөрийн slug дээр нийтэл. Production төслөө нийтлэхээсээ өмнө үүн рүү гаргаарай.

Аль ч тохиолдолд, ямар нэг устгах туршилт хийхээс өмнө агентаас preview болон нийтлэгдсэн апп аль өгөгдлийн санг ашигладагийг асуу, муу өөрчлөлтийг буцаахын тулд checkpoint ашигла. Аппаа илүү өргөн хүрээнд live болгох талаар AI прототипыг production руу хэрхэн гаргах вэ-аас үзнэ үү.

Асуултууд