કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર: XP નો ઉપયોગ કરીને સમસ્યાઓ કેવી રીતે દૂર કરવી

હેલો, હેબ્ર! અગાઉ, મેં કોડ પેરાડાઈમ તરીકે ઈન્ફ્રાસ્ટ્રક્ચરમાં જીવન વિશે ફરિયાદ કરી હતી અને વર્તમાન પરિસ્થિતિને ઉકેલવા માટે કંઈપણ ઑફર કર્યું ન હતું. આજે હું તમને જણાવવા પાછો આવ્યો છું કે કયા અભિગમો અને પ્રથાઓ તમને નિરાશાના પાતાળમાંથી બહાર નીકળવામાં અને પરિસ્થિતિને યોગ્ય દિશામાં લઈ જવા માટે મદદ કરશે.

પાછલા લેખમાં "કોડ તરીકે ઇન્ફ્રાસ્ટ્રક્ચર: પ્રથમ પરિચય" મેં આ વિસ્તારની મારી છાપ શેર કરી, આ વિસ્તારની વર્તમાન પરિસ્થિતિ પર પ્રતિબિંબિત કરવાનો પ્રયાસ કર્યો, અને એવું પણ સૂચવ્યું કે તમામ વિકાસકર્તાઓ માટે જાણીતી પ્રમાણભૂત પદ્ધતિઓ મદદ કરી શકે છે. એવું લાગે છે કે જીવન વિશે ઘણી ફરિયાદો હતી, પરંતુ વર્તમાન પરિસ્થિતિમાંથી બહાર નીકળવાના માર્ગ માટે કોઈ દરખાસ્તો નથી.

આપણે કોણ છીએ, ક્યાં છીએ અને આપણને કઈ સમસ્યાઓ છે

અમે હાલમાં Sre ઑનબોર્ડિંગ ટીમમાં છીએ, જેમાં છ પ્રોગ્રામર અને ત્રણ ઇન્ફ્રાસ્ટ્રક્ચર એન્જિનિયર્સનો સમાવેશ થાય છે. અમે બધા ઇન્ફ્રાસ્ટ્રક્ચરને કોડ (IaC) તરીકે લખવાનો પ્રયાસ કરી રહ્યા છીએ. અમે આ કરીએ છીએ કારણ કે અમે મૂળભૂત રીતે જાણીએ છીએ કે કોડ કેવી રીતે લખવો અને "સરેરાશથી ઉપર" વિકાસકર્તા હોવાનો ઇતિહાસ ધરાવે છે.

• અમારી પાસે ફાયદાઓનો સમૂહ છે: ચોક્કસ પૃષ્ઠભૂમિ, પ્રેક્ટિસનું જ્ઞાન, કોડ લખવાની ક્ષમતા, નવી વસ્તુઓ શીખવાની ઇચ્છા.
• અને એક ઝૂલતો ભાગ છે, જે માઈનસ પણ છે: ઈન્ફ્રાસ્ટ્રક્ચર હાર્ડવેર વિશે જ્ઞાનનો અભાવ.

અમે અમારા IaC માં ટેક્નોલોજી સ્ટેકનો ઉપયોગ કરીએ છીએ.

• સંસાધનો બનાવવા માટે ટેરાફોર્મ.
• છબીઓ એસેમ્બલ કરવા માટે પેકર. આ Windows, CentOS 7 છબીઓ છે.
• Jsonnet drone.io માં શક્તિશાળી બિલ્ડ બનાવવા તેમજ પેકર json અને અમારા ટેરાફોર્મ મોડ્યુલ્સ જનરેટ કરવા માટે.
• નીલમ.
• ઈમેજ તૈયાર કરતી વખતે જવાબ આપવા યોગ્ય.
• સહાયક સેવાઓ અને જોગવાઈ સ્ક્રિપ્ટો માટે Python.
• અને આ બધું VSCode માં પ્લગઈન્સ સાથે ટીમના સભ્યો વચ્ચે વહેંચાયેલું છે.

મારા પરથી નિષ્કર્ષ છેલ્લો લેખ આના જેવું હતું: મેં આશાવાદ (સૌપ્રથમ મારામાં) જગાડવાનો પ્રયાસ કર્યો, હું કહેવા માંગતો હતો કે આ ક્ષેત્રમાં અસ્તિત્વમાં રહેલી મુશ્કેલીઓ અને જટિલતાઓનો સામનો કરવા માટે અમે અમને જાણીતા અભિગમો અને પ્રથાઓ અજમાવીશું.

અમે હાલમાં નીચેની IaC સમસ્યાઓ સાથે સંઘર્ષ કરી રહ્યા છીએ:

• કોડ ડેવલપમેન્ટ માટે સાધનો અને માધ્યમોની અપૂર્ણતા.
• ધીમી જમાવટ. ઈન્ફ્રાસ્ટ્રક્ચર એ વાસ્તવિક દુનિયાનો એક ભાગ છે અને તે ધીમું હોઈ શકે છે.
• અભિગમ અને વ્યવહારનો અભાવ.
• અમે નવા છીએ અને બહુ જાણતા નથી.

બચાવ માટે એક્સ્ટ્રીમ પ્રોગ્રામિંગ (XP).

