ഇന്ന്, മിക്ക സോഫ്റ്റ്‌വെയർ ഉൽപ്പന്നങ്ങളും ടീമുകളിലാണ് വികസിപ്പിച്ചിരിക്കുന്നത്. വിജയകരമായ ടീം വികസനത്തിനുള്ള വ്യവസ്ഥകൾ ഒരു ലളിതമായ ഡയഗ്രം രൂപത്തിൽ പ്രതിനിധീകരിക്കാം.

നിങ്ങളുടെ കോഡ് എഴുതിക്കഴിഞ്ഞാൽ, നിങ്ങൾ അത് ഉറപ്പാക്കേണ്ടതുണ്ട്:

1. .
2. നിങ്ങളുടെ സഹപ്രവർത്തകർ എഴുതിയ കോഡ് ഉൾപ്പെടെ, ഇത് ഒന്നും തകർക്കുന്നില്ല.

രണ്ട് വ്യവസ്ഥകളും പാലിക്കുകയാണെങ്കിൽ, നിങ്ങൾ വിജയത്തിലേക്കുള്ള പാതയിലാണ്. ഈ വ്യവസ്ഥകൾ എളുപ്പത്തിൽ പരിശോധിക്കുന്നതിനും ലാഭകരമായ പാതയിൽ നിന്ന് വ്യതിചലിക്കാതിരിക്കുന്നതിനും, ഞങ്ങൾ തുടർച്ചയായ സംയോജനം കൊണ്ടുവന്നു.

നിങ്ങളുടെ കോഡ് മൊത്തത്തിലുള്ള ഉൽപ്പന്ന കോഡിലേക്ക് കഴിയുന്നത്ര തവണ സംയോജിപ്പിക്കുന്ന ഒരു വർക്ക്ഫ്ലോയാണ് CI. നിങ്ങൾ സംയോജിപ്പിക്കുക മാത്രമല്ല, എല്ലാം പ്രവർത്തിക്കുന്നുണ്ടോയെന്ന് നിരന്തരം പരിശോധിക്കുകയും ചെയ്യുക. നിങ്ങൾ പലപ്പോഴും പരിശോധിക്കേണ്ടതിനാൽ, ഓട്ടോമേഷനെക്കുറിച്ച് ചിന്തിക്കുന്നത് മൂല്യവത്താണ്. നിങ്ങൾക്ക് എല്ലാം സ്വമേധയാ പരിശോധിക്കാൻ കഴിയും, എന്നാൽ നിങ്ങൾ പാടില്ല, എന്തുകൊണ്ടെന്ന് ഇവിടെയുണ്ട്.

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

Avito മൊബൈൽ ഡെവലപ്‌മെന്റ് ടീമിൽ തുടർച്ചയായ സംയോജനം എങ്ങനെ നടപ്പിലാക്കുകയും വികസിപ്പിച്ചെടുക്കുകയും ചെയ്തു, അവ എങ്ങനെ പ്രതിദിനം 0 മുതൽ 450 ബിൽഡുകൾ വരെ പോയി, കൂടാതെ യന്ത്രങ്ങൾ ഒരു ദിവസം 200 മണിക്കൂർ കൂടിച്ചേരുന്നു, നിക്കോളായ് നെസ്റ്ററോവ് പറയുന്നു (nnesterov) CI/CD ആൻഡ്രോയിഡ് ആപ്ലിക്കേഷന്റെ എല്ലാ പരിണാമ മാറ്റങ്ങളിലും പങ്കാളിയാണ്.

ഒരു Android കമാൻഡിന്റെ ഉദാഹരണത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് സ്റ്റോറി, എന്നാൽ മിക്ക സമീപനങ്ങളും iOS-ലും ബാധകമാണ്.

പണ്ട് ഒരാൾ Avito ആൻഡ്രോയിഡ് ടീമിൽ ജോലി ചെയ്തിരുന്നു. നിർവചനം അനുസരിച്ച്, അദ്ദേഹത്തിന് തുടർച്ചയായ സംയോജനത്തിൽ നിന്ന് ഒന്നും ആവശ്യമില്ല: സംയോജിപ്പിക്കാൻ ആരുമില്ല.

എന്നാൽ ആപ്ലിക്കേഷൻ വളർന്നു, കൂടുതൽ കൂടുതൽ പുതിയ ജോലികൾ പ്രത്യക്ഷപ്പെട്ടു, അതിനനുസരിച്ച് ടീം വളർന്നു. ചില ഘട്ടങ്ങളിൽ, കൂടുതൽ ഔപചാരികമായി ഒരു കോഡ് സംയോജന പ്രക്രിയ സ്ഥാപിക്കാനുള്ള സമയമാണിത്. ജിറ്റ് ഫ്ലോ ഉപയോഗിക്കാൻ തീരുമാനിച്ചു.

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

ചെക്കുകൾ

നിങ്ങളുടെ കണ്ണുകൾ കൊണ്ട് കോഡ് കാണുന്നത് രസകരമാണ്, പക്ഷേ പര്യാപ്തമല്ല. അതിനാൽ, ഓട്ടോമാറ്റിക് പരിശോധനകൾ അവതരിപ്പിക്കുന്നു.

• ഒന്നാമതായി, ഞങ്ങൾ പരിശോധിക്കുന്നു ARK അസംബ്ലി.
• ഒരുപാട് ജൂണിറ്റ് ടെസ്റ്റുകൾ.
• ഞങ്ങൾ കോഡ് കവറേജ് പരിഗണിക്കുന്നു, ഞങ്ങൾ ടെസ്റ്റുകൾ നടത്തുന്നതിനാൽ.

ഈ പരിശോധനകൾ എങ്ങനെ പ്രവർത്തിപ്പിക്കണമെന്ന് മനസിലാക്കാൻ, Avito-യിലെ വികസന പ്രക്രിയ നോക്കാം.

ഇത് സ്കീമാറ്റിക്കായി ഇതുപോലെ പ്രതിനിധീകരിക്കാം:

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

