DevOps કોણ છે અને ક્યારે તેની જરૂર નથી?

DevOps છેલ્લા કેટલાક વર્ષોમાં ખૂબ જ લોકપ્રિય વિષય બની ગયો છે. ઘણા લોકો તેમાં જોડાવાનું સ્વપ્ન જુએ છે, પરંતુ, પ્રેક્ટિસ બતાવે છે તેમ, ઘણીવાર ફક્ત પગારના સ્તરને કારણે.

કેટલાક લોકો તેમના રેઝ્યૂમેમાં DevOps ની યાદી આપે છે, જો કે તેઓ હંમેશા આ શબ્દના સારને જાણતા નથી અથવા સમજી શકતા નથી. કેટલાક લોકો વિચારે છે કે Ansible, GitLab, Jenkins, Terraform અને જેમનો અભ્યાસ કર્યા પછી (સૂચિ તમારા સ્વાદ અનુસાર ચાલુ રાખી શકાય છે), તમે તરત જ "deopsist" બની જશો. આ, અલબત્ત, સાચું નથી.

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

DevOps કોણ છે

લેખ લખવાનો વિચાર બીજા પ્રશ્ન પછી આવ્યો: "દેવઓપ્સ કોણ છે?" તે શું છે અથવા કોણ છે તે માટે હજુ પણ કોઈ સ્થાપિત શબ્દ નથી. કેટલાક જવાબો આમાં પહેલેથી જ છે видео. પ્રથમ, હું તેમાંથી મુખ્ય મુદ્દાઓને પ્રકાશિત કરીશ, અને પછી હું મારા અવલોકનો અને વિચારો શેર કરીશ.

DevOps એવા નિષ્ણાત નથી કે જેને નોકરી પર રાખી શકાય, ઉપયોગિતાઓનો સમૂહ નથી, અને એન્જિનિયરો સાથેના વિકાસકર્તાઓનો વિભાગ નથી.

DevOps એક ફિલસૂફી અને પદ્ધતિ છે.

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

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

DevOps ના લક્ષ્યોને ત્રણ મુદ્દાઓમાં વર્ણવી શકાય છે:

• સોફ્ટવેર નિયમિતપણે અપડેટ થવું જોઈએ.
• સૉફ્ટવેર ઝડપથી થવું જોઈએ.
• સૉફ્ટવેરને અનુકૂળ અને ટૂંકા સમયમાં જમાવવું જોઈએ.

DevOps માટે કોઈ એક સાધન નથી. ઘણા ઉત્પાદનોને ગોઠવવા, પહોંચાડવા અને અભ્યાસ કરવાનો અર્થ એ નથી કે DevOps કંપનીમાં દેખાયા છે. ત્યાં ઘણા બધા સાધનો છે અને તે બધાનો ઉપયોગ વિવિધ તબક્કામાં થાય છે, પરંતુ એક સામાન્ય હેતુ પૂરો પાડે છે.

અને આ DevOps ટૂલ્સનો માત્ર એક ભાગ છે

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

ઇન્ટરવ્યુના અનુભવમાંથી, હું નીચેનું ચિત્ર જોઉં છું: જે નિષ્ણાતો DevOps ને નોકરીનું શીર્ષક માને છે તેઓને સામાન્ય રીતે સહકર્મીઓ સાથે ગેરસમજ હોય ​​છે.

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

પછી મેં તેમને એક પ્રશ્ન પૂછ્યો જે દરેક ઉમેદવાર માટે મારી યાદીમાં ઉચ્ચ છે.

— તમારા માટે વ્યક્તિગત રીતે DevOps નો અર્થ શું છે?
- સામાન્ય રીતે અથવા હું તેને કેવી રીતે સમજી શકું?

મને તેમના અંગત અભિપ્રાયમાં રસ હતો. તે શબ્દનો સિદ્ધાંત અને મૂળ જાણતો હતો, પરંતુ તે તેમની સાથે સખત અસંમત હતો. તેઓ માનતા હતા કે DevOps નોકરીનું શીર્ષક છે. તેની સમસ્યાઓનું મૂળ અહીં જ છે. તેમજ સમાન અભિપ્રાય સાથે અન્ય નિષ્ણાતો.

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

DevOps પદ્ધતિ અને ફિલસૂફી

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

DevOps પદ્ધતિ એ લક્ષ્યો હાંસલ કરવા માટેનું એક સાધન છે.

હવે DevOps ફિલસૂફી શું છે તે વિશે. અને આ કદાચ સૌથી મુશ્કેલ પ્રશ્ન છે.

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

મારી યુનિવર્સિટીમાં આવો કોઈ વિષય ન હતો, 90 ના દાયકામાં મને જે સામગ્રી મળી હતી તેનો ઉપયોગ કરીને મારે જાતે બધું જ અભ્યાસ કરવાનું હતું. ઇજનેરી શિક્ષણ માટે વિષય વૈકલ્પિક છે, તેથી જવાબની ઔપચારિકતાનો અભાવ છે. પરંતુ તે લોકો કે જેઓ ગંભીરતાથી DevOps માં ડૂબી ગયા છે તેઓ કંપનીની બધી પ્રક્રિયાઓની ચોક્કસ "ભાવના" અથવા "બેભાન વ્યાપકતા" અનુભવવા લાગે છે.

