તમારી એપ માટે સ્ટેજિંગ એન્વાયર્નમેન્ટ કેવી રીતે સેટ કરવું

સ્ટેજિંગ એન્વાયર્નમેન્ટ સેટ કરવા માટે, તમારી એપની બીજી નકલ તેના પોતાના ખાનગી URL પર ડિપ્લોય કરો, તેને પોતાનો ડેટાબેઝ અને ટેસ્ટ API કી આપો, અને તેનું સેટઅપ પ્રોડક્શન સાથે શક્ય તેટલું મેળ ખાય તેવું બનાવો. પછી દરેક મહત્વપૂર્ણ ફેરફાર પહેલાં સ્ટેજિંગ પર રિલીઝ કરો, મહત્વના ફ્લો ચલાવો, અને સ્ટેજિંગ બરાબર લાગે ત્યારે જ પ્રોડક્શન પર પ્રકાશિત કરો.

જો આ વિચાર તમારા માટે નવો છે, તો સ્ટેજિંગ એન્વાયર્નમેન્ટ શું છે ખ્યાલ સમજાવે છે. આ માર્ગદર્શિકા વ્યવહારુ સેટઅપ છે, જે DevOps ટીમ ચલાવનારા માટે નહીં પણ AI ટૂલ્સ વડે બનાવનારા લોકો માટે લખાઈ છે.

ડેવ, સ્ટેજિંગ અને પ્રોડક્શન

મોટાભાગની નાની એપને ત્રણ જગ્યાઓની જરૂર પડે છે, ભલે પહેલી તમારા બિલ્ડરનો પ્રિવ્યૂ જ હોય:

સ્ટેજિંગનો મુદ્દો એ છે કે તે પ્રોડક્શન જેવું વર્તે — એ જ કોડ, એ જ સ્ટેક, એ જ પ્રકારની સેટિંગ્સ — પરંતુ ત્યાંની ભૂલથી કોઈને નુકસાન ન થાય.

પગલું 1: નક્કી કરો કે સ્ટેજિંગે શું મેળ ખાવું જોઈએ

સ્ટેજિંગ ત્યારે જ ઉપયોગી છે જ્યારે સમસ્યાઓ પ્રોડક્શનમાં દેખાય તે પહેલાં ત્યાં દેખાય. આ મેળ ખાવું જોઈએ:

• એ જ કોડ, એ જ રીતે રિલીઝ થયેલો.
• એ જ સ્ટેક અને વર્ઝન — ફ્રેમવર્ક, રનટાઇમ, ડેટાબેઝનો પ્રકાર.
• એ જ પ્રકારનું કોન્ફિગરેશન — એ જ એન્વાયર્નમેન્ટ વેરિયેબલના નામ, ટેસ્ટ મૂલ્યો સાથે.
• એ જ સર્વિસ — જો પ્રોડક્શનમાં વેબ એપ અને API છે, તો સ્ટેજિંગમાં બંને હોવાં જોઈએ.

કદ (નાનું મશીન ચાલે) અને ડેટામાં તે જુદું હોઈ શકે.

પગલું 2: નકલ બનાવો

સૌથી સરળ રીત: એ જ પ્રોજેક્ટનું બીજું ડિપ્લોયમેન્ટ, જુદા URL પર, જેમ કે staging.yourapp.com અથવા yourapp-staging.example.com.

તમે આ કેવી રીતે કરો તે તમારા હોસ્ટ પર આધારિત છે:

• બિલ્ટ-ઇન પ્રિવ્યૂ અથવા સ્ટેજિંગ ડિપ્લોયમેન્ટવાળા હોસ્ટ Git બ્રાન્ચ માટે આપમેળે એક બનાવી શકે છે.
• એવા હોસ્ટ જેમાં ન હોય: એ જ કોડમાંથી બીજી એપ કે પ્રોજેક્ટ બનાવો, અને તેને અલગ ડિપ્લોય કરો.
• Git માં કોડ: એક staging અથવા main બ્રાન્ચ રાખો જે સ્ટેજિંગ પર ડિપ્લોય થાય, અને રિલીઝમાંથી પ્રોડક્શન પર ડિપ્લોય કરો. AI વડે બનાવેલી એપ સાથે Git કેવી રીતે વાપરવું જુઓ.