അവരുടെ ലാപ്‌ടോപ്പിൽ സ്കാൻ പ്രവർത്തിപ്പിക്കുന്നത് ആരും ഇഷ്ടപ്പെട്ടില്ല. ഒരു ഡവലപ്പർ ഒരു ഫീച്ചർ പൂർത്തിയാക്കുമ്പോൾ, അത് വേഗത്തിൽ പുഷ് ചെയ്ത് ഒരു പുൾ അഭ്യർത്ഥന തുറക്കാൻ അവൻ ആഗ്രഹിക്കുന്നു. ഈ നിമിഷം ചില നീണ്ട പരിശോധനകൾ സമാരംഭിക്കുകയാണെങ്കിൽ, ഇത് വളരെ മനോഹരം മാത്രമല്ല, വികസനം മന്ദഗതിയിലാക്കുന്നു: ലാപ്ടോപ്പ് എന്തെങ്കിലും പരിശോധിക്കുമ്പോൾ, അതിൽ സാധാരണയായി പ്രവർത്തിക്കുന്നത് അസാധ്യമാണ്.

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

പരിശോധനകൾ ഒരു പുൾ അഭ്യർത്ഥനയെ തടഞ്ഞാൽ, മതിയായ പ്രചോദനം ഉണ്ട്, കാരണം ബിൽഡുകൾ പച്ചയായി മാറുന്നതുവരെ, കോഡ് വികസിപ്പിക്കില്ല, അതായത് ടാസ്ക് പൂർത്തിയാകില്ല.

തൽഫലമായി, ഞങ്ങൾ ഇനിപ്പറയുന്ന തന്ത്രം തിരഞ്ഞെടുത്തു: ഞങ്ങൾ രാത്രിയിൽ സാധ്യമായ പരമാവധി ചെക്കുകൾ പ്രവർത്തിപ്പിക്കുകയും അവയിൽ ഏറ്റവും നിർണായകമായവയും ഏറ്റവും പ്രധാനമായി, പുൾ അഭ്യർത്ഥനയിൽ ഏറ്റവും വേഗതയേറിയവയും സമാരംഭിക്കുന്നു. എന്നാൽ ഞങ്ങൾ അവിടെ നിർത്തുന്നില്ല - സമാന്തരമായി, ചെക്കുകളുടെ വേഗത ഞങ്ങൾ ഒപ്റ്റിമൈസ് ചെയ്യുന്നു, അതുവഴി അഭ്യർത്ഥന ചെക്കുകൾ പിൻവലിക്കുന്നതിന് രാത്രി മോഡിൽ നിന്ന് അവ കൈമാറും.

ആ സമയത്ത്, ഞങ്ങളുടെ എല്ലാ ബിൽഡുകളും വളരെ വേഗത്തിൽ പൂർത്തിയാക്കി, അതിനാൽ പുൾ അഭ്യർത്ഥനയ്ക്കുള്ള ഒരു ബ്ലോക്കറായി ഞങ്ങൾ ARK ബിൽഡ്, ജൂണിറ്റ് ടെസ്റ്റുകൾ, കോഡ് കവറേജ് കണക്കുകൂട്ടലുകൾ എന്നിവ ഉൾപ്പെടുത്തി. ഞങ്ങൾ അത് ഓണാക്കി, അതിനെക്കുറിച്ച് ചിന്തിക്കുകയും കോഡ് കവറേജ് ഉപേക്ഷിക്കുകയും ചെയ്തു, കാരണം ഞങ്ങൾക്ക് ഇത് ആവശ്യമില്ലെന്ന് ഞങ്ങൾ കരുതി.

അടിസ്ഥാന CI പൂർണ്ണമായും സജ്ജീകരിക്കാൻ ഞങ്ങൾക്ക് രണ്ട് ദിവസമെടുത്തു (ഇനി മുതൽ സമയം കണക്കാക്കുന്നത് ഏകദേശമാണ്, സ്കെയിലിന് ആവശ്യമാണ്).

അതിനുശേഷം, ഞങ്ങൾ കൂടുതൽ ചിന്തിക്കാൻ തുടങ്ങി - ഞങ്ങൾ ശരിയായി പരിശോധിക്കുന്നുണ്ടോ? പുൾ അഭ്യർത്ഥനകളിൽ ഞങ്ങൾ ബിൽഡുകൾ ശരിയായി പ്രവർത്തിപ്പിക്കുന്നുണ്ടോ?

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

ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ ഒരു ലളിതമായ ബാഷ് സ്ക്രിപ്റ്റ് എഴുതി premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

ഇവിടെ ഡെവലപ്‌മെന്റിൽ നിന്നുള്ള ഏറ്റവും പുതിയ എല്ലാ മാറ്റങ്ങളും ലളിതമായി വലിച്ചെടുത്ത് നിലവിലെ ബ്രാഞ്ചിലേക്ക് ലയിപ്പിക്കുന്നു. എല്ലാ ബിൽഡുകളുടെയും ആദ്യപടിയായി ഞങ്ങൾ premerge.sh സ്ക്രിപ്റ്റ് ചേർത്തു, ഞങ്ങൾക്ക് എന്താണ് വേണ്ടതെന്ന് കൃത്യമായി പരിശോധിക്കാൻ തുടങ്ങി, അതായത് സംയോജനം.

പ്രശ്നം പ്രാദേശികവൽക്കരിക്കാനും ഒരു പരിഹാരം കണ്ടെത്താനും ഈ സ്ക്രിപ്റ്റ് എഴുതാനും മൂന്ന് ദിവസമെടുത്തു.

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

ഇത് എങ്ങനെ സംഭവിക്കുന്നു എന്നതിന്റെ ഒരു ഉദാഹരണം:

രണ്ട് ഡവലപ്പർമാർ ഒരേസമയം എ, ബി എന്നീ ഫീച്ചറുകളിൽ പ്രവർത്തിക്കാൻ തുടങ്ങുന്നു. ഫീച്ചർ എയുടെ ഡെവലപ്പർ പ്രോജക്റ്റിൽ ഉപയോഗിക്കാത്ത ഫീച്ചർ കണ്ടെത്തുന്നു answer() ഒരു നല്ല കുട്ടി സ്കൗട്ട് പോലെ, അത് നീക്കം ചെയ്യുന്നു. അതേ സമയം, ഫീച്ചർ ബിയുടെ ഡെവലപ്പർ തന്റെ ബ്രാഞ്ചിൽ ഈ ഫംഗ്‌ഷനിലേക്ക് ഒരു പുതിയ കോൾ ചേർക്കുന്നു.

