നിങ്ങളുടെ ആപ്പിനായി സ്റ്റേജിംഗ് എൻവയോൺമെന്റ് എങ്ങനെ സജ്ജീകരിക്കാം

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

ഈ ആശയം പുതിയതാണെങ്കിൽ, എന്താണ് സ്റ്റേജിംഗ് എൻവയോൺമെന്റ് ആശയം വിശദീകരിക്കുന്നു. ഈ ഗൈഡ് പ്രായോഗിക സജ്ജീകരണമാണ്, DevOps ടീം നടത്തുന്നവർക്കല്ല, AI ടൂളുകൾ ഉപയോഗിച്ച് നിർമ്മിക്കുന്നവർക്കായി എഴുതിയതാണ്.

ഡെവ്, സ്റ്റേജിംഗ്, പ്രൊഡക്ഷൻ

മിക്ക ചെറിയ ആപ്പുകൾക്കും മൂന്ന് സ്ഥലങ്ങൾ വേണം, ആദ്യത്തേത് നിങ്ങളുടെ ബിൽഡറിന്റെ പ്രിവ്യൂ മാത്രമാണെങ്കിലും:

സ്റ്റേജിംഗിന്റെ ഉദ്ദേശ്യം അത് പ്രൊഡക്ഷൻ പോലെ പെരുമാറുക എന്നതാണ് — അതേ കോഡ്, അതേ സ്റ്റാക്ക്, അതേ തരം ക്രമീകരണങ്ങൾ — പക്ഷേ അവിടെയുള്ള ഒരു പിഴവ് ആർക്കും ദോഷം ചെയ്യില്ല.

ഘട്ടം 1: സ്റ്റേജിംഗ് എന്തുമായി ഒത്തുപോകണമെന്ന് തീരുമാനിക്കുക

പ്രൊഡക്ഷനിൽ പ്രശ്നങ്ങൾ വരുന്നതിന് മുമ്പ് അവ സ്റ്റേജിംഗിൽ കണ്ടാൽ മാത്രമേ സ്റ്റേജിംഗ് ഉപയോഗപ്രദമാകൂ. ഇവ ഒത്തുനോക്കുക:

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

വലിപ്പത്തിലും (ചെറിയ മെഷീൻ മതി) ഡാറ്റയിലും വ്യത്യാസമുണ്ടാകാം.

ഘട്ടം 2: പകർപ്പ് ഉണ്ടാക്കുക

ഏറ്റവും ലളിതമായ രീതി: അതേ പ്രോജക്റ്റിന്റെ രണ്ടാമത്തെ ഡിപ്ലോയ്മെന്റ്, staging.yourapp.com അല്ലെങ്കിൽ yourapp-staging.example.com പോലുള്ള വ്യത്യസ്ത URLൽ.

അത് നിങ്ങളുടെ ഹോസ്റ്റിനെ ആശ്രയിച്ചിരിക്കുന്നു:

• ബിൽറ്റ്-ഇൻ പ്രിവ്യൂ അല്ലെങ്കിൽ സ്റ്റേജിംഗ് ഡിപ്ലോയ്മെന്റുകളുള്ള ഹോസ്റ്റുകൾ ഒരു Git ബ്രാഞ്ചിനായി അത് സ്വയമേവ ഉണ്ടാക്കാം.
• അങ്ങനെ ഇല്ലാത്ത ഹോസ്റ്റുകൾ: അതേ കോഡിൽ നിന്ന് രണ്ടാമത്തെ ആപ്പ് അല്ലെങ്കിൽ പ്രോജക്റ്റ് ഉണ്ടാക്കി വേറെ ഡിപ്ലോയ് ചെയ്യുക.
• Gitൽ കോഡ്: സ്റ്റേജിംഗിലേക്ക് ഡിപ്ലോയ് ചെയ്യുന്ന ഒരു staging അല്ലെങ്കിൽ main ബ്രാഞ്ച് സൂക്ഷിക്കുക, ഒരു റിലീസിൽ നിന്ന് പ്രൊഡക്ഷനിലേക്ക് ഡിപ്ലോയ് ചെയ്യുക. AI ഉപയോഗിച്ച് നിർമ്മിച്ച ആപ്പിനൊപ്പം Git എങ്ങനെ ഉപയോഗിക്കാം കാണുക.

