ഗിറ്റ് അധിഷ്ഠിത തുടർച്ചയായ വിന്യാസം
ഒരു Git പ്രovider ഒരിക്കൽ കണക്റ്റ് ചെയ്യുക, അപ്പോൾ നിങ്ങളുടെ ശേഖരം (repository) ആധികാരിക സ്രോതസ്സായി മാറും. കോഡ് പുഷ് ചെയ്യുക, പ്ലാറ്റ്ഫോം നിങ്ങൾക്കായി അത് ബിൽഡ് ചെയ്യുകയും ഡിപ്ലോയ് ചെയ്യുകയും ചെയ്യും.
GitHub, GitLab അല്ലെങ്കിൽ Bitbucket എന്നിവ OAuth വഴി കണക്റ്റ് ചെയ്യുക. നിങ്ങളുടെ ഡിപ്ലോയ് കീകൾ പ്ലെയിൻ കോൺഫിഗറേഷനിലല്ല, എൻക്രിപ്റ്റ് ചെയ്ത ക്രെഡൻഷ്യൽ സ്റ്റോറിലാണ് സൂക്ഷിക്കുന്നത്. ഓരോ പുഷ് ചെയ്യുമ്പോഴും ഒരു വെബ്ഹോക്ക് പ്രവർത്തിക്കുകയും, സൈറ്റിലേക്ക് റിലീസ് ചെയ്യുന്നതിന് മുമ്പ് നിങ്ങളുടെ സ്റ്റേക്കിനായുള്ള ബിൽഡ് ഘട്ടങ്ങൾ — Composer, npm എന്നിവയും മറ്റുള്ളവയും — പ്രവർത്തിപ്പിക്കുന്ന ഡ്യൂറബിൾ ബിൽഡ്-ആൻഡ്-ഡിപ്ലോയ് പൈപ്പ്ലൈൻ അത് ട്രിഗർ ചെയ്യുകയും ചെയ്യുന്നു.
നിങ്ങളുടെ ടീം ഇതിനകം പിന്തുടരുന്ന രീതിയിൽ ബ്രാഞ്ചുകളെ എൻവയൺമെന്റുകളുമായി മാപ്പ് ചെയ്യുക: main എന്നത് production-ലേക്കും, staging എന്നത് staging-ലേക്കും, അല്ലെങ്കിൽ നിങ്ങൾ ഇഷ്ടപ്പെടുന്ന ഏത് രീതിയിലായാലും ശരി. ഒരു ബ്രാഞ്ചിലേക്ക് മെർജ് ചെയ്യുമ്പോൾ അതിന് അനുയോജ്യമായ എൻവയൺമെന്റ് സ്വയം അപ്ഡേറ്റ് ആകുന്നു, അതിനാൽ ഒരു മാറ്റം പ്രൊമോട്ട് ചെയ്യുക എന്നത് വെറുമൊരു git push മാത്രമാണ്.
- ഡെപ്ലോയ് കീകൾ ക്രെഡൻഷ്യൽ സ്റ്റോറിൽ സൂക്ഷിച്ചുകൊണ്ട്, GitHub, GitLab അല്ലെങ്കിൽ Bitbucket എന്നിവ OAuth വഴി കണക്റ്റ് ചെയ്യുക
- പുഷ് ചെയ്യുമ്പോഴുള്ള വെബ്ഹൂക്ക് ശക്തമായ ഒരു ബിൽഡ്-ആൻഡ്-ഡിപ്ലോയ് പൈപ്പ്ലൈൻ പ്രവർത്തിപ്പിക്കുന്നു
- ഓരോ സ്റ്റാക്കിനുമുള്ള ബിൽഡ് ഘട്ടങ്ങൾ സ്വയമേവ പ്രവർത്തിക്കുന്നു (കമ്പോസർ, എൻപിഎം എന്നിവയും മറ്റും)
- ബ്രാഞ്ച്-ടു-എൻവയോൺമെന്റ് മാപ്പിംഗ് — ഉദാഹരണത്തിന് main എന്നത് production-ലേക്കും, staging എന്നത് staging-ലേക്കും
- ആവശ്യ വരുമ്പോൾ ഏത് മുൻ പതിപ്പിലേക്കും തിരികെ പോവുക
- ഡെപ്ലോയ്മന്റുകൾ ശക്തവും പുനഃശ്രമിക്കാവുന്നതുമായ വർക്ക്ഫ്ലോകളായാണ് പ്രവർത്തിക്കുന്നത്, അതിനാൽ ബിൽഡിംഗിനിടയിലുണ്ടാകുന്ന ചെറിയ തടസ്സങ്ങൾ ഒരിക്കലും പൂർണ്ണമായി ഡെപ്ലോയ് ചെയ്യാത്ത സൈറ്റുകൾ ബാക്കി വെക്കില്ല