എന്താണ് സ്റ്റേജിംഗ് എൻവയോൺമെന്റ്? റിലീസിന് മുമ്പ് പരീക്ഷിക്കുക

സ്റ്റേജിംഗ് എൻവയോൺമെന്റ് എന്നത് നിങ്ങളുടെ ആപ്പിന്റെ സ്വകാര്യ പകർപ്പാണ്, ലൈവ് പതിപ്പിനോട് കഴിയുന്നത്ര അടുത്ത രീതിയിൽ ഒരുക്കിയത്. യഥാർത്ഥ ഉപയോക്താക്കൾ കാണുന്നതിന് മുമ്പ് മാറ്റങ്ങൾ ഇവിടെ പരീക്ഷിക്കുന്നു. ഇതിന് സ്വന്തം ഡാറ്റാബേസും ടെസ്റ്റ് ഡാറ്റയും ടെസ്റ്റ് API കീകളും ഉണ്ട്, അതിനാൽ ഇവിടെ തകർന്ന ഫീച്ചറോ മോശം ഡാറ്റാ മാറ്റമോ നിങ്ങളുടെ ടീമിന് പുറത്തുള്ള ആരെയും ബാധിക്കില്ല. സ്റ്റേജിംഗിൽ മാറ്റം ശരിയെന്ന് തോന്നിയാൽ അത് പ്രൊഡക്ഷനിലേക്ക് വിടുന്നു, അതായത് നിങ്ങളുടെ ഉപഭോക്താക്കൾ ഉപയോഗിക്കുന്ന ലൈവ് ആപ്പിലേക്ക്.

AI ഉപയോഗിച്ച് നിർമ്മിക്കുമ്പോൾ സ്റ്റേജിംഗ് പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്

AI ഉപയോഗിച്ച് നിർമ്മിക്കുമ്പോൾ മാറ്റങ്ങൾ വേഗത്തിലാണ്. ഒരു ഫീച്ചർ ചേർക്കാനോ ഒരു പേജ് എഴുതാനോ ഡാറ്റാ ഘടന മാറ്റാനോ മിനിറ്റുകൾ മതി. ചെക്ക്ഔട്ട് തകർക്കുന്ന മാറ്റം അല്ലെങ്കിൽ ഉപഭോക്താവിന്റെ ഡാറ്റാ കോളം മായ്ക്കുന്ന "ചെറിയ ക്ലീനപ്പ്" വരെ ഇത് ശ്രദ്ധിക്കപ്പെടാതെ പോകാം.

ലൈവ് ആകുന്നതിന് മുമ്പ് മാറ്റങ്ങൾ പരിശോധിക്കാനുള്ള ഒരിടം നിങ്ങളെ ഇവ ചെയ്യാൻ സഹായിക്കുന്നു:

• ഉപഭോക്താക്കൾ കണ്ടെത്തുന്നതിന് മുമ്പ് തകരാറുകൾ കണ്ടെത്തുക. ഓരോ പ്രധാന മാറ്റത്തിനു ശേഷവും സൈൻ-അപ്പ്, പേയ്മെന്റ്, കീ ഫ്ലോകൾ പരീക്ഷിക്കുക.
• യഥാർത്ഥ ലോക സെറ്റിംഗ്സിൽ പരീക്ഷിക്കുക. സ്റ്റേജിംഗ് പ്രൊഡക്ഷനെപ്പോലെ പെരുമാറണം, അതേ സ്റ്റാക്കും സമാനമായ കോൺഫിഗറേഷനും. അങ്ങനെ പ്രശ്നങ്ങൾ പിന്നീടല്ല, അവിടെ തന്നെ കാണാം.
• യഥാർത്ഥ ഡാറ്റ സംരക്ഷിക്കുക. ഡാറ്റാബേസ് മാറ്റങ്ങളും ഇമ്പോർട്ടുകളും ബൾക്ക് എഡിറ്റുകളും ആദ്യം ടെസ്റ്റ് ഡാറ്റയിൽ റിഹേഴ്സ് ചെയ്യാം.
• പുരോഗമിക്കുന്ന ജോലി കാണിക്കുക. ഒരു ക്ലയന്റിനോ സഹപ്രവർത്തകനോ മാറ്റം പൊതുവായി ആക്കാതെ തന്നെ അവലോകനം ചെയ്യാം.

ദൈനംദിന ഉപമ