પગલું 3: સ્ટેજિંગને પોતાનો ડેટાબેઝ આપો

આ તે પગલું છે જે તમને બચાવે છે. જો સ્ટેજિંગ અને પ્રોડક્શન ડેટાબેઝ વહેંચે, તો રેકોર્ડ ડિલીટ કરતી ટેસ્ટ વાસ્તવિક રેકોર્ડ ડિલીટ કરી દે છે.

• સ્ટેજિંગ માટે અલગ ડેટાબેઝ બનાવો.
• તેને સીડ ડેટા થી ભરો — વાસ્તવિક લાગતા નકલી રેકોર્ડ જે AI તમારા માટે બનાવી શકે.
• જો તમને પ્રોડક્શન ડેટાની નકલ જોઈએ, તો પહેલાં નામો, ઇમેઇલ અને વ્યક્તિગત હોય તે બધું દૂર કરો અથવા ભેળવી દો.

એક સીડ સ્ક્રિપ્ટ લખો જે ખાલી ડેટાબેઝને વાસ્તવિક ટેસ્ટ ડેટાથી ભરે: 20 ગ્રાહકો, અલગ અલગ સ્થિતિમાં 50 ઓર્ડર, અને બે એડમિન વપરાશકર્તા. સ્પષ્ટપણે નકલી નામો અને example.com ઇમેઇલ સરનામાં વાપરો.

સેટઅપ પર ભરોસો કરતાં પહેલાં, ચકાસો કે દરેક નકલ કયા ડેટાબેઝ સાથે જોડાય છે. સીધો પ્રશ્ન પૂછો:

આ એપ કયા ડેટાબેઝ સાથે જોડાય છે, અને તે સેટિંગ ક્યાંથી આવે છે? મને પાસવર્ડ નહીં, વેરિયેબલનું નામ બતાવો.

પગલું 4: ટેસ્ટ કી અને અલગ સેટિંગ્સ વાપરો

બહારની કોઈ પણ સેવા સાથે વાત કરતી દરેક વસ્તુએ સ્ટેજિંગમાં ટેસ્ટ ક્રેડેન્શિયલ વાપરવા જોઈએ:

• પેમેન્ટ ટેસ્ટ મોડમાં (દાખલા તરીકે Stripe ટેસ્ટ કી), જેથી કોઈ વાસ્તવિક કાર્ડ ચાર્જ ન થાય.
• ઇમેઇલ સેન્ડબોક્સ પર અથવા ફક્ત તમારા પોતાના સરનામા પર મોકલાય, જેથી ગ્રાહકોને ક્યારેય ટેસ્ટ સંદેશ ન મળે.
• AI અને અન્ય પેઇડ API અલગ કી અને ઓછી ખર્ચ મર્યાદા સાથે.
• વેબહૂક સ્ટેજિંગ URL પર ચીંધાયેલા, પ્રોડક્શન પર નહીં.

બંને એન્વાયર્નમેન્ટમાં વેરિયેબલના નામ એ જ રાખો અને માત્ર મૂલ્યો બદલો. આ રીતે કોડને ખબર પડવાની જરૂર નથી કે તે ક્યાં ચાલી રહ્યો છે. આ વિશે વધુ માટે, API કી સુરક્ષિત કેવી રીતે રાખવી જુઓ.

પગલું 5: સ્ટેજિંગને ખાનગી રાખો

સ્ટેજિંગ જાહેર ન હોવું જોઈએ:

• તેને લૉગિન, પાસવર્ડ, અથવા ટીમના ઇમેઇલની allow-list પાછળ રાખો.
• noindex મેટા ટૅગ અથવા X-Robots-Tag હેડર વડે સર્ચ એન્જિનને તેને ઇન્ડેક્સ કરતાં રોકો.
• તમારી પબ્લિક સાઇટ પરથી તેની લિંક ન આપો.
• તેને અલગ દેખાડો — રંગીન "STAGING" બેનર ખોટી ટેબમાં ટેસ્ટ થતું અટકાવે છે.