બધા વિકાસકર્તાઓ એક્સ્ટ્રીમ પ્રોગ્રામિંગ (XP) અને તેની પાછળ રહેલી પ્રથાઓથી પરિચિત છે. આપણામાંના ઘણાએ આ અભિગમ સાથે કામ કર્યું છે, અને તે સફળ રહ્યું છે. તો શા માટે ઈન્ફ્રાસ્ટ્રક્ચર પડકારોને દૂર કરવા માટે ત્યાં નિર્ધારિત સિદ્ધાંતો અને પ્રથાઓનો ઉપયોગ ન કરવો? અમે આ અભિગમ અપનાવવાનું નક્કી કર્યું અને જુઓ કે શું થાય છે.

તમારા ઉદ્યોગ માટે XP અભિગમની લાગુ પડતી ચકાસણીXP જે પર્યાવરણ માટે યોગ્ય છે તેનું વર્ણન અહીં છે અને તે આપણી સાથે કેવી રીતે સંબંધિત છે:

1. ગતિશીલ રીતે બદલાતી સોફ્ટવેર આવશ્યકતાઓ. તે અમને સ્પષ્ટ હતું કે અંતિમ ધ્યેય શું છે. પરંતુ વિગતો અલગ અલગ હોઈ શકે છે. અમે જાતે જ નક્કી કરીએ છીએ કે અમારે ક્યાં ટેક્સીની જરૂર છે, તેથી જરૂરિયાતો સમયાંતરે બદલાતી રહે છે (મુખ્યત્વે આપણી જાત દ્વારા). જો આપણે SRE ટીમ લઈએ, જે ઓટોમેશન પોતે જ કરે છે અને પોતે જ કામની જરૂરિયાતો અને અવકાશને મર્યાદિત કરે છે, તો આ બિંદુ સારી રીતે બંધબેસે છે.

2. નવી ટેક્નોલોજીનો ઉપયોગ કરીને નિશ્ચિત સમયના પ્રોજેક્ટ્સને કારણે થતા જોખમો. અમને કેટલીક અજાણી વસ્તુઓનો ઉપયોગ કરતી વખતે અમે જોખમોનો સામનો કરી શકીએ છીએ. અને આ 100% અમારો કેસ છે. અમારો આખો પ્રોજેક્ટ એવી ટેક્નોલોજીનો ઉપયોગ હતો જેનાથી અમે સંપૂર્ણપણે પરિચિત ન હતા. સામાન્ય રીતે, આ એક સતત સમસ્યા છે, કારણ કે ... ઈન્ફ્રાસ્ટ્રક્ચર સેક્ટરમાં દરેક સમયે ઘણી નવી તકનીકો ઉભરી રહી છે.

3,4. નાની, સહ-સ્થિત વિસ્તૃત વિકાસ ટીમ. તમે જે સ્વચાલિત તકનીકનો ઉપયોગ કરી રહ્યાં છો તે એકમ અને કાર્યાત્મક પરીક્ષણો માટે પરવાનગી આપે છે. આ બે મુદ્દાઓ અમને તદ્દન અનુકૂળ નથી. પ્રથમ, અમે સંકલિત ટીમ નથી, અને બીજું, અમારામાંથી નવ છે, જેને મોટી ટીમ ગણી શકાય. જો કે, "મોટી" ટીમની કેટલીક વ્યાખ્યાઓ અનુસાર, ઘણી 14+ લોકો છે.

ચાલો કેટલીક XP પ્રથાઓ જોઈએ અને તે પ્રતિસાદની ઝડપ અને ગુણવત્તાને કેવી રીતે અસર કરે છે.

XP પ્રતિસાદ લૂપ સિદ્ધાંત

મારી સમજમાં, પ્રતિસાદ એ પ્રશ્નનો જવાબ છે, શું હું સાચું કરી રહ્યો છું, શું આપણે ત્યાં જઈ રહ્યા છીએ? XP પાસે આ માટે દૈવી યોજના છે: સમય પ્રતિસાદ લૂપ. રસપ્રદ બાબત એ છે કે આપણે જેટલા નીચા છીએ, તેટલી ઝડપથી આપણે જરૂરી પ્રશ્નોના જવાબ આપવા માટે OS મેળવવામાં સક્ષમ છીએ.

ચર્ચા માટે આ એક રસપ્રદ વિષય છે, કે આપણા IT ઉદ્યોગમાં ઝડપથી OS મેળવવું શક્ય છે. કલ્પના કરો કે છ મહિના સુધી કોઈ પ્રોજેક્ટ કરવું કેટલું પીડાદાયક છે અને પછી જ ખબર પડે છે કે શરૂઆતમાં જ ભૂલ હતી. આ ડિઝાઇનમાં અને જટિલ સિસ્ટમોના કોઈપણ બાંધકામમાં થાય છે.

IaC ના અમારા કિસ્સામાં, પ્રતિસાદ અમને મદદ કરે છે. હું ઉપરના ચિત્રમાં તરત જ એક નાનું ગોઠવણ કરીશ: પ્રકાશન યોજનામાં માસિક ચક્ર નથી, પરંતુ તે દિવસમાં ઘણી વખત થાય છે. આ OS ચક્ર સાથે જોડાયેલી કેટલીક પ્રથાઓ છે જેને આપણે વધુ વિગતવાર જોઈશું.

મહત્વપૂર્ણ: પ્રતિસાદ ઉપર જણાવેલ બધી સમસ્યાઓનો ઉકેલ હોઈ શકે છે. XP પ્રેક્ટિસ સાથે મળીને, તે તમને નિરાશાના પાતાળમાંથી બહાર કાઢી શકે છે.

નિરાશાના પાતાળમાંથી તમારી જાતને કેવી રીતે બહાર કાઢવી: ત્રણ પ્રથાઓ