ഒരു തിയേറ്ററിന്റെ ഡ്രസ് റിഹേഴ്സൽ ഓർക്കുക.

• ഡെവലപ്മെന്റ് റിഹേഴ്സൽ മുറിയാണ്: അഭിനേതാക്കൾ വരികൾ പരീക്ഷിക്കുന്നു, നിർത്തുന്നു, വീണ്ടും തുടങ്ങുന്നു, പരീക്ഷണം നടത്തുന്നു.
• സ്റ്റേജിംഗ് ഡ്രസ് റിഹേഴ്സലാണ്: പൂർണ്ണ വേഷവിധാനം, യഥാർത്ഥ വേദി, യഥാർത്ഥ ലൈറ്റുകൾ. ഉദ്ഘാടന രാത്രിയിൽ എല്ലാം എങ്ങനെയാകുമോ അതുപോലെ, പണം നൽകുന്ന കാണികൾ മാത്രമില്ല.
• പ്രൊഡക്ഷൻ ഉദ്ഘാടന രാത്രിയാണ്. തെറ്റുകൾ എല്ലാവരുടെയും മുന്നിൽ സംഭവിക്കുന്നു.

ഉദ്ഘാടന രാത്രിയിൽ കാണാൻ ആഗ്രഹിക്കാത്ത മിക്ക പ്രശ്നങ്ങളും ഡ്രസ് റിഹേഴ്സലിൽ കാണാം: വേഷം മാറ്റാൻ വളരെ സമയമെടുക്കുന്നത്, തെറ്റായ ലൈറ്റ് ക്യൂ. അതാണ് സ്റ്റേജിംഗിന്റെ ജോലി.

മൂന്ന് സാധാരണ എൻവയോൺമെന്റുകൾ

ഓരോ എൻവയോൺമെന്റും പ്രധാനമായും അതിന്റെ കോൺഫിഗറേഷനിൽ വ്യത്യസ്തമാണ്: ഏത് ഡാറ്റാബേസുമായി ബന്ധിപ്പിക്കുന്നു, ഏത് കീകൾ ഉപയോഗിക്കുന്നു, ഏത് URL-ൽ ഇരിക്കുന്നു. അതുകൊണ്ടാണ് നല്ല ആപ്പുകൾ ഈ സെറ്റിംഗ്സ് എൻവയോൺമെന്റ് വേരിയബിളുകളിൽ നിന്നും സീക്രട്ടുകളിൽ നിന്നും വായിക്കുന്നത്, കോഡിൽ നേരിട്ട് എഴുതുന്നതിനു പകരം. അങ്ങനെ ഒരേ കോഡ് ഓരോ എൻവയോൺമെന്റിലും വ്യത്യസ്ത സെറ്റിംഗ്സോടെ പ്രവർത്തിക്കും.

ഒരു ഉദാഹരണം: ഒരു ബുക്കിംഗ് ആപ്പിന്റെ റദ്ദാക്കൽ നിയമങ്ങൾ മാറ്റുന്നത്

പണം നൽകുന്ന ഉപഭോക്താക്കളുള്ള ഒരു സലൂൺ ബുക്കിംഗ് ആപ്പ് നിങ്ങൾ നടത്തുന്നു. 48 മണിക്കൂറിന് പകരം 24 മണിക്കൂർ മുമ്പ് വരെ റദ്ദാക്കാം, റീഫണ്ട് സ്വയമേവ ആകണം എന്ന നിയമം മാറ്റാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു.

1. ഡെവലപ്മെന്റിൽ നിർമ്മിക്കുക. മാറ്റത്തിനായി നിങ്ങൾ AI ബിൽഡറോട് ആവശ്യപ്പെടുന്നു. അത് റദ്ദാക്കൽ ലോജിക്കും പേയ്മെന്റ് ദാതാവിനുള്ള റീഫണ്ട് കോളും അപ്ഡേറ്റ് ചെയ്യുന്നു.

2. സ്റ്റേജിംഗിലേക്ക് റിലീസ് ചെയ്യുക. സ്റ്റേജിംഗ് ഇതേ കോഡ് പ്രവർത്തിപ്പിക്കുന്നു, സ്റ്റേജിംഗ് ഡാറ്റാബേസുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു, ടെസ്റ്റ് ബുക്കിംഗുകളോടെ, നിങ്ങളുടെ പേയ്മെന്റ് ദാതാവിന്റെ ടെസ്റ്റ് മോഡ് കീകളും ഉപയോഗിക്കുന്നു.