મારા પોતાના અનુભવનો ઉપયોગ કરીને, મેં આ ફિલસૂફીના કેટલાક "પોસ્ટ્યુલેટ્સ" ને ઔપચારિક બનાવવાનો પ્રયાસ કર્યો. પરિણામ નીચે મુજબ છે:

• DevOps એવી કોઈ સ્વતંત્ર વસ્તુ નથી જેને જ્ઞાન અથવા પ્રવૃત્તિના અલગ ક્ષેત્રમાં વિભાજિત કરી શકાય.
• કંપનીના તમામ કર્મચારીઓએ તેમની પ્રવૃત્તિઓનું આયોજન કરતી વખતે DevOps પદ્ધતિ દ્વારા માર્ગદર્શન મેળવવું જોઈએ.
• DevOps કંપનીની અંદરની તમામ પ્રક્રિયાઓને અસર કરે છે.
• તેની સેવાઓના વિકાસ અને મહત્તમ ગ્રાહક આરામની ખાતરી કરવા માટે કંપનીની અંદર કોઈપણ પ્રક્રિયાઓ માટે સમય ખર્ચ ઘટાડવા માટે DevOps અસ્તિત્વમાં છે.
• DevOps, આધુનિક ભાષામાં, કંપનીના દરેક કર્મચારીની સક્રિય સ્થિતિ છે, જેનો હેતુ સમય ખર્ચ ઘટાડવા અને આપણી આસપાસના IT ઉત્પાદનોની ગુણવત્તામાં સુધારો કરવાનો છે.

મને લાગે છે કે મારા "પોસ્ટ્યુલેટ્સ" ચર્ચા માટે એક અલગ વિષય છે. પરંતુ હવે બિલ્ડ કરવા માટે કંઈક છે.

DevOps શું કરે છે

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

હું પશ્ચિમી શ્રમ બજાર વિશે 100% વિશ્વાસ સાથે વાત કરી શકતો નથી. પરંતુ હું રશિયામાં DevOps માર્કેટ વિશે ઘણું બધું જાણું છું. સેંકડો ઇન્ટરવ્યુ ઉપરાંત, પાછલા દોઢ વર્ષમાં મેં મોટી રશિયન કંપનીઓ અને બેંકો માટે "દેવઓપ્સના અમલીકરણ" સેવા માટે સેંકડો તકનીકી પ્રીસેલ્સમાં ભાગ લીધો છે.

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

પૈસાની દ્રષ્ટિએ DevOpsનો અમલ કરવો ખર્ચાળ છે. અને તે માત્ર ત્યારે જ ન્યાયી છે જ્યાં તે અન્ય ક્ષેત્રોમાં આર્થિક લાભ લાવે છે, અને તેના પોતાના પર નહીં.

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

ઉપરાંત, એક DevOps એન્જિનિયરને સમય સમય પર વહીવટી સંસાધનનો ઉપયોગ કરવાની જરૂર છે. ઉદાહરણ તરીકે, "પર્યાવરણીય પ્રતિકાર" ને દૂર કરવા - જ્યારે ટીમ DevOps ટૂલ્સ અને પદ્ધતિ સ્વીકારવા તૈયાર ન હોય.

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

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

જ્યારે DevOps ની જરૂર નથી

એવી પરિસ્થિતિઓ છે જ્યારે DevOps ની જરૂર નથી. આ એક હકીકત છે - તેને સમજવાની અને સ્વીકારવાની જરૂર છે.

સૌ પ્રથમ, આ કોઈપણ કંપનીઓ (ખાસ કરીને નાના વ્યવસાયો) ને લાગુ પડે છે, જ્યારે તેમનો નફો સીધો IT ઉત્પાદનોની હાજરી અથવા ગેરહાજરી પર આધાર રાખતો નથી જે ગ્રાહકોને માહિતી સેવાઓ પ્રદાન કરે છે. અને અહીં અમે કંપનીની વેબસાઈટ વિશે વાત નથી કરી રહ્યા, ભલે તે સ્ટેટિક “બિઝનેસ કાર્ડ” હોય કે ડાયનેમિક ન્યૂઝ બ્લોક્સ વગેરે સાથે.

જ્યારે તમારા ક્લાયંટનો સંતોષ અને તમારી પાસે પાછા આવવાની તેમની ઇચ્છા ક્લાયંટ સાથેની ક્રિયાપ્રતિક્રિયા, તેમની ગુણવત્તા અને લક્ષ્યીકરણ માટે આ માહિતી સેવાઓની ઉપલબ્ધતા પર આધાર રાખે છે ત્યારે DevOps જરૂરી છે.

