വേദനയില്ലാതെ ആസക്തികളെ നിലനിർത്തുക

ഓരോ പ്രോജക്ടും പുതിയ ആശ്രിതത്വങ്ങളോടെയാണ് തുടങ്ങുന്നത്. ഒരു വര് ഷം കഴിഞ്ഞ്, അവയില് പകുതിയും കാലഹരണപ്പെട്ടവയാണ്. രണ്ടു വർഷത്തിനു ശേഷം ഒരു ലൈബ്രറി അപ്ഗ്രേഡ് ചെയ്യാന് അഞ്ച് ലൈബ്രറികള് കൂടി അപ്ഗ്രെഡ് ചെയ്യണം, ഫ്രെയിം വർക്ക്, ഭാഷാ പതിപ്പ്, പെട്ടെന്ന് ഒരു ചെറിയ അപ്ഡേറ്റ് ഒരു മൂന്നു ആഴ്ചത്തെ പ്രോജക്ട് ആയി മാറുന്നു.

പരിഹാരം ഹീറോയിക് അപ്ഗ്രേഡ് സ്പ്രിന്റുകളല്ല. ചെറിയ, സ്ഥിരമായ, ഓട്ടോമേറ്റഡ് അപ്ഡേറ്റുകളാണ്. റിനോവേറ്റും ഡെപൻഡാബോട്ടും അത് സാധ്യമാക്കുന്നു, നിങ്ങൾ അവയെ സജ്ജമാക്കിയാൽ അവ നിങ്ങളെ സഹായിക്കും, പകരം നിങ്ങളെ വലിച്ചെടുക്കാനുള്ള അഭ്യർത്ഥനകളാൽ വെള്ളപ്പൊക്കത്തിലാക്കും.

എന്തുകൊണ്ട് അപ്ഡേറ്റുകൾ കൂട്ടിചേരുന്നു

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

ഡെപൻഡാബോട്ട് vs റിനോവേറ്റ്

ആശ്രിതൻ ഗിറ്റ്ഹബ്ബില് അന്തര് ഘടിപ്പിച്ചിരിക്കുന്നതാണ്. എളുപ്പത്തിൽ ഓണാക്കാം, ഏറ്റവും സാധാരണമായ പരിസ്ഥിതി വ്യവസ്ഥിതികളിലെ സുരക്ഷാ അലേർട്ടുകളും പതിപ്പ് അപ്ഡേറ്റുകളും കൈകാര്യം ചെയ്യുന്നു. പല പദ്ധതികൾക്കും മതിയാകും.

പുതുക്കുക (Mend, ഓപ്പൺ സോഴ്സ്) കൂടുതൽ ശക്തവും വഴക്കമുള്ളതുമാണ്:

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

അടിസ്ഥാന സൌകര്യങ്ങളുള്ള റിപ്പോസിറ്ററികൾക്കായി, എനിക്ക് റിനോവേറ്റ് ഇഷ്ടമാണ്, കാരണം ഇത് ഇമേജ് ടാഗുകൾ, ചാർട്ട് പതിപ്പുകൾ, പിൻ ചെയ്ത ആക്ഷൻ ഷാ എന്നിവയും അപ്ഡേറ്റ് ചെയ്യാൻ കഴിയും.

എന്റെ പുതുക്കിയ ക്രമീകരണം

ശാന്തമായ ആരംഭ ക്രമീകരണം:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended", ":dependencyDashboard"],
  "schedule": ["before 7am on monday"],
  "timezone": "Europe/Berlin",
  "prConcurrentLimit": 5,
  "minimumReleaseAge": "3 days",
  "packageRules": [
    {
      "matchUpdateTypes": ["patch", "minor"],
      "matchCurrentVersion": "!/^0/",
      "groupName": "non-major dependencies",
      "automerge": true
    },
    {
      "matchManagers": ["github-actions"],
      "groupName": "github actions",
      "pinDigests": true
    },
    {
      "matchDatasources": ["docker"],
      "pinDigests": true
    }
  ],
  "vulnerabilityAlerts": {
    "schedule": ["at any time"],
    "labels": ["security"]
  }
}

ഇത് ചെയ്യുന്നതെന്ത്?

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

ഓരോ ആഴ്ചയും ചെറിയ അപ്ഡേറ്റുകൾ ബോറടിപ്പിക്കുന്നതാണ്. ഓരോ രണ്ടു വര് ഷം കൂടുമ്പോഴും ഒരു വലിയ അപ്ഗ്രേഡ് ഒരു പ്രോജക്ട് ആണ്. വിരസത തിരഞ്ഞെടുക്കുക.

ഓട്ടോമർജെ, സുരക്ഷിതമായി

ഓട്ടോമാറ്റിക് ഡെപൻഡൻസി അപ്ഡേറ്റുകൾ അപകടകരമായി തോന്നിയേക്കാം, പക്ഷെ അത് പ്രക്രിയയെ നിയന്ത്രിക്കാവുന്നതാക്കുന്നു. നിയമങ്ങൾ ഇങ്ങനെയാണ്:

• നല്ല പരിശോധനകൾ എല്ലാ പിആര് പേപ്പറുകളിലും കാണും. പരീക്ഷണങ്ങളില്ലാത്ത ഓട്ടോമർജെ ചൂതാട്ടമാണ്.
• ആവശ്യമായ സ്റ്റാറ്റസ് പരിശോധനകൾ ബ്രാഞ്ച് പരിരക്ഷയില് ,അങ്ങനെ ഒന്നും ലയിക്കുന്നില്ല,അല്ലെങ്കില് CI പച്ചയായിരിക്കും.
• കുറഞ്ഞ അപകടസാധ്യതയുള്ള അപ്ഡേറ്റുകൾക്ക് മാത്രം: സ്ഥിരമായ (1.0+) പാക്കേജുകളുടെ പാച്ചുകളും ചെറിയ പതിപ്പുകളും, ഡെവ ഡെപൻഡൻസികളും, ലിന്ററുകളും.
• പ്രധാന പതിപ്പുകൾ ഒരിക്കലും ഓട്ടോമാറ്റിക് ആയി ലയിപ്പിക്കരുത്. അവയെ മനുഷ്യന് നിരീക്ഷിക്കും.

മാറ്റങ്ങൾ ലംഘിക്കുന്നതു കൈകാര്യം ചെയ്യുക

പ്രധാനപ്പെട്ട ചില കാര്യങ്ങൾ ശ്രദ്ധിക്കേണ്ടതുണ്ട്:

• നവീകരിക്കുക റിലീസ് നോട്ടുകൾ പി.ആര് . വായിക്കൂ.
• അപ്ഡേറ്റ് ചെയ്യുക ഓരോ തവണയും ഒരു പ്രധാന, അഞ്ചു പേരെ അല്ല.
• വലിയ ഫ്രെയിം വർക്കുകൾക്ക്, ഒരു പ്രത്യേക ഗ്രൂപ്പ് സജ്ജമാക്കുകയും അതിനായി സമയം ക്രമീകരിക്കുകയും ചെയ്യുക, മറ്റേതൊരു ജോലിയും പോലെ.
• AI കോഡിംഗ് ഏജന്റുമാർ ഇവിടെ കൂടുതലായി ഉപയോഗപ്രദമാണ്ഃ ഒരു API മാറിയതിനാൽ ഒരു അപ്ഗ്രേഡ് ബിൽഡ് തകർക്കുമ്പോൾ, ഒരു ഏജന്റിന് അതേ PR- ൽ കോഡ് മാറ്റങ്ങൾ നിർദ്ദേശിക്കാൻ കഴിയും.

ചിത്രങ്ങളും ചാർട്ടുകളും കൂടി

ആപ്ലിക്കേഷന് ആശ്രിതത്വം കഥയുടെ ഒരു ഭാഗം മാത്രമാണ്. അടിസ്ഥാന സൌകര്യങ്ങള് ക്കും ആശ്രിതത്വങ്ങളുണ്ട്:

• അടിസ്ഥാന ചിത്രങ്ങൾ ഡോക്കർ ഫയലുകളിൽ
• ഹെൽം ചാർട്ട് പതിപ്പുകൾ നിങ്ങളുടെ ഗിറ്റോപ്സ് റെപ്പോയില്
• കണ്ടെയ്നർ ഇമേജ് ടാഗുകൾ കുബർനെറ്റസ് മാനിഫെസ്റ്റുകളില്
• ടെറാഫോർം ദാതാക്കളും മൊഡ്യൂളുകളും
• ഗിറ്റ്ഹബ് പ്രവർത്തനങ്ങൾ പതിപ്പുകൾ

ഇവയെല്ലാം പുതുക്കി പണിയണം. നിങ്ങളുടെ കണ്ടെയ്നറുകളിലെ ദുർബലത കുറയ്ക്കുന്നതിനുള്ള ഏറ്റവും എളുപ്പവഴിയാണ് അടിസ്ഥാന ചിത്രങ്ങൾ അപ്ഡേറ്റ് ചെയ്യുന്നത്.

എവിടെ നിന്നാണ് ഞാൻ തുടങ്ങേണ്ടത്?

ഒരു ആഴ്ചയിലെ ഷെഡ്യൂളും PR പരിധിയും ഉള്ള ഒരു റിപ്പോസിറ്ററിയിൽ റിനോവേറ്റ് (അല്ലെങ്കിൽ ഡിപൻഡാബോട്ട്) ഓണാക്കുക. നിങ്ങളുടെ പരിശോധനകളെ വിശ്വസിച്ചാല് അപ്ഡേറ്റുകള് ക്ക് ഓട്ടോമർജെന് സജ്ജമാക്കുക. ചെറിയ അപ്ഡേറ്റുകളിലേക്ക് വിപുലീകരിക്കുക, പിന്നെ ഇൻഫ്രാസ്ട്രക്ചർ ഫയലുകളിലേക്ക്. ഒരു മാസത്തിനകം, കാലികമായി തുടരുക എന്നത് ഒരു പദ്ധതിയുടെ പശ്ചാത്തല ശബ്ദമായി മാറുന്നു.

എന്റെ അഭിപ്രായം: ആസക്തികൾ പാൽ പോലെ പോകുന്നു, വീഞ്ഞു പോലെ അല്ല. ഒരു ബോട്ട് ഓരോ ആഴ്ചയും അവയെ പുതുതായി സൂക്ഷിക്കട്ടെ.

ഡെസ്ലി