પરીક્ષણો

XP ફીડબેક લૂપમાં ટેસ્ટનો બે વાર ઉલ્લેખ કરવામાં આવ્યો છે. એવું જ નથી. તેઓ સમગ્ર એક્સ્ટ્રીમ પ્રોગ્રામિંગ તકનીક માટે અત્યંત મહત્વપૂર્ણ છે.

એવું માનવામાં આવે છે કે તમારી પાસે એકમ અને સ્વીકૃતિ પરીક્ષણો છે. કેટલાક તમને થોડી મિનિટોમાં પ્રતિસાદ આપે છે, અન્ય થોડા દિવસોમાં, જેથી તેઓ લખવામાં વધુ સમય લે છે અને ઘણી વાર તેમની સમીક્ષા કરવામાં આવે છે.

ક્લાસિક પરીક્ષણ પિરામિડ છે, જે દર્શાવે છે કે વધુ પરીક્ષણો હોવા જોઈએ.

IaC પ્રોજેક્ટમાં આ ફ્રેમવર્ક અમને કેવી રીતે લાગુ પડે છે? ખરેખર... બિલકુલ નહીં.

• એકમ પરીક્ષણો, તે હકીકત હોવા છતાં કે તેમાં ઘણું હોવું જોઈએ, તે ઘણા બધા હોઈ શકતા નથી. અથવા તેઓ ખૂબ જ પરોક્ષ રીતે કંઈક પરીક્ષણ કરી રહ્યા છે. હકીકતમાં, અમે કહી શકીએ કે અમે તેમને બિલકુલ લખતા નથી. પરંતુ અહીં આવા પરીક્ષણો માટેની કેટલીક એપ્લિકેશનો છે જે અમે કરવા સક્ષમ હતા:
  1. jsonnet કોડ પરીક્ષણ. આ, ઉદાહરણ તરીકે, અમારી ડ્રોન એસેમ્બલી પાઇપલાઇન છે, જે એકદમ જટિલ છે. jsonnet કોડ પરીક્ષણો દ્વારા સારી રીતે આવરી લેવામાં આવે છે.
     અમે આનો ઉપયોગ કરીએ છીએ Jsonnet માટે એકમ પરીક્ષણ માળખું.
  2. સ્ક્રિપ્ટો માટે પરીક્ષણો કે જે સંસાધન શરૂ થાય ત્યારે ચલાવવામાં આવે છે. સ્ક્રિપ્ટો પાયથોનમાં લખવામાં આવે છે, અને તેથી તેના પર પરીક્ષણો લખી શકાય છે.
• પરીક્ષણોમાં રૂપરેખાંકન તપાસવું સંભવિત રીતે શક્ય છે, પરંતુ અમે તે કરતા નથી. દ્વારા સંસાધન રૂપરેખાંકન નિયમોની ચકાસણીને ગોઠવવાનું પણ શક્ય છે tflint. જો કે, ત્યાંની તપાસો ટેરાફોર્મ માટે ખૂબ જ મૂળભૂત છે, પરંતુ ઘણી ટેસ્ટ સ્ક્રિપ્ટો AWS માટે લખાયેલી છે. અને અમે Azure પર છીએ, તેથી આ ફરીથી લાગુ પડતું નથી.
• ઘટક સંકલન પરીક્ષણો: તે તમે તેમને કેવી રીતે વર્ગીકૃત કરો છો અને તમે તેમને ક્યાં મૂકશો તેના પર આધાર રાખે છે. પરંતુ તેઓ મૂળભૂત રીતે કામ કરે છે.

  એકીકરણ પરીક્ષણો આના જેવા દેખાય છે.

  
  
  ડ્રોન સીઆઈમાં છબીઓ બનાવતી વખતે આ એક ઉદાહરણ છે. તેમના સુધી પહોંચવા માટે, તમારે પેકર ઇમેજ બનવા માટે 30 મિનિટ રાહ જોવી પડશે, પછી તેમના પસાર થવા માટે બીજી 15 મિનિટ રાહ જુઓ. પરંતુ તેઓ અસ્તિત્વમાં છે!

  છબી ચકાસણી અલ્ગોરિધમનો

  1. પેકરે પ્રથમ છબીને સંપૂર્ણપણે તૈયાર કરવી આવશ્યક છે.
  2. પરીક્ષણની બાજુમાં સ્થાનિક રાજ્ય સાથેનું ટેરાફોર્મ છે, જેનો ઉપયોગ અમે આ છબીને જમાવવા માટે કરીએ છીએ.
  3. જ્યારે ખુલે છે, ત્યારે ઇમેજ સાથે કામ કરવાનું સરળ બનાવવા માટે નજીકમાં પડેલા નાના મોડ્યુલનો ઉપયોગ કરવામાં આવે છે.
  4. એકવાર ઇમેજમાંથી VM તૈનાત થઈ જાય, પછી તપાસ શરૂ થઈ શકે છે. મૂળભૂત રીતે, તપાસ કાર દ્વારા કરવામાં આવે છે. તે સ્ટાર્ટઅપ પર સ્ક્રિપ્ટ્સ કેવી રીતે કામ કરે છે અને ડિમન કેવી રીતે કામ કરે છે તે તપાસે છે. આ કરવા માટે, ssh અથવા winrm દ્વારા અમે નવા ઉભા થયેલા મશીનમાં લૉગ ઇન કરીએ છીએ અને રૂપરેખાંકન સ્થિતિ અથવા સેવાઓ ચાલુ છે કે કેમ તે તપાસીએ છીએ.