જ્યારે APP_ENV એન્વાયર્નમેન્ટ વેરિયેબલ "staging" હોય ત્યારે દરેક પેજની ટોચ પર એક તેજસ્વી પીળો બેનર ઉમેરો જેમાં લખ્યું હોય "STAGING — માત્ર ટેસ્ટ ડેટા". તે કિસ્સામાં noindex મેટા ટૅગ પણ ઉમેરો.

પગલું 6: રિલીઝનું રૂટિન બનાવો

સ્ટેજિંગ ત્યારે જ મદદ કરે જ્યારે તમે તેનો દરેક વખતે ઉપયોગ કરો. એક સરળ રૂટિન:

1. ડેવલપમેન્ટમાં ફેરફાર કરો અને પ્રિવ્યૂમાં તપાસો.
2. તેને સ્ટેજિંગ પર રિલીઝ કરો.
3. તમારા મુખ્ય ફ્લો ચલાવો: સાઇન અપ, લૉગ ઇન, મુખ્ય ફીચર, પેમેન્ટ, ફેરફારે જે કંઈ સ્પર્શ્યું હોય તે.
4. કંઈ તૂટે તો ઠીક કરો અને ફરી સ્ટેજિંગ પર રિલીઝ કરો.
5. એ જ વર્ઝન પ્રોડક્શન પર પ્રકાશિત કરો.
6. પ્રોડક્શન ઝડપથી તપાસો — એ જ ફ્લો, સંક્ષિપ્તમાં.

મુખ્ય ફ્લો ટૂંકી ટેસ્ટ સ્ક્રિપ્ટ તરીકે લખી રાખો. શું સમાવવું તે માટે લૉન્ચ પહેલાં તમારી એપ કેવી રીતે ટેસ્ટ કરવી જુઓ.

પગલું 7: ડેટાબેઝના ફેરફારો કાળજીથી સંભાળો

ડેટાબેઝના માળખામાં ફેરફારો — કૉલમ ઉમેરવી, ટેબલનું નામ બદલવું — એ જગ્યા છે જ્યાં સ્ટેજિંગ પોતાનું મૂલ્ય સાબિત કરે છે.

• દરેક સ્ટ્રક્ચરલ ફેરફાર પહેલાં સ્ટેજિંગ પર ચલાવો.
• ફક્ત નવી સુવિધાઓ કામ કરે છે એટલું નહીં, હાલનો ડેટા બચ્યો કે નહીં તે તપાસો.
• પ્રોડક્શન પર એ જ ફેરફાર ચલાવતાં પહેલાં તેનો બેકઅપ લો. તમારી એપના ડેટાબેઝનો બેકઅપ કેવી રીતે લેવો જુઓ.
• નામ બદલવા કે ડિલીટ કરવાને બદલે ઉમેરતા ફેરફારો પસંદ કરો, જેથી રોલબેક કરો તો જૂનું વર્ઝન હજી કામ કરે.

ઉદાહરણ પ્રોમ્પ્ટ

જો આ ડેટાબેઝ ફેરફાર પ્રોડક્શન પર ચલાવીએ તો હાલના ડેટાનું શું થાય તે સમજાવો. શું કંઈ ડિલીટ કે નામ બદલાય છે?

એન્વાયર્નમેન્ટ-વિશિષ્ટ બધી સેટિંગ્સ — API URL, કી, ઇમેઇલ મોકલનાર, સાઇટનો પોતાનો URL — સ્ટેજિંગ અને પ્રોડક્શનમાં એ જ નામના એન્વાયર્નમેન્ટ વેરિયેબલમાંથી આવે તેવી બનાવો. તેમની યાદી આપો.

આ એપ શું કરે છે તેના આધારે, દરેક રિલીઝ પહેલાં સ્ટેજિંગ પર મારે કયા ફ્લો ટેસ્ટ કરવા જોઈએ તેની ટૂંકી ચેકલિસ્ટ લખો.

સામાન્ય ભૂલો