ഡെവലപ്പർമാർ അവരുടെ ജോലി പൂർത്തിയാക്കി ഒരേ സമയം ഒരു പുൾ അഭ്യർത്ഥന തുറക്കുന്നു. ബിൽഡുകൾ സമാരംഭിച്ചു, ഏറ്റവും പുതിയ ഡെവലപ്‌മെന്റ് അവസ്ഥയെക്കുറിച്ചുള്ള രണ്ട് പുൾ അഭ്യർത്ഥനകളും premerge.sh പരിശോധിക്കുന്നു - എല്ലാ ചെക്കുകളും പച്ചയാണ്. അതിനുശേഷം, ഫീച്ചർ എയുടെ പുൾ അഭ്യർത്ഥന ലയിക്കുന്നു, ഫീച്ചർ ബിയുടെ പുൾ അഭ്യർത്ഥന ലയിക്കുന്നു... ബൂം! ഡെവലപ്പ് കോഡിൽ നിലവിലില്ലാത്ത ഫംഗ്‌ഷനിലേക്കുള്ള ഒരു കോൾ അടങ്ങിയിരിക്കുന്നതിനാൽ ബ്രേക്കുകൾ വികസിപ്പിക്കുക.

അത് വികസിപ്പിക്കാൻ പോകുന്നില്ലെങ്കിൽ, അത് പ്രാദേശിക ദുരന്തം. മുഴുവൻ ടീമിനും ഒന്നും ശേഖരിക്കാനും പരിശോധനയ്ക്ക് സമർപ്പിക്കാനും കഴിയില്ല.

ഞാൻ മിക്കപ്പോഴും ഇൻഫ്രാസ്ട്രക്ചർ ജോലികളിൽ പ്രവർത്തിച്ചു: അനലിറ്റിക്സ്, നെറ്റ്‌വർക്ക്, ഡാറ്റാബേസുകൾ. അതായത്, മറ്റ് ഡെവലപ്പർമാർ ഉപയോഗിക്കുന്ന ആ ഫംഗ്ഷനുകളും ക്ലാസുകളും എഴുതിയത് ഞാനാണ്. ഇക്കാരണത്താൽ, ഞാൻ പലപ്പോഴും സമാനമായ സാഹചര്യങ്ങളിൽ എന്നെത്തന്നെ കണ്ടെത്തി. ഈ ചിത്രം ഞാൻ കുറച്ചു നേരം തൂക്കി വെച്ചിരുന്നു.

ഇത് ഞങ്ങൾക്ക് അനുയോജ്യമല്ലാത്തതിനാൽ, ഇത് എങ്ങനെ തടയാം എന്നതിനെക്കുറിച്ചുള്ള ഓപ്ഷനുകൾ ഞങ്ങൾ പര്യവേക്ഷണം ചെയ്യാൻ തുടങ്ങി.

എങ്ങനെ തകർക്കാൻ പാടില്ല വികസനം

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

ഇതിന് എത്ര സമയമെടുക്കുമെന്ന് മനസിലാക്കാൻ, രണ്ട് PR-കൾ ഉള്ള ഒരു ഉദാഹരണം പരിഗണിക്കുക. ഞങ്ങൾ രണ്ട് പിആർ തുറക്കുന്നു: രണ്ട് ബിൽഡുകൾ, രണ്ട് റൺ ചെക്കുകൾ. ആദ്യത്തെ പിആർ വികസനത്തിൽ ലയിപ്പിച്ച ശേഷം, രണ്ടാമത്തേത് പുനർനിർമ്മിക്കേണ്ടതുണ്ട്. മൊത്തത്തിൽ, രണ്ട് PR-കൾക്ക് മൂന്ന് റൺ ചെക്കുകൾ ആവശ്യമാണ്: 2 + 1 = 3.

തത്വത്തിൽ, അത് നല്ലതാണ്. എന്നാൽ ഞങ്ങൾ സ്ഥിതിവിവരക്കണക്കുകൾ പരിശോധിച്ചു, ഞങ്ങളുടെ ടീമിലെ സാധാരണ സാഹചര്യം 10 ​​ഓപ്പൺ പിആർ ആയിരുന്നു, തുടർന്ന് ചെക്കുകളുടെ എണ്ണം പുരോഗതിയുടെ ആകെത്തുകയാണ്: 10 + 9 +... + 1 = 55. അതായത്, 10 അംഗീകരിക്കുക PR-കൾ, നിങ്ങൾ 55 തവണ പുനർനിർമ്മിക്കേണ്ടതുണ്ട്. എല്ലാ ചെക്കുകളും ആദ്യമായി കടന്നുപോകുമ്പോൾ, ഈ ഡസൻ പ്രോസസ്സ് ചെയ്യുമ്പോൾ ആരും അധിക പുൾ അഭ്യർത്ഥന തുറക്കാത്തപ്പോൾ ഇത് അനുയോജ്യമായ ഒരു സാഹചര്യത്തിലാണ്.

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

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

തൽഫലമായി, മൂന്നാമത്തെ ഓപ്ഷൻ മാത്രമേ അവശേഷിക്കുന്നുള്ളൂ - ബൈക്ക്. ഞങ്ങളുടെ എല്ലാ കോഡുകളും ഞങ്ങളുടെ എല്ലാ ഉറവിടങ്ങളും ബിറ്റ്ബക്കറ്റ് സെർവറിലെ ഒരു ശേഖരത്തിൽ സംഭരിച്ചിരിക്കുന്നു. അതനുസരിച്ച്, ഞങ്ങൾ ബിറ്റ്ബക്കറ്റിനായി ഒരു പ്ലഗിൻ വികസിപ്പിക്കേണ്ടതുണ്ട്.

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

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

ഈ പ്ലഗിൻ നടപ്പിലാക്കുന്നതിന് മുമ്പ്, ഓരോ പുൾ അഭ്യർത്ഥനയ്ക്കും ഞങ്ങൾ ശരാശരി 2,7 അവലോകന റണ്ണുകൾ നടത്തിയിരുന്നു. പ്ലഗിൻ ഉപയോഗിച്ച് 3,6 ലോഞ്ചുകൾ ഉണ്ടായിരുന്നു. ഇത് ഞങ്ങൾക്ക് യോജിച്ചു.

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

ബിറ്റ്ബക്കറ്റ് പ്ലഗിന്റെ ആദ്യ പതിപ്പ് എഴുതാൻ ഞങ്ങൾക്ക് രണ്ടാഴ്ചയെടുത്തു.

പുതിയ ചെക്കുകൾ