• ટેરાફોર્મ માટેના મોડ્યુલોમાં એકીકરણ પરીક્ષણો સાથે પરિસ્થિતિ સમાન છે. અહીં આવા પરીક્ષણોની વિશેષતાઓ સમજાવતું એક નાનું કોષ્ટક છે.

  
  
  પાઇપલાઇન પર પ્રતિસાદ લગભગ 40 મિનિટનો છે. બધું ખૂબ લાંબા સમય માટે થાય છે. તેનો ઉપયોગ રીગ્રેસન માટે થઈ શકે છે, પરંતુ નવા વિકાસ માટે તે સામાન્ય રીતે અવાસ્તવિક છે. જો તમે આ માટે ખૂબ જ તૈયાર છો, તો ચાલતી સ્ક્રિપ્ટો તૈયાર કરો, પછી તમે તેને 10 મિનિટ સુધી ઘટાડી શકો છો. પરંતુ આ હજુ પણ એકમ પરીક્ષણો નથી, જે 5 સેકન્ડમાં 100 ટુકડાઓ કરે છે.

ઈમેજીસ અથવા ટેરાફોર્મ મોડ્યુલોને એસેમ્બલ કરતી વખતે યુનિટ ટેસ્ટની ગેરહાજરી કામને અલગ સેવાઓમાં સ્થાનાંતરિત કરવા પ્રોત્સાહિત કરે છે જે ફક્ત REST દ્વારા અથવા પાયથોન સ્ક્રિપ્ટમાં ચલાવી શકાય છે.

ઉદાહરણ તરીકે, અમારે ખાતરી કરવાની જરૂર હતી કે જ્યારે વર્ચ્યુઅલ મશીન શરૂ થાય છે, ત્યારે તે સેવામાં પોતાને રજીસ્ટર કરે છે સ્કેલએફટી, અને જ્યારે વર્ચ્યુઅલ મશીન નાશ પામ્યું હતું, ત્યારે તે પોતે કાઢી નાખ્યું હતું.

અમારી પાસે એક સેવા તરીકે ScaleFT હોવાથી, અમને API દ્વારા તેની સાથે કામ કરવાની ફરજ પડી છે. ત્યાં એક રેપર લખેલું હતું જેને તમે ખેંચીને કહી શકો: "અંદર જાઓ અને આ અને તે કાઢી નાખો." તે તમામ જરૂરી સેટિંગ્સ અને એક્સેસ સ્ટોર કરે છે.

અમે આ માટે પહેલાથી જ સામાન્ય પરીક્ષણો લખી શકીએ છીએ, કારણ કે તે સામાન્ય સૉફ્ટવેરથી અલગ નથી: અમુક પ્રકારની અપિહાની મજાક કરવામાં આવે છે, તમે તેને ખેંચો અને જુઓ કે શું થાય છે.

પરીક્ષણોના પરિણામો: એકમ પરીક્ષણ, જે OS ને એક મિનિટમાં આપવું જોઈએ, તે આપતું નથી. અને પિરામિડમાં ઉચ્ચ પરીક્ષણના પ્રકારો અસરકારક છે, પરંતુ સમસ્યાઓના માત્ર એક ભાગને આવરી લે છે.

જોડી પ્રોગ્રામિંગ

પરીક્ષણો, અલબત્ત, સારી છે. તમે તેમાંથી ઘણું લખી શકો છો, તે વિવિધ પ્રકારના હોઈ શકે છે. તેઓ તેમના સ્તરે કામ કરશે અને અમને પ્રતિસાદ આપશે. પરંતુ ખરાબ એકમ પરીક્ષણો સાથે સમસ્યા, જે સૌથી ઝડપી OS આપે છે, તે રહે છે. તે જ સમયે, મને હજી પણ ઝડપી OS જોઈએ છે જેની સાથે કામ કરવું સરળ અને સુખદ હોય. પરિણામી ઉકેલની ગુણવત્તાનો ઉલ્લેખ ન કરવો. સદનસીબે, એવી તકનીકો છે જે એકમ પરીક્ષણો કરતાં પણ ઝડપી પ્રતિસાદ આપી શકે છે. આ જોડી પ્રોગ્રામિંગ છે.

કોડ લખતી વખતે, તમે શક્ય તેટલી ઝડપથી તેની ગુણવત્તા પર પ્રતિસાદ મેળવવા માંગો છો. હા, તમે ફીચર બ્રાન્ચમાં બધું જ લખી શકો છો (જેથી કોઈને માટે કંઈ તોડવું ન જોઈએ), ગીથબમાં પુલ રિક્વેસ્ટ કરી શકો છો, જેને કોઈના અભિપ્રાયનું વજન હોય તેને સોંપી શકો છો અને પ્રતિસાદની રાહ જોઈ શકો છો.

પરંતુ તમે લાંબા સમય સુધી રાહ જોઈ શકો છો. લોકો બધા વ્યસ્ત છે, અને જવાબ, જો ત્યાં એક હોય, તો પણ ઉચ્ચ ગુણવત્તાનો ન હોઈ શકે. ધારો કે જવાબ તરત જ આવ્યો, સમીક્ષક તરત જ આખો વિચાર સમજી ગયો, પરંતુ જવાબ હજી પણ મોડો આવે છે, હકીકત પછી. હું ઈચ્છું છું કે તે પહેલા હોત. આ તે છે જે જોડી પ્રોગ્રામિંગનો હેતુ છે - તરત જ, લેખન સમયે.