ഘട്ടം 3: സ്റ്റേജിംഗിന് സ്വന്തം ഡാറ്റാബേസ് നൽകുക

നിങ്ങളെ സംരക്ഷിക്കുന്ന ഘട്ടമാണിത്. സ്റ്റേജിംഗും പ്രൊഡക്ഷനും ഒരു ഡാറ്റാബേസ് പങ്കിടുകയാണെങ്കിൽ, റെക്കോർഡുകൾ ഇല്ലാതാക്കുന്ന ഒരു ടെസ്റ്റ് യഥാർത്ഥ റെക്കോർഡുകൾ ഇല്ലാതാക്കും.

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

ഒഴിഞ്ഞ ഡാറ്റാബേസ് യാഥാർത്ഥ്യബോധമുള്ള ടെസ്റ്റ് ഡാറ്റ കൊണ്ട് നിറയ്ക്കുന്ന ഒരു സീഡ് സ്ക്രിപ്റ്റ് എഴുതുക: 20 ഉപഭോക്താക്കൾ, വ്യത്യസ്ത അവസ്ഥകളിലുള്ള 50 ഓർഡറുകൾ, രണ്ട് അഡ്മിൻ ഉപയോക്താക്കൾ. വ്യക്തമായും വ്യാജമായ പേരുകളും example.com ഇമെയിൽ വിലാസങ്ങളും ഉപയോഗിക്കുക.

സജ്ജീകരണത്തിൽ വിശ്വസിക്കുന്നതിന് മുമ്പ്, ഓരോ പകർപ്പും ഏത് ഡാറ്റാബേസുമായി ബന്ധിപ്പിക്കുന്നു എന്ന് ഉറപ്പാക്കുക. നേരിട്ട് ചോദിക്കുക:

ഈ ആപ്പ് ഏത് ഡാറ്റാബേസുമായി ബന്ധിപ്പിക്കുന്നു, ആ ക്രമീകരണം എവിടെ നിന്ന് വരുന്നു? പാസ്‌വേഡ് അല്ല, വേരിയബിളിന്റെ പേര് കാണിക്കുക.

ഘട്ടം 4: ടെസ്റ്റ് കീകളും വേറിട്ട ക്രമീകരണങ്ങളും ഉപയോഗിക്കുക

സ്റ്റേജിംഗിൽ പുറത്തുള്ള ഒരു സേവനവുമായി സംസാരിക്കുന്ന എല്ലാം ടെസ്റ്റ് ക്രെഡൻഷ്യലുകൾ ഉപയോഗിക്കണം:

• പേയ്‌മെന്റുകൾ ടെസ്റ്റ് മോഡിൽ (ഉദാഹരണത്തിന് Stripe ടെസ്റ്റ് കീകൾ), അതുവഴി യഥാർത്ഥ കാർഡിന് ചാർജ് ചെയ്യപ്പെടില്ല.
• ഇമെയിൽ ഒരു സാൻഡ്‌ബോക്സിലേക്കോ നിങ്ങളുടെ സ്വന്തം വിലാസത്തിലേക്ക് മാത്രമോ അയക്കുക, അതുവഴി ഉപഭോക്താക്കൾക്ക് ഒരിക്കലും ടെസ്റ്റ് സന്ദേശം കിട്ടില്ല.
• AIയും മറ്റ് പണമടച്ചുള്ള APIകളും വേറെ കീയും കുറഞ്ഞ ചെലവ് പരിധിയുമായി.
• വെബ്ഹുക്കുകൾ പ്രൊഡക്ഷനല്ല, സ്റ്റേജിംഗ് URLലേക്ക് ചൂണ്ടിക്കാണിക്കുക.