അതേസമയം, ഞങ്ങളുടെ ടീം വളർന്നുകൊണ്ടിരുന്നു. പുതിയ ചെക്കുകൾ ചേർത്തു.

ഞങ്ങൾ ചിന്തിച്ചു: തടയാൻ കഴിയുമെങ്കിൽ എന്തുകൊണ്ടാണ് തെറ്റുകൾ വരുത്തുന്നത്? അതുകൊണ്ടാണ് അവർ നടപ്പാക്കിയത് സ്റ്റാറ്റിക് കോഡ് വിശകലനം. ആൻഡ്രോയിഡ് SDK-യിൽ ഉൾപ്പെടുത്തിയിരിക്കുന്ന ലിന്റ് ഉപയോഗിച്ചാണ് ഞങ്ങൾ ആരംഭിച്ചത്. എന്നാൽ ആ സമയത്ത്, കോട്ലിൻ കോഡ് ഉപയോഗിച്ച് എങ്ങനെ പ്രവർത്തിക്കണമെന്ന് അദ്ദേഹത്തിന് അറിയില്ലായിരുന്നു, കൂടാതെ ഞങ്ങളുടെ അപേക്ഷയുടെ 75% കോട്ലിനിൽ എഴുതിയിരുന്നു. അതിനാൽ, അന്തർനിർമ്മിതമായവ ലിന്റിലേക്ക് ചേർത്തു ആൻഡ്രോയിഡ് സ്റ്റുഡിയോ പരിശോധിക്കുന്നു.

ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ വളരെയധികം വികൃതമാക്കേണ്ടതുണ്ട്: ആൻഡ്രോയിഡ് സ്റ്റുഡിയോ എടുത്ത് ഡോക്കറിൽ പാക്കേജുചെയ്‌ത് ഒരു വെർച്വൽ മോണിറ്റർ ഉപയോഗിച്ച് സിഐയിൽ പ്രവർത്തിപ്പിക്കുക, അതുവഴി ഇത് ഒരു യഥാർത്ഥ ലാപ്‌ടോപ്പിലാണ് പ്രവർത്തിക്കുന്നതെന്ന് കരുതുന്നു. പക്ഷേ അത് പ്രവർത്തിച്ചു.

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

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

ഫയർബേസ് ടെസ്റ്റ് ലാബ്

ഫയർബേസ് ഒരു Google ഉൽപ്പന്നമായതിനാലാണ് ഇത് തിരഞ്ഞെടുത്തത്, അതിനർത്ഥം അത് വിശ്വസനീയവും ഒരിക്കലും മരിക്കാൻ സാധ്യതയുള്ളതുമായിരിക്കണം എന്നാണ്. വിലകൾ ന്യായമാണ്: ഒരു യഥാർത്ഥ ഉപകരണത്തിന്റെ പ്രവർത്തനത്തിന് മണിക്കൂറിന് $5, ഒരു എമുലേറ്ററിന്റെ പ്രവർത്തനത്തിന് മണിക്കൂറിന് 1 $.

ഞങ്ങളുടെ CI-യിൽ ഫയർബേസ് ടെസ്റ്റ് ലാബ് നടപ്പിലാക്കാൻ ഏകദേശം മൂന്നാഴ്ചയെടുത്തു.

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

ഡോക്കർ + പൈത്തൺ + ബാഷ്

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

ഞങ്ങളുടെ സ്വന്തം പരീക്ഷണ അന്തരീക്ഷം സൃഷ്ടിക്കാൻ അഞ്ച് ആഴ്ച എടുത്തു.

തൽഫലമായി, ഓരോ പുൾ അഭ്യർത്ഥനയ്ക്കും ചെക്കുകളുടെ വിപുലമായ ലയന-തടയൽ ലിസ്റ്റ് ഉണ്ടായിരുന്നു:

• ARK അസംബ്ലി;
• ജൂണിറ്റ് ടെസ്റ്റുകൾ;
• ലിന്റ്;
• ആൻഡ്രോയിഡ് സ്റ്റുഡിയോ പരിശോധിക്കുന്നു;
• ഇൻസ്ട്രുമെന്റേഷൻ ടെസ്റ്റുകൾ;
• സ്ക്രീൻഷോട്ട് പരിശോധനകൾ.

ഇത് സാധ്യമായ പല തകരാറുകളും തടഞ്ഞു. സാങ്കേതികമായി എല്ലാം പ്രവർത്തിച്ചു, പക്ഷേ ഫലങ്ങൾക്കായുള്ള കാത്തിരിപ്പ് വളരെ നീണ്ടതാണെന്ന് ഡവലപ്പർമാർ പരാതിപ്പെട്ടു.

എത്ര ദൈർഘ്യമേറിയതാണ്? ഞങ്ങൾ Bitbucket, TeamCity എന്നിവയിൽ നിന്നുള്ള ഡാറ്റ വിശകലന സംവിധാനത്തിലേക്ക് അപ്‌ലോഡ് ചെയ്യുകയും അത് മനസ്സിലാക്കുകയും ചെയ്തു ശരാശരി കാത്തിരിപ്പ് സമയം 45 മിനിറ്റ്. അതായത്, ഒരു ഡവലപ്പർ, ഒരു പുൾ അഭ്യർത്ഥന തുറക്കുമ്പോൾ, ബിൽഡ് ഫലങ്ങൾക്കായി ശരാശരി 45 മിനിറ്റ് കാത്തിരിക്കുന്നു. എന്റെ അഭിപ്രായത്തിൽ, ഇത് ധാരാളം, നിങ്ങൾക്ക് അങ്ങനെ പ്രവർത്തിക്കാൻ കഴിയില്ല.

തീർച്ചയായും, ഞങ്ങളുടെ എല്ലാ നിർമ്മാണങ്ങളും വേഗത്തിലാക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു.

നമുക്ക് വേഗത കൂട്ടാം

കെട്ടിടങ്ങൾ പലപ്പോഴും ക്യൂവിൽ നിൽക്കുന്നത് കാണുമ്പോൾ, ഞങ്ങൾ ആദ്യം ചെയ്യുന്നത് ഇതാണ് കൂടുതൽ ഹാർഡ്‌വെയർ വാങ്ങി - വിപുലമായ വികസനം ഏറ്റവും ലളിതമാണ്. ബിൽഡുകൾ ക്യൂ നിൽക്കുന്നത് നിർത്തി, പക്ഷേ കാത്തിരിപ്പ് സമയം ചെറുതായി കുറഞ്ഞു, കാരണം ചില പരിശോധനകൾ തന്നെ വളരെ സമയമെടുത്തു.