3. യഥാർത്ഥ ഫ്ലോകൾ പരീക്ഷിക്കുക. നിങ്ങളും ഒരു സഹപ്രവർത്തകനും ചേർന്ന്:

• നാളെത്തേക്ക് ഒരു ടെസ്റ്റ് അപ്പോയിന്റ്മെന്റ് ബുക്ക് ചെയ്ത് 30 മണിക്കൂർ മുമ്പ് റദ്ദാക്കുക. റീഫണ്ട് ലഭിക്കണം;
• 10 മണിക്കൂർ മുമ്പ് റദ്ദാക്കാൻ ശ്രമിക്കുക. വ്യക്തമായ സന്ദേശത്തോടെ നിരസിക്കപ്പെടണം;
• റീഫണ്ട് പേയ്മെന്റ് ദാതാവിന്റെ ടെസ്റ്റ് ഡാഷ്ബോർഡിൽ കാണുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക;
• സ്ഥിരീകരണ ഇമെയിൽ 48 അല്ല, 24 മണിക്കൂർ എന്ന് പറയുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക.

4. ബഗ് കണ്ടെത്തുക. സ്റ്റേജിംഗിൽ നിയമം സെർവറിന്റെ ടൈം സോൺ ഉപയോഗിക്കുന്നു, സലൂണിന്റേതല്ല എന്ന് നിങ്ങൾ ശ്രദ്ധിക്കുന്നു, അതിനാൽ കട്ട്-ഓഫ് ഒരു മണിക്കൂർ തെറ്റാണ്. നിങ്ങൾ അത് ശരിയാക്കി വീണ്ടും പരീക്ഷിക്കുന്നു.

5. പ്രൊഡക്ഷനിലേക്ക് റിലീസ് ചെയ്യുക. ഇപ്പോൾ മാത്രമാണ് മാറ്റം യഥാർത്ഥ ഉപഭോക്താക്കളിൽ എത്തുന്നത്, ടൈം-സോൺ ബഗ് നേരത്തെ പിടികൂടിയ ശേഷം.

സ്റ്റേജിംഗ് ഇല്ലായിരുന്നെങ്കിൽ, നാലാം ഘട്ടം ഒരു യഥാർത്ഥ ഉപഭോക്താവിന്റെ റീഫണ്ടിൽ സംഭവിക്കുമായിരുന്നു.

പ്രധാന പദങ്ങൾ

സാധാരണ തെറ്റിദ്ധാരണകൾ

• "സ്റ്റേജിംഗിന് പ്രൊഡക്ഷൻ ഡാറ്റാബേസ് പങ്കിടാം." ഇത് ഏറ്റവും അപകടകരമായ കുറുക്കുവഴിയാണ്. റെക്കോർഡുകൾ മായ്ക്കുകയോ തിരുത്തുകയോ ചെയ്യുന്ന ഒരു ടെസ്റ്റ് യഥാർത്ഥ ഉപഭോക്താക്കളെ ബാധിക്കും. സ്റ്റേജിംഗിന് സ്വന്തം ഡാറ്റാബേസ് നൽകുക.
• "സ്റ്റേജിംഗിൽ പ്രവർത്തിച്ചാൽ പ്രൊഡക്ഷനിൽ തകരില്ല." സ്റ്റേജിംഗ് റിസ്ക് കുറയ്ക്കുന്നു, ഇല്ലാതാക്കുന്നില്ല. യഥാർത്ഥ ട്രാഫിക്കും യഥാർത്ഥ ഡാറ്റയും പുറത്തുള്ള സേവനങ്ങളും ഇപ്പോഴും അത്ഭുതപ്പെടുത്താം. റോൾബാക്ക് ചെയ്യാനുള്ള ഒരു വഴി സൂക്ഷിക്കുക.
• "സ്റ്റേജിംഗ് ചെലവേറിയതായിരിക്കണം." ചെറുതാകാം. പ്രൊഡക്ഷന്റെ അതേ വലുപ്പമല്ല, അതേ സെറ്റപ്പാണ് വേണ്ടത്.
• "യാഥാർത്ഥ്യബോധത്തിനായി സ്റ്റേജിംഗിൽ ലൈവ് പേയ്മെന്റ് കീകൾ ഉപയോഗിക്കുക." ദാതാവിന്റെ ടെസ്റ്റ് മോഡ് ഉപയോഗിക്കുക. യാഥാർത്ഥ്യബോധം എന്നാൽ യഥാർത്ഥ പണമല്ല.
• "സ്റ്റേജിംഗ് വലിയ ടീമുകൾക്ക് മാത്രം." സുരക്ഷിതമായ ഒരിടത്ത് ആദ്യം പരീക്ഷിക്കുക എന്ന ആശയം ഒരാൾക്കും ഉപയോഗപ്രദമാണ്. ചടങ്ങുകളുടെ അളവ് പണയത്തിന്റെ വലുപ്പത്തിനനുസരിച്ച് മാറാം.
• "ആളുകൾക്ക് പരീക്ഷിക്കാൻ സ്റ്റേജിംഗ് പൊതുവായിരിക്കണം." സ്വകാര്യമോ സംരക്ഷിതമോ ആയി വെക്കുക, സെർച്ച് എഞ്ചിനുകൾ ഇൻഡെക്സ് ചെയ്യാതിരിക്കാൻ തടയുക, അങ്ങനെ ആരും അതിനെ യഥാർത്ഥ ആപ്പായി തെറ്റിദ്ധരിക്കില്ല.