രണ്ട് എൻവയോൺമെന്റുകളിലും വേരിയബിളുകളുടെ പേരുകൾ ഒന്നുതന്നെയാക്കി നിർത്തുക, മൂല്യങ്ങൾ മാത്രം മാറ്റുക. അങ്ങനെ കോഡ് എവിടെ പ്രവർത്തിക്കുന്നു എന്ന് അറിയേണ്ട ആവശ്യമില്ല. ഇതിനെക്കുറിച്ച് കൂടുതൽ അറിയാൻ, API കീകൾ സുരക്ഷിതമായി സൂക്ഷിക്കുന്നത് എങ്ങനെ കാണുക.

ഘട്ടം 5: സ്റ്റേജിംഗ് സ്വകാര്യമായി സൂക്ഷിക്കുക

സ്റ്റേജിംഗ് പബ്ലിക്കായിരിക്കരുത്:

• ഒരു ലോഗിന്, പാസ്‌വേഡ്, അല്ലെങ്കിൽ ടീം ഇമെയിലുകളുടെ അനുവദനീയ പട്ടികയ്ക്ക് പിന്നിൽ വെക്കുക.
• noindex മെറ്റാ ടാഗോ X-Robots-Tag ഹെഡറോ ഉപയോഗിച്ച് സെർച്ച് എൻജിനുകൾ ഇൻഡെക്സ് ചെയ്യുന്നത് തടയുക.
• പബ്ലിക് സൈറ്റിൽ നിന്ന് അതിലേക്ക് ലിങ്ക് ചെയ്യരുത്.
• അത് വേറിട്ട് കാണുന്ന രീതിയിൽ ആക്കുക — നിറമുള്ള “STAGING” ബാനർ തെറ്റായ ടാബിൽ ടെസ്റ്റ് ചെയ്യുന്നത് തടയുന്നു.

APP_ENV എൻവയോൺമെന്റ് വേരിയബിൾ “staging” ആയിരിക്കുമ്പോൾ, ഓരോ പേജിന്റെയും മുകളിൽ “STAGING — test data only” എന്ന് പറയുന്ന തിളക്കമുള്ള മഞ്ഞ ബാനർ ചേർക്കുക. ആ സാഹചര്യത്തിൽ noindex മെറ്റാ ടാഗും ചേർക്കുക.

ഘട്ടം 6: ഒരു റിലീസ് ശീലം ഉണ്ടാക്കുക

സ്റ്റേജിംഗ് ഓരോ തവണയും ഉപയോഗിച്ചാൽ മാത്രമേ സഹായിക്കൂ. ഒരു ലളിതമായ ക്രമം:

1. ഡെവലപ്മെന്റിൽ മാറ്റം വരുത്തി പ്രിവ്യൂയിൽ പരിശോധിക്കുക.
2. സ്റ്റേജിംഗിലേക്ക് റിലീസ് ചെയ്യുക.
3. പ്രധാന ഫ്ലോകളിലൂടെ കടന്നുപോകുക: സൈൻ അപ്പ്, ലോഗിൻ, പ്രധാന ഫീച്ചർ, പേയ്‌മെന്റുകൾ, മാറ്റം തൊട്ട എന്തും.
4. എന്തെങ്കിലും പൊട്ടിയാൽ, ശരിയാക്കി വീണ്ടും സ്റ്റേജിംഗിലേക്ക് റിലീസ് ചെയ്യുക.
5. അതേ പതിപ്പ് പ്രൊഡക്ഷനിലേക്ക് പ്രസിദ്ധീകരിക്കുക.
6. പ്രൊഡക്ഷൻ വേഗത്തിൽ പരിശോധിക്കുക — അതേ ഫ്ലോകൾ, ചുരുക്കത്തിൽ.