വളരെയധികം സമയമെടുക്കുന്ന ചെക്കുകൾ നീക്കംചെയ്യുന്നു

ഞങ്ങളുടെ തുടർച്ചയായ സംയോജനത്തിന് ഇത്തരത്തിലുള്ള പിശകുകളും പ്രശ്‌നങ്ങളും കണ്ടെത്താനാകും.

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

ഈ ലിസ്റ്റ് നോക്കിയപ്പോൾ, ആദ്യത്തെ രണ്ട് പോയിന്റുകൾ മാത്രമാണ് നിർണായകമെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി. അത്തരം പ്രശ്നങ്ങൾ ആദ്യം പരിഹരിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഡിസൈൻ-റിവ്യൂ ഘട്ടത്തിൽ ലേഔട്ടിലെ ബഗുകൾ കണ്ടെത്തുകയും പിന്നീട് എളുപ്പത്തിൽ തിരുത്തുകയും ചെയ്യാം. സാങ്കേതിക കടം കൈകാര്യം ചെയ്യുന്നതിന് ഒരു പ്രത്യേക പ്രക്രിയയും ആസൂത്രണവും ആവശ്യമാണ്, അതിനാൽ ഒരു പുൾ അഭ്യർത്ഥനയിൽ ഇത് പരീക്ഷിക്കേണ്ടെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു.

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

തൽഫലമായി, ഞങ്ങൾക്ക് അവശേഷിച്ചു:

• ARK അസംബ്ലി;
• ജൂണിറ്റ് ടെസ്റ്റുകൾ;
• ഇൻസ്ട്രുമെന്റേഷൻ ടെസ്റ്റുകൾ.

ഗ്രേഡിൽ റിമോട്ട് കാഷെ

കനത്ത പരിശോധനകളില്ലാതെ എല്ലാം മെച്ചപ്പെട്ടു. എന്നാൽ പൂർണതയ്ക്ക് പരിധിയില്ല!

ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ ഇതിനകം 150 ഗ്രേഡിൽ മൊഡ്യൂളുകളായി വിഭജിക്കപ്പെട്ടിട്ടുണ്ട്. ഗ്രേഡിൽ റിമോട്ട് കാഷെ സാധാരണയായി ഈ സാഹചര്യത്തിൽ നന്നായി പ്രവർത്തിക്കുന്നു, അതിനാൽ ഞങ്ങൾ ഇത് പരീക്ഷിക്കാൻ തീരുമാനിച്ചു.

ഗ്രാഡിൽ റിമോട്ട് കാഷെ എന്നത് വ്യക്തിഗത മൊഡ്യൂളുകളിൽ വ്യക്തിഗത ജോലികൾക്കായി ആർട്ടിഫാക്റ്റുകൾ കാഷെ ചെയ്യാൻ കഴിയുന്ന ഒരു സേവനമാണ്. ഗ്രാഡിൽ, യഥാർത്ഥത്തിൽ കോഡ് കംപൈൽ ചെയ്യുന്നതിനുപകരം, റിമോട്ട് കാഷെയിൽ തട്ടി ആരെങ്കിലും ഈ ടാസ്‌ക് നിർവ്വഹിച്ചിട്ടുണ്ടോ എന്ന് ചോദിക്കാൻ HTTP ഉപയോഗിക്കുന്നു. അതെ എങ്കിൽ, അത് ഫലം ഡൗൺലോഡ് ചെയ്യുന്നു.

Gradle ഒരു ഡോക്കർ ഇമേജ് നൽകുന്നതിനാൽ Gradle റിമോട്ട് കാഷെ പ്രവർത്തിപ്പിക്കുന്നത് എളുപ്പമാണ്. മൂന്ന് മണിക്കൂറിനുള്ളിൽ ഞങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിഞ്ഞു.

നിങ്ങൾ ചെയ്യേണ്ടത് ഡോക്കർ സമാരംഭിച്ച് പ്രോജക്റ്റിൽ ഒരു വരി എഴുതുക മാത്രമാണ്. എന്നാൽ ഇത് വേഗത്തിൽ സമാരംഭിക്കാൻ കഴിയുമെങ്കിലും, എല്ലാം നന്നായി പ്രവർത്തിക്കാൻ വളരെയധികം സമയമെടുക്കും.

കാഷെ മിസ്‌സ് ഗ്രാഫ് ചുവടെയുണ്ട്.

തുടക്കത്തിൽ തന്നെ, കാഷെ നഷ്ടപ്പെടുന്നതിന്റെ ശതമാനം ഏകദേശം 65 ആയിരുന്നു. മൂന്നാഴ്ചയ്ക്ക് ശേഷം, ഈ മൂല്യം 20% ആയി ഉയർത്താൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു. ആൻഡ്രോയിഡ് ആപ്ലിക്കേഷൻ ശേഖരിക്കുന്ന ടാസ്‌ക്കുകൾക്ക് വിചിത്രമായ ട്രാൻസിറ്റീവ് ഡിപൻഡൻസികളുണ്ടെന്ന് മനസ്സിലായി, അതിനാലാണ് ഗ്രാഡിലിന് കാഷെ നഷ്‌ടമായത്.

കാഷെ ബന്ധിപ്പിക്കുന്നതിലൂടെ, ഞങ്ങൾ ബിൽഡ് വളരെ വേഗത്തിലാക്കി. എന്നാൽ അസംബ്ലിക്ക് പുറമേ, ഇൻസ്ട്രുമെന്റേഷൻ ടെസ്റ്റുകളും ഉണ്ട്, അവ വളരെക്കാലം എടുക്കും. ഒരുപക്ഷേ എല്ലാ പുൾ അഭ്യർത്ഥനകൾക്കും എല്ലാ ടെസ്റ്റുകളും പ്രവർത്തിപ്പിക്കേണ്ടതില്ല. കണ്ടെത്താൻ, ഞങ്ങൾ ആഘാത വിശകലനം ഉപയോഗിക്കുന്നു.

ആഘാത വിശകലനം

