અભ્યાસક્રમના વિદ્યાર્થીઓ માટે તૈયાર કરેલ લેખનો અનુવાદ "DevOps પ્રેક્ટિસ અને ટૂલ્સ" OTUS શૈક્ષણિક પ્રોજેક્ટમાં.

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

શા માટે આપણે આ વિશે વાત કરી રહ્યા છીએ?

મેટ ક્લેઇને લેખ લખ્યો "મોનોરેપોસ: કૃપા કરીને ના કરો!"  (અનુવાદકની નોંધ: Habré પર અનુવાદ "મોનોરેપોઝિટરીઝ: કૃપા કરીને ના કરો"). મને મેટ ગમે છે, મને લાગે છે કે તે ખૂબ જ સ્માર્ટ છે અને તમારે તેનો દૃષ્ટિકોણ વાંચવો જોઈએ. તેણે મૂળરૂપે ટ્વિટર પર મતદાન પોસ્ટ કર્યું હતું:

અનુવાદ:
આ નવા વર્ષના દિવસે, હું કેટલી હાસ્યાસ્પદ મોનોરેપોઝિટરીઝ છે તે વિશે દલીલ કરવા જઈ રહ્યો છું. 2019ની શરૂઆત શાંતિથી થઈ. આની ભાવનામાં, હું તમને એક સર્વે ઓફર કરું છું. મોટા કટ્ટરપંથીઓ કોણ છે? સમર્થકો:
- મોનોરેપો
- કાટ
- ખોટો મતદાન / બંને

મારો પ્રતિભાવ હતો, "હું શાબ્દિક રીતે તે બંને લોકો છું." રસ્ટ કેવી રીતે દવા છે તે વિશે વાત કરવાને બદલે, ચાલો જોઈએ કે શા માટે મને લાગે છે કે તે મોનોરેપોઝિટરીઝ વિશે ખોટું છે. તમારા વિશે થોડુંક. હું શેફ સૉફ્ટવેરનો CTO છું. અમારી પાસે લગભગ 100 એન્જિનિયરો છે, કોડ બેઝ લગભગ 11-12 વર્ષ પાછળનો છે અને 4 મુખ્ય ઉત્પાદનો છે. આ કોડમાંથી અમુક પોલીરેપોઝીટરીમાં છે (મારી શરૂઆતની સ્થિતિ), અમુક મોનોરેપોઝીટરીમાં છે (મારી વર્તમાન સ્થિતિ).

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

હું મેટના મુદ્દાના પ્રથમ ભાગ સાથે સંમત છું:

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

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

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

• કોડબેઝ વિશાળ છે - મને આ બધા જંકની જરૂર નથી.
• તે ચકાસવું મુશ્કેલ છે કારણ કે મારે આ બધા જંકનું પરીક્ષણ કરવું પડશે જેની મને જરૂર નથી.
• બાહ્ય અવલંબન સાથે કામ કરવું વધુ મુશ્કેલ છે.
• મને મારી પોતાની વર્ચ્યુઅલ વર્ચ્યુઅલ કંટ્રોલ સિસ્ટમ્સની જરૂર છે.

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

તે સંચાર ઉશ્કેરે છે અને સમસ્યાઓ દર્શાવે છે

જ્યારે આપણે રિપોઝીટરીઝને અલગ કરીએ છીએ, ત્યારે અમે સંકલન અને પારદર્શિતાની વાસ્તવિક સમસ્યા ઊભી કરીએ છીએ. આ અમે ટીમો વિશે જે રીતે વિચારીએ છીએ તેને અનુરૂપ છે (ખાસ કરીને વ્યક્તિગત સભ્યો તેમના વિશે જે રીતે વિચારે છે): અમે ચોક્કસ ઘટક માટે જવાબદાર છીએ. અમે સંબંધિત એકલતામાં કામ કરીએ છીએ. મારી ટીમ અને અમે જેના પર કામ કરી રહ્યા છીએ તેના પર સીમાઓ નિશ્ચિત છે.