പ്രധാന ഫ്ലോകൾ ഒരു ചെറിയ ടെസ്റ്റ് സ്ക്രിപ്റ്റായി എഴുതി വെക്കുക. ലോഞ്ചിന് മുമ്പ് ആപ്പ് എങ്ങനെ പരിശോധിക്കാം എന്നതിന് ലോഞ്ചിന് മുമ്പ് ആപ്പ് എങ്ങനെ ടെസ്റ്റ് ചെയ്യാം കാണുക.

ഘട്ടം 7: ഡാറ്റാബേസ് മാറ്റങ്ങൾ ശ്രദ്ധയോടെ കൈകാര്യം ചെയ്യുക

ഡാറ്റാബേസ് ഘടനയിലെ മാറ്റങ്ങൾ — ഒരു കോളം ചേർക്കുന്നതോ ഒരു ടേബിളിന്റെ പേര് മാറ്റുന്നതോ — സ്റ്റേജിംഗ് അതിന്റെ മൂല്യം തെളിയിക്കുന്ന ഇടമാണ്.

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

ഉദാഹരണ പ്രോംപ്റ്റുകൾ

ഈ ഡാറ്റാബേസ് മാറ്റം പ്രൊഡക്ഷനിൽ പ്രവർത്തിപ്പിച്ചാൽ നിലവിലുള്ള ഡാറ്റയ്ക്ക് എന്ത് സംഭവിക്കുമെന്ന് വിശദീകരിക്കുക. എന്തെങ്കിലും ഇല്ലാതാക്കപ്പെടുന്നുണ്ടോ അതോ പേരുമാറ്റപ്പെടുന്നുണ്ടോ?

എൻവയോൺമെന്റ്-നിർദ്ദിഷ്ട ക്രമീകരണങ്ങൾ — API URLകൾ, കീകൾ, ഇമെയിൽ അയക്കുന്നയാൾ, സൈറ്റിന്റെ സ്വന്തം URL — എല്ലാം സ്റ്റേജിംഗിലും പ്രൊഡക്ഷനിലും ഒരേ പേരുകളുള്ള എൻവയോൺമെന്റ് വേരിയബിളുകളിൽ നിന്ന് വരുന്ന രീതിയിൽ ആക്കുക. അവ പട്ടികപ്പെടുത്തുക.

ഈ ആപ്പ് എന്ത് ചെയ്യുന്നു എന്നതിനെ അടിസ്ഥാനമാക്കി, ഓരോ റിലീസിനും മുമ്പ് സ്റ്റേജിംഗിൽ ഞാൻ പരിശോധിക്കേണ്ട ഫ്ലോകളുടെ ഒരു ചെറിയ ചെക്ക്‌ലിസ്റ്റ് എഴുതുക.

സാധാരണ തെറ്റുകൾ

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

ചെക്ക്‌ലിസ്റ്റ്

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

Mythex-ൽ സ്റ്റേജിംഗ്

Mythexന്റെ Publish ഓരോ ആപ്പിനും ഒരു ലൈവ് URL മാത്രം നൽകുന്നു; പ്രത്യേക സ്റ്റേജിംഗ് ടോഗിൾ ഇല്ല. പ്രായോഗികമായി രണ്ട് ഓപ്ഷനുകളുണ്ട്:

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

ഏതായാലും, എന്തെങ്കിലും നാശകരമായത് ടെസ്റ്റ് ചെയ്യുന്നതിന് മുമ്പ്, പ്രിവ്യൂയും പ്രസിദ്ധീകരിച്ച ആപ്പും ഏത് ഡാറ്റാബേസ് ഉപയോഗിക്കുന്നു എന്ന് ഏജന്റിനോട് ചോദിക്കുക; മോശം മാറ്റം തിരികെ എടുക്കാൻ ചെക്ക്‌പോയിന്റുകൾ ഉപയോഗിക്കുക. ആപ്പ് വിശാലമായി ലൈവാക്കുന്നതിനെക്കുറിച്ച്, AI പ്രോട്ടോടൈപ്പ് പ്രൊഡക്ഷനിലേക്ക് എങ്ങനെ കൊണ്ടുപോകാം കാണുക.

ചോദ്യങ്ങൾ