• વહેંચાયેલો ડેટાબેઝ. સૌથી નુકસાનકારક ભૂલ. સ્ટેજિંગને હંમેશાં પોતાનો ડેટાબેઝ મળે.
• સ્ટેજિંગમાં લાઇવ કી. વાસ્તવિક ચાર્જ, વાસ્તવિક ગ્રાહકોને વાસ્તવિક ઇમેઇલ.
• સ્ટેજિંગ પ્રોડક્શનથી દૂર થઈ જાય. જુદાં વર્ઝન કે સેટિંગ્સનો અર્થ છે કે સ્ટેજિંગ સમસ્યાઓ પકડવાનું બંધ કરે છે.
• જાહેર, ઇન્ડેક્સ થયેલી સ્ટેજિંગ સાઇટ જે તમારી વાસ્તવિક સાઇટ સાથે સર્ચ પરિણામોમાં દેખાય.
• "નાના" ફેરફારો માટે સ્ટેજિંગ છોડવું. નાના ફેરફારો પણ વસ્તુઓ તોડે છે.
• ખોટી ટેબમાં ટેસ્ટિંગ. દેખાતો બેનર આ ઠીક કરે છે.

ચેકલિસ્ટ

• સ્ટેજિંગ પ્રોડક્શન જેવો જ કોડ, સ્ટેક અને સર્વિસ ચલાવે છે.
• સ્ટેજિંગ પાસે ટેસ્ટ અથવા સ્ક્રબ કરેલા ડેટા સાથે પોતાનો ડેટાબેઝ છે.
• પેમેન્ટ, ઇમેઇલ અને પેઇડ API સ્ટેજિંગમાં ટેસ્ટ કી વાપરે છે.
• એન્વાયર્નમેન્ટમાં વેરિયેબલના નામ મેળ ખાય છે; માત્ર મૂલ્યો જુદાં છે.
• સ્ટેજિંગ લૉગિન કે પાસવર્ડ પાછળ છે અને ઇન્ડેક્સ થતું નથી.
• જ્યારે તમે સ્ટેજિંગ પર હો ત્યારે બેનર દેખાય છે.
• દરેક રિલીઝ પહેલાં સ્ટેજિંગ પર જાય છે, લખેલી તપાસ-ફ્લો યાદી સાથે.
• ડેટાબેઝના ફેરફારો પહેલાં સ્ટેજિંગ પર ચાલે છે, રિલીઝ પહેલાં પ્રોડક્શન બેકઅપ સાથે.

Mythex પર સ્ટેજિંગ

Mythex નું Publish તમને દરેક એપ માટે એક લાઇવ URL આપે છે; અલગ સ્ટેજિંગ ટૉગલ નથી. વ્યવહારમાં તમારી પાસે બે વિકલ્પ છે:

• પ્રિ-રિલીઝ ચકાસણી તરીકે પ્રિવ્યૂ. દરેક પ્રોજેક્ટ લાઇવ Preview સાથે ખાનગી ક્લાઉડ વર્કસ્પેસમાં ચાલે છે. /test એજન્ટને વપરાશકર્તાની જેમ તેના પર ક્લિક કરાવે છે, અને Share લિંક ક્લાયન્ટ કે ટીમના સાથીને પ્રકાશિત કર્યા વગર પ્રિવ્યૂ રિવ્યૂ કરવા દે છે. Preview and Code જુઓ. ઘણા એકલા પ્રોજેક્ટ માટે આ પૂરતું છે.
• સ્ટેજિંગ તરીકે બીજો પ્રોજેક્ટ. Pro પર, પ્રોજેક્ટ એક્સપોર્ટ કરો અને નવા પ્રોજેક્ટમાં ઇમ્પોર્ટ કરો, તેને પોતાનો ડેટાબેઝ અને ટેસ્ટ-કી સિક્રેટ આપો, અને તેને પોતાના સ્લગ પર પ્રકાશિત કરો. પ્રોડક્શન પ્રોજેક્ટ પ્રકાશિત કરતાં પહેલાં તેના પર રિલીઝ કરો.

બંને રીતે, કંઈ પણ વિનાશક ટેસ્ટ કરતાં પહેલાં એજન્ટને પૂછો કે પ્રિવ્યૂ અને પ્રકાશિત એપ કયો ડેટાબેઝ વાપરે છે, અને ખરાબ ફેરફારને રોલબેક કરવા ચેકપોઇન્ટ વાપરો. એપને વ્યાપક રીતે લાઇવ કરવા માટે, AI પ્રોટોટાઇપને પ્રોડક્શન સુધી કેવી રીતે લઈ જવો જુઓ.

પ્રશ્નો