ഒരു പുൾ അഭ്യർത്ഥനയിൽ, ഞങ്ങൾ git diff ശേഖരിക്കുകയും പരിഷ്കരിച്ച Gradle മൊഡ്യൂളുകൾ കണ്ടെത്തുകയും ചെയ്യുന്നു.

മാറിയ മൊഡ്യൂളുകളും അവയെ ആശ്രയിക്കുന്ന എല്ലാ മൊഡ്യൂളുകളും പരിശോധിക്കുന്ന ഇൻസ്ട്രുമെന്റേഷൻ ടെസ്റ്റുകൾ മാത്രം പ്രവർത്തിപ്പിക്കുന്നതിൽ അർത്ഥമുണ്ട്. അയൽ മൊഡ്യൂളുകൾക്കായി ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുന്നതിൽ അർത്ഥമില്ല: അവിടെയുള്ള കോഡ് മാറിയിട്ടില്ല, ഒന്നും തകർക്കാൻ കഴിയില്ല.

ഇൻസ്ട്രുമെന്റേഷൻ ടെസ്റ്റുകൾ അത്ര ലളിതമല്ല, കാരണം അവ ഉയർന്ന തലത്തിലുള്ള ആപ്ലിക്കേഷൻ മൊഡ്യൂളിൽ സ്ഥിതിചെയ്യണം. ഓരോ ടെസ്റ്റും ഏത് മൊഡ്യൂളിന്റേതാണെന്ന് മനസ്സിലാക്കാൻ ബൈറ്റ്കോഡ് വിശകലനത്തോടുകൂടിയ ഹ്യൂറിസ്റ്റിക്സ് ഞങ്ങൾ ഉപയോഗിച്ചു.

ഇൻസ്ട്രുമെന്റേഷൻ ടെസ്റ്റുകളുടെ പ്രവർത്തനം അപ്‌ഗ്രേഡ് ചെയ്യുന്നതിലൂടെ അവർ ഉൾപ്പെട്ടിരിക്കുന്ന മൊഡ്യൂളുകൾ മാത്രം പരിശോധിക്കുന്നത് ഏകദേശം എട്ട് ആഴ്ചകൾ എടുത്തു.

പരിശോധനകൾ വേഗത്തിലാക്കാനുള്ള നടപടികൾ വിജയകരമായിരുന്നു. 45 മിനിറ്റിൽ നിന്ന് ഞങ്ങൾ ഏകദേശം 15 ആയി ഉയർന്നു. ഒരു നിർമ്മാണത്തിനായി കാൽ മണിക്കൂർ കാത്തിരിക്കുന്നത് ഇതിനകം സാധാരണമാണ്.

എന്നാൽ ഇപ്പോൾ ഡെവലപ്പർമാർ ഏത് ബിൽഡുകളാണ് സമാരംഭിക്കുന്നത്, ലോഗ് എവിടെ കാണണം, എന്തുകൊണ്ടാണ് ബിൽഡ് ചുവപ്പ്, ഏത് ടെസ്റ്റ് പരാജയപ്പെട്ടു തുടങ്ങിയവ മനസ്സിലാകുന്നില്ലെന്ന് പരാതിപ്പെടാൻ തുടങ്ങിയിരിക്കുന്നു.

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

വിശദമായ പ്രതികരണങ്ങൾക്കായി ആറാഴ്ച ചെലവഴിച്ചു.

പദ്ധതികൾ

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

കൂടാതെ, മറ്റ് പദ്ധതികളും ഉണ്ട്.

• റിട്ടേൺ ലിന്റ് (മറ്റ് സ്റ്റാറ്റിക് വിശകലനം). ഞങ്ങൾ ഇതിനകം ഈ ദിശയിൽ പ്രവർത്തിക്കുന്നു.
• ഒരു PR ബ്ലോക്കറിൽ എല്ലാം പ്രവർത്തിപ്പിക്കുക എൻഡ്-ടു-എൻഡ് ടെസ്റ്റുകൾ എല്ലാ SDK പതിപ്പുകളിലും.

അതിനാൽ, Avito-യിലെ തുടർച്ചയായ സംയോജനത്തിന്റെ വികസനത്തിന്റെ ചരിത്രം ഞങ്ങൾ കണ്ടെത്തി. പരിചയസമ്പന്നനായ ഒരു വീക്ഷണകോണിൽ നിന്ന് ഇപ്പോൾ ഞാൻ ചില ഉപദേശങ്ങൾ നൽകാൻ ആഗ്രഹിക്കുന്നു.

നുറുങ്ങുകൾ

എനിക്ക് ഒരു ഉപദേശം നൽകാൻ കഴിയുമെങ്കിൽ, അത് ഇതായിരിക്കും:

ഷെൽ സ്ക്രിപ്റ്റുകളിൽ ദയവായി ശ്രദ്ധിക്കുക!

ബാഷ് വളരെ വഴക്കമുള്ളതും ശക്തവുമായ ഉപകരണമാണ്, സ്ക്രിപ്റ്റുകൾ എഴുതാൻ ഇത് വളരെ സൗകര്യപ്രദവും വേഗതയുമാണ്. എന്നാൽ നിങ്ങൾക്ക് അത് ഉപയോഗിച്ച് ഒരു കെണിയിൽ വീഴാം, നിർഭാഗ്യവശാൽ, ഞങ്ങൾ അതിൽ വീണു.

ഞങ്ങളുടെ ബിൽഡ് മെഷീനുകളിൽ പ്രവർത്തിക്കുന്ന ലളിതമായ സ്ക്രിപ്റ്റുകൾ ഉപയോഗിച്ചാണ് ഇതെല്ലാം ആരംഭിച്ചത്:

#!/usr/bin/env bash
./gradlew assembleDebug

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

അത്തരം സ്ക്രിപ്റ്റുകൾ വികസിപ്പിക്കുന്നതിനുള്ള തൊഴിൽ ചെലവ് നിങ്ങൾക്ക് ഊഹിക്കാം. ഈ കെണിയിൽ വീഴരുതെന്ന് ഞാൻ നിങ്ങളെ ഉപദേശിക്കുന്നു.

എന്താണ് മാറ്റിസ്ഥാപിക്കാൻ കഴിയുക?