જેમ જેમ આર્કિટેક્ચર વધુ જટિલ બનતું જાય છે, એક ટીમ હવે તેને એકલા મેનેજ કરી શકશે નહીં. બહુ ઓછા એન્જિનિયરો પાસે સમગ્ર સિસ્ટમ તેમના માથામાં હોય છે. ચાલો કહીએ કે તમે એક શેર કરેલ ઘટક A ને મેનેજ કરો છો જેનો ઉપયોગ ટીમ B, C અને D દ્વારા કરવામાં આવે છે. ટીમ A રિફેક્ટીંગ કરી રહી છે, API ને સુધારી રહી છે અને આંતરિક અમલીકરણને પણ બદલી રહી છે. પરિણામે, ફેરફારો પાછળની તરફ સુસંગત નથી. તમારી પાસે શું સલાહ છે?

• જૂના API નો ઉપયોગ થાય છે તે તમામ સ્થાનો શોધો.
• શું એવી જગ્યાઓ છે જ્યાં નવા API નો ઉપયોગ કરી શકાતો નથી?
• શું તમે અન્ય ઘટકોને તૂટે નહીં તેની ખાતરી કરવા માટે તેને ઠીક અને પરીક્ષણ કરી શકો છો?
• શું આ ટીમો અત્યારે તમારા ફેરફારોનું પરીક્ષણ કરી શકે છે?

મહેરબાની કરીને નોંધ કરો કે આ પ્રશ્નો રીપોઝીટરી પ્રકારથી સ્વતંત્ર છે. તમારે B, C અને D ટીમો શોધવાની જરૂર પડશે. તમારે તેમની સાથે વાત કરવાની, સમય શોધવાની, તેમની પ્રાથમિકતાઓને સમજવાની જરૂર પડશે. ઓછામાં ઓછું અમને આશા છે કે તમે કરશો.

કોઈ ખરેખર આ કરવા માંગતું નથી. માત્ર ડામ API ને ઠીક કરવા કરતાં આ ઘણી ઓછી મજા છે. તે બધું માનવીય અને અવ્યવસ્થિત છે. પોલીરેપોઝીટરીમાં, તમે ફક્ત ફેરફારો કરી શકો છો, તે ઘટક (કદાચ B, C અથવા D નહીં) પર કામ કરતા લોકોને સમીક્ષા માટે આપી શકો છો અને આગળ વધો. ટીમ B, C અને D હમણાં માટે તેમના વર્તમાન સંસ્કરણ સાથે રહી શકે છે. જ્યારે તેઓ તમારી પ્રતિભાનો અહેસાસ કરશે ત્યારે તેઓ નવીકરણ કરવામાં આવશે!

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

પછી આપણે આ પરિસ્થિતિમાંથી કેવી રીતે બહાર નીકળીશું તે વિશે વાત કરવી પડશે:

1. બહુવિધ આંતરિક API માટે સપોર્ટ, અને જ્યાં સુધી D તેનો ઉપયોગ કરવાનું બંધ ન કરે ત્યાં સુધી જૂના અલ્ગોરિધમને નાપસંદ તરીકે ચિહ્નિત કરશે.
2. બહુવિધ પ્રકાશન સંસ્કરણો માટે સપોર્ટ, એક જૂના ઇન્ટરફેસ સાથે, એક નવા સાથે.
3. A ના ફેરફારોને રિલીઝ કરવામાં વિલંબ કરો જ્યાં સુધી B, C અને D તેને એકસાથે સ્વીકારી ન શકે.

ચાલો કહીએ કે અમે 1, ઘણા API પસંદ કર્યા છે. આ કિસ્સામાં અમારી પાસે કોડના બે ટુકડા છે. જૂના અને નવા. કેટલીક પરિસ્થિતિઓમાં તદ્દન અનુકૂળ. અમે જૂના કોડને ફરીથી તપાસીએ છીએ, તેને નાપસંદ તરીકે ચિહ્નિત કરીએ છીએ અને ડી ટીમ સાથે દૂર કરવાના સમયપત્રક પર સંમત છીએ. પોલી અને મોનો રિપોઝીટરીઝ માટે આવશ્યકપણે સમાન.