നിങ്ങളുടെ AI ബിൽഡറിനോട് എന്ത് ചോദിക്കണം

• "ഡാറ്റാബേസ്, API കീകൾ, സൈറ്റ് URL എന്നിങ്ങനെ എൻവയോൺമെന്റ്-നിർദ്ദിഷ്ട എല്ലാ സെറ്റിംഗ്സും എൻവയോൺമെന്റ് വേരിയബിളുകളിൽ നിന്ന് വരട്ടെ."
• "പ്രൊഡക്ഷനല്ലാത്ത ഡാറ്റാബേസ് യാഥാർത്ഥ്യബോധമുള്ള ടെസ്റ്റ് ഡാറ്റയിൽ നിറയ്ക്കുന്ന ഒരു സീഡ് സ്ക്രിപ്റ്റ് ചേർക്കുക."
• "ഞങ്ങൾ ലോഞ്ച് ചെയ്യുന്നു എന്ന് ഞാൻ പറയുന്നതുവരെ പേയ്മെന്റ് ദാതാവിന്റെ ടെസ്റ്റ് മോഡ് ഉപയോഗിക്കുക."
• "ഈ മാറ്റം ലൈവ് ആകുന്നതിന് മുമ്പ്, ഞാൻ പരീക്ഷിക്കേണ്ട ഫ്ലോകളും ഓരോന്നിലും എന്ത് സംഭവിക്കണമെന്നും പട്ടികപ്പെടുത്തുക."
• "ഈ മാറ്റം നിലവിലുള്ള ഡാറ്റയെ ബാധിക്കുമോ? ആദ്യം മൈഗ്രേഷൻ കാണിക്കുക."
• "പ്രൊഡക്ഷനല്ലാത്ത സൈറ്റ് പകർപ്പുകൾ സെർച്ച് എഞ്ചിനുകൾ ഇൻഡെക്സ് ചെയ്യുന്നില്ലെന്ന് ഉറപ്പാക്കുക."

ഘട്ടം ഘട്ടമായുള്ള സെറ്റപ്പിനായി സ്റ്റേജിംഗ് എൻവയോൺമെന്റ് എങ്ങനെ സെറ്റ് ചെയ്യാം കാണുക. റിലീസുകൾ പതിവാകുമ്പോൾ, കോഡിൽ നിന്ന് സ്റ്റേജിംഗിലേക്കും പ്രൊഡക്ഷനിലേക്കുമുള്ള പാത ഓട്ടോമേറ്റ് ചെയ്യുന്നതാണ് CI/CD ചെയ്യുന്നത്.

Mythex-ൽ റിലീസിന് മുമ്പുള്ള പരീക്ഷണം

Mythex-ന് പ്രത്യേക "സ്റ്റേജിംഗ് vs പ്രൊഡക്ഷൻ" സ്വിച്ച് ഇല്ല. പ്രസിദ്ധീകരിക്കുമ്പോൾ ഒരു ലൈവ് പൊതു URL ലഭിക്കുന്നു, ഡോക്സ് ഇത് വ്യക്തമായി പറയുന്നുണ്ട് (മൾട്ടി-സർവീസ് ആപ്പുകൾ). എന്നാൽ നിർമ്മാണവും ലൈവ് ആകലും തമ്മിൽ വ്യക്തമായ വേർതിരിവ് ഇത് നൽകുന്നു:

• പ്രിവ്യൂ നിങ്ങൾ നിർമ്മിക്കുമ്പോൾ ആപ്പ് ഒരു സ്വകാര്യ ക്ലൗഡ് സാൻഡ്ബോക്സിൽ പ്രവർത്തിപ്പിക്കുന്നു. മാറ്റങ്ങൾ ആദ്യം അവിടെയാണ് കാണുന്നത്, ലൈവ് ആപ്പിൽ അല്ല.
• ഷെയർ ഒരു ക്ലയന്റിനോ സഹപ്രവർത്തകനോ Mythex അക്കൗണ്ടില്ലാതെ, നിങ്ങൾ പ്രസിദ്ധീകരിക്കാതെ തന്നെ പുരോഗമിക്കുന്ന ജോലി അവലോകനം ചെയ്യാൻ പ്രിവ്യൂ ലിങ്കുകൾ ഉണ്ടാക്കുന്നു. ലിങ്ക് സാൻഡ്ബോക്സ് ഇപ്പോൾ ഉള്ളതുപോലെ കാണിക്കുന്നു, നിർമ്മാണത്തിനിടയിലെ മാറ്റങ്ങളും ഉൾപ്പെടെ. നിങ്ങൾക്ക് എപ്പോൾ വേണമെങ്കിലും അത് ഇല്ലാതാക്കാം.
• പ്രസിദ്ധീകരിക്കൽ പ്രോജക്റ്റിന്റെ സ്നാപ്പ്ഷോട്ടെടുത്ത് ഡിപ്ലോയ് ചെയ്യുന്നു. വീണ്ടും പ്രസിദ്ധീകരിക്കുന്നതുവരെ ലൈവ് ആപ്പ് മുമ്പുള്ള പോലെ തുടരുന്നു.
• ചെക്ക്പോയിന്റുകൾ ഏജന്റിന്റെ ഓരോ വിജയകരമായ ടേണിന് ശേഷവും സേവ് ചെയ്യുന്നു, അതിനാൽ ഒരു മാറ്റം തെറ്റിയാൽ പ്രോജക്റ്റ് ഫയലുകൾ തിരികെ കൊണ്ടുവരാം.

പ്രിവ്യൂയെ നിങ്ങളുടെ റിഹേഴ്സലായി കാണുക: ലോഞ്ച് വരെ പേയ്മെന്റ് ദാതാക്കളെ ടെസ്റ്റ് മോഡിൽ സൂക്ഷിക്കുക, ഓരോ പ്രസിദ്ധീകരണത്തിനു മുമ്പും പ്രധാന ഫ്ലോകൾ പരീക്ഷിക്കുക. യഥാർത്ഥ ഉപഭോക്താക്കൾ വന്നാൽ, ഡാറ്റ എഴുതുന്നതോ മായ്ക്കുന്നതോ ആയ എന്തും പരീക്ഷിക്കുന്നതിന് മുമ്പ് നിങ്ങളുടെ പ്രിവ്യൂ ഏത് ഡാറ്റാബേസും കീകളും ഉപയോഗിക്കുന്നു എന്ന് ഏജന്റിനോട് ചോദിച്ച് ഉറപ്പാക്കുക. നിങ്ങളുടെ സ്വന്തം ഡാറ്റാബേസോടെ പൂർണ്ണമായി വേർതിരിച്ച സ്റ്റേജിംഗ് സെറ്റപ്പ് വേണമെങ്കിൽ, നിങ്ങളുടെ പ്രോജക്റ്റിനുള്ള ഓപ്ഷനുകൾ വിശദീകരിക്കാൻ ഏജന്റിനോട് ആവശ്യപ്പെടുക, അല്ലെങ്കിൽ Pro-യിൽ പ്രോജക്റ്റ് എക്സ്പോർട്ട് ചെയ്യുക അല്ലെങ്കിൽ GitHub-മായി സിങ്ക് ചെയ്ത് നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഇൻഫ്രാസ്ട്രക്ചറിൽ പ്രവർത്തിപ്പിക്കുക.

ചോദ്യങ്ങൾ