નીચે જોડી પ્રોગ્રામિંગ શૈલીઓ અને IaC પર કામ કરવા માટે તેમની લાગુ પડે છે:

1. ક્લાસિક, અનુભવી+અનુભવી, ટાઈમર દ્વારા શિફ્ટ. બે ભૂમિકાઓ - ડ્રાઇવર અને નેવિગેટર. બે માણસો. તેઓ સમાન કોડ પર કામ કરે છે અને ચોક્કસ પૂર્વનિર્ધારિત સમયગાળા પછી ભૂમિકાઓ સ્વિચ કરે છે.

ચાલો શૈલી સાથેની અમારી સમસ્યાઓની સુસંગતતાને ધ્યાનમાં લઈએ:

• સમસ્યા: કોડ ડેવલપમેન્ટ માટે સાધનો અને સાધનોની અપૂર્ણતા.
  નકારાત્મક અસર: વિકાસ થવામાં વધુ સમય લાગે છે, આપણે ધીમા પડીએ છીએ, કામની ગતિ/લય ખોવાઈ જાય છે.
  અમે કેવી રીતે લડીએ છીએ: અમે એક અલગ ટૂલિંગ, એક સામાન્ય IDE નો ઉપયોગ કરીએ છીએ અને શૉર્ટકટ પણ શીખીએ છીએ.
• સમસ્યા: ધીમી જમાવટ.
  નકારાત્મક અસર: કોડનો કાર્યકારી ભાગ બનાવવામાં જે સમય લાગે છે તે વધે છે. રાહ જોતી વખતે આપણે કંટાળી જઈએ છીએ, રાહ જોતી વખતે આપણા હાથ કંઈક બીજું કરવા માટે પહોંચે છે.
  અમે કેવી રીતે લડીએ છીએ: અમે તેના પર કાબુ મેળવ્યો નથી.
• સમસ્યા: અભિગમ અને વ્યવહારનો અભાવ.
  નકારાત્મક અસર: તેને સારી રીતે કેવી રીતે કરવું અને ખરાબ રીતે કેવી રીતે કરવું તેની કોઈ જાણકારી નથી. પ્રતિસાદની પ્રાપ્તિને લંબાવે છે.
  આપણે કેવી રીતે લડીએ છીએ: જોડીના કામમાં મંતવ્યો અને વ્યવહારનું પરસ્પર વિનિમય લગભગ સમસ્યાનું નિરાકરણ લાવે છે.

IaC માં આ શૈલીનો ઉપયોગ કરવાની મુખ્ય સમસ્યા કામની અસમાન ગતિ છે. પરંપરાગત સોફ્ટવેર ડેવલપમેન્ટમાં, તમારી પાસે ખૂબ જ સમાન હિલચાલ છે. તમે પાંચ મિનિટ ખર્ચીને N લખી શકો છો. 10 મિનિટનો ખર્ચ કરો અને 2N, 15 મિનિટ - 3N લખો. અહીં તમે પાંચ મિનિટ ફાળવી શકો છો અને N લખી શકો છો, અને પછી બીજી 30 મિનિટ પસાર કરી શકો છો અને N નો દસમો ભાગ લખી શકો છો. અહીં તમે કંઈપણ જાણતા નથી, તમે અટવાઈ ગયા છો, મૂર્ખ છો. તપાસમાં સમય લાગે છે અને પ્રોગ્રામિંગથી જ વિચલિત થાય છે.

નિષ્કર્ષ: તેના શુદ્ધ સ્વરૂપમાં તે આપણા માટે યોગ્ય નથી.

2. પિંગ-પૉંગ. આ અભિગમમાં એક વ્યક્તિ પરીક્ષણ લખે છે અને બીજી વ્યક્તિ તેના માટે અમલીકરણ કરે છે. એકમ પરીક્ષણો સાથે બધું જટિલ છે તે હકીકતને ધ્યાનમાં લેતા, અને તમારે એક સંકલન પરીક્ષણ લખવું પડશે જેમાં પ્રોગ્રામિંગનો ઘણો સમય લાગે છે, પિંગ-પૉંગની બધી સરળતા દૂર થઈ જાય છે.

હું કહી શકું છું કે અમે ટેસ્ટ સ્ક્રિપ્ટ ડિઝાઇન કરવા અને તેના માટે કોડ લાગુ કરવા માટે જવાબદારીઓને અલગ કરવાનો પ્રયાસ કર્યો છે. એક સહભાગી સ્ક્રિપ્ટ સાથે આવ્યો, કામના આ ભાગમાં તે જવાબદાર હતો, તેની પાસે છેલ્લો શબ્દ હતો. અને બીજા અમલીકરણ માટે જવાબદાર હતા. તે સારી રીતે કામ કર્યું. આ અભિગમ સાથે સ્ક્રિપ્ટની ગુણવત્તા વધે છે.

નિષ્કર્ષ: અરે, કામની ગતિ IaC માં જોડી પ્રોગ્રામિંગ પ્રેક્ટિસ તરીકે પિંગ-પૉંગનો ઉપયોગ કરવાની મંજૂરી આપતી નથી.