• ഏതെങ്കിലും സ്ക്രിപ്റ്റിംഗ് ഭാഷ. എഴുതുക പൈത്തൺ അല്ലെങ്കിൽ കോട്ലിൻ സ്ക്രിപ്റ്റ് സ്ക്രിപ്റ്റുകളല്ല, പ്രോഗ്രാമിംഗ് ആയതിനാൽ കൂടുതൽ സൗകര്യപ്രദമാണ്.
• അല്ലെങ്കിൽ ഫോമിലെ എല്ലാ ബിൽഡ് ലോജിക്കും വിവരിക്കുക ഇഷ്‌ടാനുസൃത ഗ്രേഡിൽ ടാസ്‌ക്കുകൾ നിങ്ങളുടെ പ്രോജക്റ്റിനായി.

രണ്ടാമത്തെ ഓപ്ഷൻ തിരഞ്ഞെടുക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു, ഇപ്പോൾ ഞങ്ങൾ എല്ലാ ബാഷ് സ്ക്രിപ്റ്റുകളും വ്യവസ്ഥാപിതമായി ഇല്ലാതാക്കുകയും ധാരാളം ഇഷ്‌ടാനുസൃത ഗ്രേഡിൽ ടാസ്‌ക്കുകൾ എഴുതുകയും ചെയ്യുന്നു.

ടിപ്പ് #2: അടിസ്ഥാന സൗകര്യങ്ങൾ കോഡിൽ സംഭരിക്കുക.

തുടർച്ചയായ സംയോജന ക്രമീകരണം ജെങ്കിൻസിന്റെയോ ടീംസിറ്റിയുടെയോ യുഐ ഇന്റർഫേസിലല്ല, മറിച്ച് പ്രോജക്റ്റ് റിപ്പോസിറ്ററിയിൽ നേരിട്ട് ടെക്സ്റ്റ് ഫയലുകളുടെ രൂപത്തിൽ സംഭരിക്കുമ്പോൾ ഇത് സൗകര്യപ്രദമാണ്. ഇത് പതിപ്പ് നൽകുന്നു. മറ്റൊരു ബ്രാഞ്ചിൽ കോഡ് റോൾബാക്ക് ചെയ്യുകയോ നിർമ്മിക്കുകയോ ചെയ്യുന്നത് ബുദ്ധിമുട്ടുള്ള കാര്യമല്ല.

സ്ക്രിപ്റ്റുകൾ ഒരു പ്രോജക്റ്റിൽ സൂക്ഷിക്കാം. പരിസ്ഥിതിയുമായി എന്തുചെയ്യണം?

നുറുങ്ങ് #3: ഡോക്കറിന് പരിസ്ഥിതിയെ സഹായിക്കാനാകും.

ഇത് തീർച്ചയായും Android ഡെവലപ്പർമാരെ സഹായിക്കും; നിർഭാഗ്യവശാൽ, iOS-ന് ഇതുവരെ ഒന്നുമില്ല.

jdk, android-sdk എന്നിവ അടങ്ങുന്ന ഒരു ലളിതമായ ഡോക്കർ ഫയലിന്റെ ഉദാഹരണമാണിത്:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

ഈ ഡോക്കർ ഫയൽ എഴുതി (ഞാൻ നിങ്ങളോട് ഒരു രഹസ്യം പറയാം, നിങ്ങൾ ഇത് എഴുതേണ്ടതില്ല, പക്ഷേ അത് GitHub-ൽ നിന്ന് റെഡിമെയ്ഡ് ആയി വലിക്കുക) ഇമേജ് കൂട്ടിച്ചേർക്കുക, നിങ്ങൾക്ക് ആപ്ലിക്കേഷൻ നിർമ്മിക്കാൻ കഴിയുന്ന ഒരു വെർച്വൽ മെഷീൻ ലഭിക്കും. ഒപ്പം ജൂണിറ്റ് ടെസ്റ്റുകൾ നടത്തുക.

ഇത് അർത്ഥമാക്കുന്നതിന്റെ രണ്ട് പ്രധാന കാരണങ്ങൾ സ്കേലബിളിറ്റിയും ആവർത്തനക്ഷമതയുമാണ്. ഡോക്കർ ഉപയോഗിച്ച്, മുമ്പത്തേതിന് സമാനമായ അന്തരീക്ഷമുള്ള ഒരു ഡസൻ ബിൽഡ് ഏജന്റുമാരെ നിങ്ങൾക്ക് വേഗത്തിൽ സൃഷ്ടിക്കാൻ കഴിയും. ഇത് സിഐ എഞ്ചിനീയർമാരുടെ ജീവിതം വളരെ എളുപ്പമാക്കുന്നു. ആൻഡ്രോയിഡ്-എസ്ഡികെ ഡോക്കറിലേക്ക് തള്ളുന്നത് വളരെ എളുപ്പമാണ്, എന്നാൽ എമുലേറ്ററുകൾക്ക് ഇത് അൽപ്പം ബുദ്ധിമുട്ടാണ്: നിങ്ങൾ കുറച്ചുകൂടി കഠിനാധ്വാനം ചെയ്യേണ്ടിവരും (അല്ലെങ്കിൽ പൂർത്തിയായത് GitHub-ൽ നിന്ന് വീണ്ടും ഡൗൺലോഡ് ചെയ്യുക).

ടിപ്പ് നമ്പർ 4: പരിശോധനകൾ നടത്തുന്നത് പരിശോധനകൾക്കല്ല, മറിച്ച് ആളുകൾക്ക് വേണ്ടിയാണെന്ന് മറക്കരുത്.

ദ്രുതവും, ഏറ്റവും പ്രധാനമായി, വ്യക്തമായ ഫീഡ്‌ബാക്ക് ഡെവലപ്പർമാർക്ക് വളരെ പ്രധാനമാണ്: എന്താണ് തകർന്നത്, എന്ത് ടെസ്റ്റ് പരാജയപ്പെട്ടു, എനിക്ക് ബിൽഡ്ലോഗ് എവിടെ കാണാനാകും.

നുറുങ്ങ് #5: തുടർച്ചയായ ഏകീകരണം വികസിപ്പിക്കുമ്പോൾ പ്രായോഗികത പുലർത്തുക.

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

നുറുങ്ങ് #6: റെഡിമെയ്ഡ് ഉപകരണങ്ങൾ ഉപയോഗിക്കുക.

ക്ലൗഡ് സിഐ നൽകുന്ന നിരവധി കമ്പനികൾ ഇപ്പോൾ ഉണ്ട്.