બહુવિધ સંસ્કરણો પ્રકાશિત કરવા માટે, અમને એક શાખાની જરૂર છે. હવે આપણી પાસે બે ઘટકો છે - A1 અને A2. ટીમ B અને C A2 નો ઉપયોગ કરે છે અને D A1 નો ઉપયોગ કરે છે. અમારે દરેક ઘટકને પ્રકાશન માટે તૈયાર રાખવાની જરૂર છે કારણ કે ડી આગળ વધી શકે તે પહેલાં સુરક્ષા અપડેટ્સ અને અન્ય બગ ફિક્સેસની જરૂર પડી શકે છે. પોલીરેપોઝીટરીમાં, આપણે આને લાંબા સમય સુધી જીવતી શાખામાં છુપાવી શકીએ છીએ જે સારી લાગે છે. મોનોરેપોઝિટરીમાં, અમે કોડને નવા મોડ્યુલમાં બનાવવા માટે દબાણ કરીએ છીએ. ટીમ ડીએ હજુ પણ "જૂના" ઘટકમાં ફેરફાર કરવા પડશે. અમે અહીં જે કિંમત ચૂકવી રહ્યા છીએ તે દરેક વ્યક્તિ જોઈ શકે છે - અમારી પાસે હવે બમણા કોડ છે, અને કોઈપણ બગ ફિક્સેસ કે જે A1 અને A2 પર લાગુ થાય છે તે બંને પર લાગુ થવું આવશ્યક છે. પોલીરેપોઝીટરીમાં શાખાઓના અભિગમ સાથે, આ ચેરી-પિક પાછળ છુપાયેલ છે. અમે કિંમતને ઓછી ગણીએ છીએ કારણ કે ત્યાં કોઈ ડુપ્લિકેશન નથી. વ્યવહારિક દૃષ્ટિકોણથી, કિંમત સમાન છે: જ્યાં સુધી તમે તેમાંના એકને કાઢી ન શકો ત્યાં સુધી તમે બે મોટા પ્રમાણમાં સમાન કોડબેસેસ બનાવશો, રિલીઝ કરશો અને જાળવશો. તફાવત એ છે કે મોનોરેપોઝીટરી સાથે આ પીડા સીધી અને દૃશ્યમાન છે. આ વધુ ખરાબ છે, અને તે સારું છે.

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

મોનોરેપોઝિટરીમાં, ત્રીજો ખરેખર વિકલ્પ નથી. તમારે બેમાંથી એક રીતે પરિસ્થિતિનો સામનો કરવાની ફરજ પડી છે. તમારે બે પ્રકાશન શાખાઓ રાખવાના ખર્ચ જોવાની જરૂર છે. પછાત સુસંગતતાને તોડતા અપડેટ્સથી પોતાને બચાવવાનું શીખો. પરંતુ સૌથી અગત્યનું: તમે મુશ્કેલ વાતચીત કરવાનું ટાળી શકતા નથી.

મારા અનુભવમાં, જ્યારે ટીમો મોટી થાય છે, ત્યારે આખી સિસ્ટમને ધ્યાનમાં રાખવી શક્ય નથી, અને તે સૌથી મહત્વપૂર્ણ ભાગ છે. તમારે સિસ્ટમમાં વિસંગતતાની દૃશ્યતામાં સુધારો કરવો આવશ્યક છે. તમારે ટીમોને તેમના ઘટકોથી દૂર જોવા અને અન્ય ટીમો અને ગ્રાહકોના કાર્યને જોવા માટે સક્રિયપણે કાર્ય કરવું આવશ્યક છે.

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

ફક્ત નોંધાયેલા વપરાશકર્તાઓ જ સર્વેમાં ભાગ લઈ શકે છે. સાઇન ઇન કરો, મહેરબાની કરીને.

સૌથી મોટા કટ્ટરપંથી કોણ છે? સમર્થકો:

• મોનોરેપો

• કાટ

• ખોટો મતદાન / બંને

33 વપરાશકર્તાઓએ મત ​​આપ્યો. 13 વપરાશકર્તાઓ દૂર રહ્યા.

સોર્સ: www.habr.com