એક આકર્ષક ઉદાહરણ એક જાણીતી બેંક છે. કંપની પાસે પરંપરાગત ક્લાયન્ટ ઓફિસો નથી, દસ્તાવેજનો પ્રવાહ મેઇલ અથવા કુરિયર દ્વારા હાથ ધરવામાં આવે છે અને ઘણા કર્મચારીઓ ઘરેથી કામ કરે છે. કંપનીએ માત્ર એક બેંક બનવાનું બંધ કરી દીધું છે અને, મારા મતે, વિકસિત DevOps ટેક્નોલોજી સાથે IT કંપનીમાં ફેરવાઈ ગઈ છે.

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

• DevOops
• DevOpsConf
• હાઇલોડ++
• ચપટી
• MailRu ક્લાઉડ સોલ્યુશન

હવે તમારા વ્યવસાયને જુઓ અને આ વિશે વિચારો: ગ્રાહકની ક્રિયાપ્રતિક્રિયાને સક્ષમ કરવા માટે તમારી કંપની અને તેનો નફો IT ઉત્પાદનો પર કેટલો આધાર રાખે છે?

જો તમારી કંપની નાના સ્ટોરમાં માછલી વેચે છે અને એકમાત્ર IT પ્રોડક્ટ બે 1C છે: એન્ટરપ્રાઇઝ કન્ફિગરેશન્સ (એકાઉન્ટિંગ અને UNF), તો DevOps વિશે વાત કરવામાં ભાગ્યે જ કોઈ અર્થ નથી.

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

તમારી કંપનીને DevOpsની જરૂર છે કે કેમ તે નક્કી કરવા માટે વાર્ષિક નાણાકીય ટર્નઓવરનું કદ અને વોલ્યુમ મુખ્ય માપદંડ નથી.

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

તેમના ગ્રાહકો કાર ડીલરોની મર્યાદિત સૂચિ છે. અને દરેકને ઉત્પાદક તરફથી નિષ્ણાત સોંપવામાં આવે છે. તમામ આંતરિક દસ્તાવેજોનો પ્રવાહ SAP ERP દ્વારા થાય છે. આંતરિક કર્મચારીઓ આવશ્યકપણે માહિતી સિસ્ટમના ગ્રાહકો છે. પરંતુ આ IS ક્લસ્ટર સિસ્ટમ્સનું સંચાલન કરવાના શાસ્ત્રીય માધ્યમો દ્વારા નિયંત્રિત થાય છે. જે DevOps પ્રેક્ટિસનો ઉપયોગ કરવાની શક્યતાને બાકાત રાખે છે.

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

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

DevOps જરૂરી છે કે કેમ તે સમજવા માટેનો મુખ્ય માપદંડ: કંપની અને ગ્રાહકો માટે તમારા IT ઉત્પાદનોનું શું મૂલ્ય છે.

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

કોઈપણ રમતો ભંડોળને આભારી છે: ખેલાડીઓ તરફથી પ્રત્યક્ષ અથવા પરોક્ષ. Playgendary પર, અમે 200 થી વધુ લોકો સાથે તેમની બનાવટમાં સીધા સંકળાયેલા સાથે મફત મોબાઇલ ગેમ્સ વિકસાવીએ છીએ. આપણે DevOps નો ઉપયોગ કેવી રીતે કરીએ?

હા, ઉપર વર્ણવ્યા પ્રમાણે બરાબર એ જ. હું વિકાસકર્તાઓ અને પરીક્ષકો સાથે સતત વાતચીત કરું છું અને કર્મચારીઓ માટે DevOps પદ્ધતિ અને સાધનો પર આંતરિક તાલીમનું સંચાલન કરું છું.

અમે હવે જેનકિન્સનો CI/CD પાઇપલાઇન્સ ટૂલ તરીકે સક્રિયપણે ઉપયોગ કરી રહ્યા છીએ જેથી યુનિટી સાથેની તમામ એસેમ્બલી પાઇપલાઇન્સ અને એપ સ્ટોર અને પ્લે માર્કેટમાં અનુગામી જમાવટ કરવામાં આવે. ક્લાસિક ટૂલકીટમાંથી વધુ:

• આસન - પ્રોજેક્ટ મેનેજમેન્ટ માટે. જેનકિન્સ સાથે એકીકરણ ગોઠવવામાં આવ્યું છે.
• Google મીટ - વિડિઓ મીટિંગ માટે.
• સ્લૅક - જેનકિન્સ તરફથી સૂચનાઓ સહિત સંચાર અને વિવિધ ચેતવણીઓ માટે.
• એટલાસિયન સંગમ - દસ્તાવેજીકરણ અને જૂથ કાર્ય માટે.

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

તેના બદલે એક નિષ્કર્ષ

હું નીચેના વિચાર સાથે સમાપ્ત કરવા માંગુ છું: ઉચ્ચ ગુણવત્તાવાળું DevOps એન્જિનિયર બનવા માટે, લોકો સાથે જીવંત વાતચીત કેવી રીતે કરવી તે શીખવું મહત્વપૂર્ણ છે.

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

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

સોર્સ: www.habr.com