ചെറിയ ടീമുകൾക്ക് ഇത് നല്ലൊരു പരിഹാരമാണ്. നിങ്ങൾ ഒന്നിനെയും പിന്തുണയ്ക്കേണ്ടതില്ല, കുറച്ച് പണം നൽകുക, നിങ്ങളുടെ ആപ്ലിക്കേഷൻ നിർമ്മിക്കുക, ഇൻസ്ട്രുമെന്റേഷൻ ടെസ്റ്റുകൾ നടത്തുക.

നുറുങ്ങ് #7: ഒരു വലിയ ടീമിൽ, ഇൻ-ഹൗസ് സൊല്യൂഷനുകൾ കൂടുതൽ ലാഭകരമാണ്.

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

തുടർച്ചയായ സംയോജനം ഉൾപ്പെടെ നമ്മുടെ മുഴുവൻ ജീവിതത്തെയും സാമ്പത്തിക ശാസ്ത്രം വിവരിക്കുന്നു. ഞങ്ങളുടെ തുടർച്ചയായ സംയോജനത്തിന്റെ വികസനത്തിന്റെ ഓരോ ഘട്ടത്തിനും ഞാൻ തൊഴിൽ ചെലവുകളുടെ ഒരു ഷെഡ്യൂൾ നിർമ്മിച്ചു.

ഏതൊരു പുരോഗതിയും കൂടുതൽ കൂടുതൽ ബുദ്ധിമുട്ടുള്ളതായി മാറുന്നു എന്നത് വ്യക്തമാണ്. ഈ ഗ്രാഫ് നോക്കുമ്പോൾ, ടീമിന്റെ വലുപ്പത്തിന്റെ വളർച്ചയ്ക്ക് അനുസൃതമായി തുടർച്ചയായ ഏകീകരണം വികസിപ്പിക്കേണ്ടതുണ്ടെന്ന് നിങ്ങൾക്ക് മനസ്സിലാകും. രണ്ട് ആളുകളുടെ ഒരു ടീമിന്, ഒരു ആന്തരിക എമുലേറ്റർ ഫാം വികസിപ്പിക്കുന്നതിന് 50 ദിവസം ചെലവഴിക്കുന്നത് ഒരു സാധാരണ ആശയമാണ്. എന്നാൽ അതേ സമയം, ഒരു വലിയ ടീമിനെ സംബന്ധിച്ചിടത്തോളം, തുടർച്ചയായ സംയോജനം ചെയ്യാത്തതും ഒരു മോശം ആശയമാണ്, കാരണം സംയോജന പ്രശ്നങ്ങൾ, ആശയവിനിമയം പരിഹരിക്കൽ തുടങ്ങിയവ. അതിന് കൂടുതൽ സമയമെടുക്കും.

ആളുകൾ ചെലവേറിയതും തെറ്റുകൾ വരുത്തുന്നതും മടിയന്മാരുമായതിനാൽ ഓട്ടോമേഷൻ ആവശ്യമാണ് എന്ന ആശയത്തിലാണ് ഞങ്ങൾ ആരംഭിച്ചത്. എന്നാൽ ആളുകൾ ഓട്ടോമേറ്റ് ചെയ്യുന്നു. അതിനാൽ, ഒരേ പ്രശ്നങ്ങളെല്ലാം ഓട്ടോമേഷനും ബാധകമാണ്.

• ഓട്ടോമേഷൻ ചെലവേറിയതാണ്. തൊഴിൽ ഷെഡ്യൂൾ ഓർക്കുക.
• ഓട്ടോമേഷന്റെ കാര്യത്തിൽ ആളുകൾ തെറ്റുകൾ വരുത്തുന്നു.
• ചിലപ്പോൾ അത് ഓട്ടോമേറ്റ് ചെയ്യാൻ വളരെ അലസമാണ്, കാരണം എല്ലാം അങ്ങനെ പ്രവർത്തിക്കുന്നു. എന്തിന് മറ്റെന്തെങ്കിലും മെച്ചപ്പെടുത്തണം, എന്തുകൊണ്ടാണ് ഈ തുടർച്ചയായ ഏകീകരണം?

എന്നാൽ എനിക്ക് സ്ഥിതിവിവരക്കണക്കുകൾ ഉണ്ട്: 20% അസംബ്ലികളിൽ പിശകുകൾ പിടിക്കപ്പെടുന്നു. ഞങ്ങളുടെ ഡെവലപ്പർമാർ കോഡ് മോശമായി എഴുതുന്നതുകൊണ്ടല്ല ഇത്. കാരണം, ഡെവലപ്പർമാർ എന്തെങ്കിലും തെറ്റ് വരുത്തിയാൽ, അത് ഡെവലപ്‌മെന്റിൽ അവസാനിക്കില്ല, അത് ഓട്ടോമേറ്റഡ് ചെക്കുകൾ വഴി പിടിക്കപ്പെടുമെന്ന് ഉറപ്പാണ്. അതനുസരിച്ച്, ഡെവലപ്പർമാർക്ക് പ്രാദേശികമായി എന്തെങ്കിലും പ്രവർത്തിപ്പിക്കുന്നതിനും പരിശോധിക്കുന്നതിനും പകരം കോഡുകളും രസകരമായ കാര്യങ്ങളും എഴുതാൻ കൂടുതൽ സമയം ചെലവഴിക്കാൻ കഴിയും.

തുടർച്ചയായ ഏകീകരണം പരിശീലിക്കുക. എന്നാൽ മിതമായി.

വഴിയിൽ, നിക്കോളായ് നെസ്റ്ററോവ് സ്വയം മികച്ച റിപ്പോർട്ടുകൾ നൽകുക മാത്രമല്ല, പ്രോഗ്രാം കമ്മിറ്റി അംഗവുമാണ് AppsConf നിങ്ങൾക്കായി അർത്ഥവത്തായ പ്രസംഗങ്ങൾ തയ്യാറാക്കാൻ മറ്റുള്ളവരെ സഹായിക്കുന്നു. അടുത്ത കോൺഫറൻസ് പ്രോഗ്രാമിന്റെ സമ്പൂർണ്ണതയും പ്രയോജനവും വിഷയങ്ങളാൽ വിലയിരുത്താവുന്നതാണ് പട്ടിക. വിശദവിവരങ്ങൾക്ക് ഏപ്രിൽ 22-23 തീയതികളിൽ ഇൻഫോസ്‌പേസിൽ വരൂ.

അവലംബം: www.habr.com