3. મજબૂત શૈલી. મુશ્કેલ પ્રેક્ટિસ. વિચાર એ છે કે એક સહભાગી ડાયરેક્ટિવ નેવિગેટર બને છે, અને બીજો એક્ઝેક્યુશન ડ્રાઇવરની ભૂમિકા લે છે. આ કિસ્સામાં, નિર્ણય લેવાનો અધિકાર ફક્ત નેવિગેટર પાસે છે. ડ્રાઇવર ફક્ત છાપે છે અને શબ્દ વડે શું થઈ રહ્યું છે તેને પ્રભાવિત કરી શકે છે. ભૂમિકાઓ લાંબા સમય સુધી બદલાતી નથી.

શીખવા માટે સારું છે, પરંતુ મજબૂત નરમ કૌશલ્યની જરૂર છે. આ તે છે જ્યાં અમે ખોવાઈ ગયા. તકનીક મુશ્કેલ હતી. અને તે ઇન્ફ્રાસ્ટ્રક્ચર વિશે પણ નથી.

નિષ્કર્ષ: તેનો સંભવિત ઉપયોગ કરી શકાય છે, અમે પ્રયાસ કરવાનું છોડી રહ્યા નથી.

4. મોબિંગ, સ્વોર્મિંગ અને બધી જાણીતી પરંતુ સૂચિબદ્ધ શૈલીઓ અમે તેને ધ્યાનમાં લેતા નથી, કારણ કે અમે તેનો પ્રયાસ કર્યો નથી અને અમારા કાર્યના સંદર્ભમાં તેના વિશે વાત કરવી અશક્ય છે.

જોડી પ્રોગ્રામિંગનો ઉપયોગ કરવાના સામાન્ય પરિણામો:

• અમારી પાસે કામની અસમાન ગતિ છે, જે મૂંઝવણભરી છે.
• અમે અપૂરતી સારી સોફ્ટ સ્કિલ્સમાં દોડી ગયા. અને વિષય વિસ્તાર આપણી આ ખામીઓને દૂર કરવામાં મદદ કરતું નથી.
• લાંબા પરીક્ષણો અને ટૂલ્સ સાથેની સમસ્યાઓ જોડી વિકાસને મુશ્કેલ બનાવે છે.

5. આ હોવા છતાં, ત્યાં સફળતાઓ હતી. અમે અમારી પોતાની પદ્ધતિ "કન્વર્જન્સ - ડાયવર્જન્સ" લઈને આવ્યા છીએ. હું સંક્ષિપ્તમાં વર્ણન કરીશ કે તે કેવી રીતે કાર્ય કરે છે.

અમારી પાસે થોડા દિવસો (એક અઠવાડિયા કરતાં ઓછા) માટે કાયમી ભાગીદારો છે. અમે એક સાથે એક કાર્ય કરીએ છીએ. અમે થોડા સમય માટે સાથે બેસીએ છીએ: એક લખે છે, બીજો બેસે છે અને સપોર્ટ ટીમને જુએ છે. પછી આપણે થોડા સમય માટે વિખેરાઈ જઈએ છીએ, દરેક કેટલીક સ્વતંત્ર વસ્તુઓ કરે છે, પછી આપણે ફરીથી એકસાથે આવીએ છીએ, ખૂબ જ ઝડપથી સુમેળ કરીએ છીએ, કંઈક સાથે મળીને કરીએ છીએ અને પછી ફરીથી વિખેરાઈ જઈએ છીએ.

આયોજન અને સંચાર

પ્રેક્ટિસનો છેલ્લો બ્લોક કે જેના દ્વારા OS સમસ્યાઓ હલ કરવામાં આવે છે તે કાર્યો સાથે કામનું સંગઠન છે. આમાં અનુભવનું વિનિમય પણ સામેલ છે જે જોડીના કામની બહાર છે. ચાલો ત્રણ પ્રથાઓ જોઈએ:

1. ધ્યેય વૃક્ષ દ્વારા ઉદ્દેશ્યો. અમે એક વૃક્ષ દ્વારા પ્રોજેક્ટના સમગ્ર સંચાલનનું આયોજન કર્યું છે જે ભવિષ્યમાં અવિરતપણે જાય છે. તકનીકી રીતે, ટ્રેકિંગ મીરોમાં કરવામાં આવે છે. ત્યાં એક કાર્ય છે - તે મધ્યવર્તી લક્ષ્ય છે. તેમાંથી કાં તો નાના લક્ષ્યો અથવા કાર્યોના જૂથો પર જાઓ. કાર્યો પોતે તેમની પાસેથી આવે છે. તમામ કાર્યો આ બોર્ડ પર બનાવવામાં આવે છે અને જાળવવામાં આવે છે.

આ સ્કીમ પ્રતિસાદ પણ આપે છે, જે દિવસમાં એકવાર થાય છે જ્યારે આપણે રેલીઓમાં સુમેળ કરીએ છીએ. દરેકની સામે એક સામાન્ય યોજના રાખવાથી, પરંતુ સંરચિત અને સંપૂર્ણ રીતે ખુલ્લું હોવું, દરેકને શું થઈ રહ્યું છે અને આપણે કેટલી પ્રગતિ કરી છે તે વિશે જાગૃત રહેવાની મંજૂરી આપે છે.

કાર્યોની દ્રશ્ય દ્રષ્ટિના ફાયદા:

• કાર્યકારણ. દરેક કાર્ય અમુક વૈશ્વિક ધ્યેય તરફ દોરી જાય છે. કાર્યોને નાના ધ્યેયોમાં જૂથબદ્ધ કરવામાં આવે છે. ઈન્ફ્રાસ્ટ્રક્ચર ડોમેન પોતે તદ્દન તકનીકી છે. તે હંમેશા તરત જ સ્પષ્ટ થતું નથી કે કઈ ચોક્કસ અસર થાય છે, ઉદાહરણ તરીકે, અન્ય nginx માં સ્થળાંતર કરવા પર રનબુક લખવાથી વ્યવસાય પર શું અસર પડે છે. નજીકમાં લક્ષ્ય કાર્ડ રાખવાથી તે સ્પષ્ટ થાય છે.
  
  કાર્યકારણ એ સમસ્યાઓની મહત્વપૂર્ણ મિલકત છે. તે આ પ્રશ્નનો સીધો જવાબ આપે છે: "શું હું સાચું કરી રહ્યો છું?"
• સમાંતરવાદ. આપણામાંના નવ છે, અને દરેકને એક કાર્ય પર ફેંકવું શારીરિક રીતે અશક્ય છે. એક ક્ષેત્રના કાર્યો હંમેશા પૂરતા ન પણ હોય. અમને નાના કાર્યકારી જૂથો વચ્ચે સમાંતર કામ કરવાની ફરજ પડી છે. તે જ સમયે, જૂથો થોડા સમય માટે તેમના કાર્ય પર બેસે છે, તેઓને કોઈ બીજા દ્વારા મજબૂત કરી શકાય છે. કેટલીકવાર લોકો આ કાર્યકારી જૂથમાંથી દૂર થઈ જાય છે. કોઈ વેકેશન પર જાય છે, કોઈ DevOps કોન્ફ માટે રિપોર્ટ બનાવે છે, કોઈ Habr પર લેખ લખે છે. શું લક્ષ્યો અને કાર્યો સમાંતર રીતે કરી શકાય છે તે જાણવું ખૂબ જ મહત્વપૂર્ણ બની જાય છે.

2. સવારની સભાઓના ફેરબદલી પ્રસ્તુતકર્તાઓ. સ્ટેન્ડ-અપ પર અમને આ સમસ્યા છે - લોકો સમાંતર ઘણા કાર્યો કરે છે. કેટલીકવાર કાર્યો ઢીલી રીતે જોડાયેલા હોય છે અને કોણ શું કરી રહ્યું છે તેની કોઈ સમજણ હોતી નથી. અને ટીમના અન્ય સભ્યનો અભિપ્રાય ખૂબ જ મહત્વપૂર્ણ છે. આ વધારાની માહિતી છે જે સમસ્યાના ઉકેલના માર્ગને બદલી શકે છે. અલબત્ત, સામાન્ય રીતે તમારી સાથે કોઈ હોય છે, પરંતુ સલાહ અને ટીપ્સ હંમેશા ઉપયોગી છે.

આ પરિસ્થિતિને સુધારવા માટે, અમે "ચેન્જિંગ ધ લીડિંગ સ્ટેન્ડ-અપ" તકનીકનો ઉપયોગ કર્યો. હવે તેઓ ચોક્કસ સૂચિ અનુસાર ફેરવાય છે, અને આ તેની અસર ધરાવે છે. જ્યારે તમારો વારો હોય, ત્યારે સારી સ્ક્રમ મીટિંગ ચલાવવા માટે તમારે અંદર ડૂબકી મારવાની અને શું ચાલી રહ્યું છે તે સમજવાની ફરજ પાડવામાં આવે છે.

3. આંતરિક ડેમો. જોડી પ્રોગ્રામિંગથી સમસ્યા ઉકેલવામાં મદદ, સમસ્યાના વૃક્ષ પર વિઝ્યુલાઇઝેશન અને સવારે સ્ક્રમ મીટિંગ્સમાં મદદ સારી છે, પરંતુ આદર્શ નથી. દંપતી તરીકે, તમે ફક્ત તમારા જ્ઞાન દ્વારા મર્યાદિત છો. ટાસ્ક ટ્રી વૈશ્વિક સ્તરે સમજવામાં મદદ કરે છે કે કોણ શું કરી રહ્યું છે. અને સવારની મીટિંગમાં પ્રસ્તુતકર્તા અને સહકર્મીઓ તમારી સમસ્યાઓમાં ઊંડા ઉતરશે નહીં. તેઓ ચોક્કસપણે કંઈક ચૂકી શકે છે.

એકબીજાને કરેલા કામનું નિદર્શન અને પછી ચર્ચા કરીને ઉકેલ મળી ગયો. અમે અઠવાડિયામાં એકવાર એક કલાક માટે મળીએ છીએ અને છેલ્લા અઠવાડિયામાં અમે કરેલા કાર્યોના ઉકેલોની વિગતો બતાવીએ છીએ.

નિદર્શન દરમિયાન, કાર્યની વિગતો જાહેર કરવી અને તેની કામગીરી દર્શાવવાની ખાતરી કરવી જરૂરી છે.

રિપોર્ટ ચેકલિસ્ટનો ઉપયોગ કરીને હાથ ધરવામાં આવી શકે છે.1. સંદર્ભમાં દાખલ કરો. કાર્ય ક્યાંથી આવ્યું, તે શા માટે જરૂરી હતું?

2. પહેલાં સમસ્યા કેવી રીતે હલ કરવામાં આવી હતી? ઉદાહરણ તરીકે, મોટા પાયે માઉસ ક્લિક કરવું જરૂરી હતું, અથવા કંઈપણ કરવું અશક્ય હતું.

3. અમે તેને કેવી રીતે સુધારીએ છીએ. ઉદાહરણ તરીકે: "જુઓ, હવે સ્ક્રિપ્ટોસિક છે, અહીં રીડમી છે."

4. તે કેવી રીતે કામ કરે છે તે બતાવો. કેટલાક વપરાશકર્તા દૃશ્યને સીધા અમલમાં મૂકવાની સલાહ આપવામાં આવે છે. મારે X જોઈએ છે, હું Y કરું છું, હું Y (અથવા Z) જોઉં છું. ઉદાહરણ તરીકે, હું NGINX નો ઉપયોગ કરું છું, url ધૂમ્રપાન કરું છું અને 200 OK મેળવું છું. જો ક્રિયા લાંબી હોય, તો તેને અગાઉથી તૈયાર કરો જેથી તમે તેને પછીથી બતાવી શકો. જો તે નાજુક હોય તો ડેમોના એક કલાક પહેલા તેને વધુ પડતું ન તોડવાની સલાહ આપવામાં આવે છે.

5. સમજાવો કે સમસ્યા કેટલી સફળતાપૂર્વક હલ થઈ, કઈ મુશ્કેલીઓ રહે છે, શું પૂર્ણ થયું નથી, ભવિષ્યમાં કયા સુધારાઓ શક્ય છે. ઉદાહરણ તરીકે, હવે CLI, પછી CI માં સંપૂર્ણ ઓટોમેશન હશે.

દરેક સ્પીકર માટે તેને 5-10 મિનિટ સુધી રાખવાની સલાહ આપવામાં આવે છે. જો તમારું ભાષણ દેખીતી રીતે મહત્વપૂર્ણ છે અને તેમાં વધુ સમય લાગશે, તો sre-ટેકઓવર ચેનલમાં અગાઉથી તેનું સંકલન કરો.

સામ-સામે ભાગ પછી હંમેશા થ્રેડમાં ચર્ચા થાય છે. આ તે છે જ્યાં અમને અમારા કાર્યો પર જરૂરી પ્રતિસાદ દેખાય છે.

પરિણામે, શું થઈ રહ્યું છે તેની ઉપયોગિતા નક્કી કરવા માટે એક સર્વે હાથ ધરવામાં આવે છે. આ ભાષણના સાર અને કાર્યના મહત્વ પર પ્રતિસાદ છે.

લાંબા તારણો અને આગળ શું છે

એવું લાગે છે કે લેખનો સ્વર કંઈક અંશે નિરાશાવાદી છે. આ ખોટું છે. પ્રતિસાદના બે નીચલા સ્તર, એટલે કે પરીક્ષણો અને જોડી પ્રોગ્રામિંગ, કાર્ય. પરંપરાગત વિકાસની જેમ સંપૂર્ણ નથી, પરંતુ તેની સકારાત્મક અસર છે.

પરીક્ષણો, તેમના વર્તમાન સ્વરૂપમાં, માત્ર આંશિક કોડ કવરેજ પ્રદાન કરે છે. ઘણા રૂપરેખાંકન કાર્યો ચકાસાયેલ નથી. કોડ લખતી વખતે વાસ્તવિક કાર્ય પર તેમનો પ્રભાવ ઓછો હોય છે. જો કે, એકીકરણ પરીક્ષણોની અસર છે, અને તે તમને નિર્ભયપણે રિફેક્ટરિંગ હાથ ધરવા દે છે. આ એક મોટી સિદ્ધિ છે. ઉપરાંત, ઉચ્ચ-સ્તરની ભાષાઓમાં (અમારી પાસે પાયથોન છે, જાઓ) વિકાસ તરફ ધ્યાન કેન્દ્રિત કરવાથી, સમસ્યા દૂર થઈ જાય છે. અને તમારે "ગુંદર" માટે ઘણા બધા ચેકની જરૂર નથી; સામાન્ય એકીકરણ તપાસ પૂરતી છે.

જોડીમાં કામ કરવું એ ચોક્કસ લોકો પર વધુ આધાર રાખે છે. ટાસ્ક ફેક્ટર અને અમારી સોફ્ટ સ્કિલ છે. કેટલાક લોકો સાથે તે ખૂબ જ સારી રીતે કામ કરે છે, અન્ય લોકો સાથે તે વધુ ખરાબ કામ કરે છે. આનાથી ચોક્કસ લાભ થાય છે. તે સ્પષ્ટ છે કે જો જોડીના કામના નિયમોનું પૂરતું પાલન કરવામાં ન આવે તો પણ, એકસાથે કાર્યો કરવાની હકીકત પરિણામની ગુણવત્તા પર સકારાત્મક અસર કરે છે. વ્યક્તિગત રીતે, મને જોડીમાં કામ કરવાનું સરળ અને વધુ આનંદપ્રદ લાગે છે.

OS ને પ્રભાવિત કરવાની ઉચ્ચ-સ્તરની રીતો - કાર્યોનું આયોજન અને કાર્ય ચોક્કસ રીતે અસરો પેદા કરે છે: ઉચ્ચ ગુણવત્તાની જ્ઞાનનું વિનિમય અને સુધારેલ વિકાસ ગુણવત્તા.

એક લીટીમાં ટૂંકા તારણો

• એચઆર પ્રેક્ટિશનરો IaC માં કામ કરે છે, પરંતુ ઓછી કાર્યક્ષમતા સાથે.
• જે કામ કરે છે તેને મજબૂત બનાવો.
• તમારી પોતાની વળતરની પદ્ધતિઓ અને પદ્ધતિઓ સાથે આવો.

સોર્સ: www.habr.com