CI/CD પર સ્વિચ કરતી વખતે સાત સૌથી સામાન્ય ભૂલો

જો તમારી કંપની માત્ર DevOps અથવા CI/CD ટૂલ્સ રજૂ કરી રહી છે, તો તે તમારા માટે સૌથી સામાન્ય ભૂલોથી પરિચિત થવા માટે ઉપયોગી થઈ શકે છે જેથી તેનું પુનરાવર્તન ન થાય અને કોઈ બીજાના રેક પર પગ ન મૂકે. 

ટીમ Mail.ru ક્લાઉડ સોલ્યુશન્સ લેખનો અનુવાદ કર્યો ઉમેરાઓ સાથે જાસ્મીન ચોક્સી દ્વારા CI/CD માં સંક્રમણ કરતી વખતે આ સામાન્ય મુશ્કેલીઓ ટાળો.

સંસ્કૃતિ અને પ્રક્રિયાઓને બદલવાની તૈયારી નથી

જો તમે ચક્રીય રેખાકૃતિ જુઓ DevOps, તે સ્પષ્ટ છે કે DevOps પ્રેક્ટિસમાં પરીક્ષણ એ સતત પ્રવૃત્તિ છે, જે દરેક એક જમાવટનો મૂળભૂત ભાગ છે.

DevOps અનંત સાયકલ ચાર્ટ

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

પરીક્ષણ એ દરેક ટીમના સભ્યના રોજિંદા કાર્યનો ભાગ બની જાય છે. સતત પરીક્ષણ માટે સંક્રમણ સરળ નથી, તમારે તેના માટે તૈયાર રહેવાની જરૂર છે.

પ્રતિસાદનો અભાવ

DevOps અસરકારકતા સતત પ્રતિસાદ પર આધાર રાખે છે. જો સહયોગ અને સંચાર માટે જગ્યા ન હોય તો સતત સુધારણા અશક્ય છે.

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

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

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

પરીક્ષણ વિશેના વિચારોમાં ફેરફારને પ્રતિબિંબિત કરવાની એક સરળ રીત એ છે કે પરીક્ષકોને QA નહીં, પરંતુ સોફ્ટવેર ટેસ્ટર અથવા ગુણવત્તા ઇજનેર કૉલ કરો. આ ફેરફાર ખૂબ સરળ અથવા મૂર્ખ પણ લાગે છે. પરંતુ કોઈને "સોફ્ટવેર ક્વોલિટી એશ્યોરન્સ પર્સન" કહેવાથી ઉત્પાદનની ગુણવત્તા માટે કોણ જવાબદાર છે તે અંગે ખોટો ખ્યાલ આવે છે. ચપળ, CI/CD અને DevOps પ્રેક્ટિસમાં, દરેક વ્યક્તિ સોફ્ટવેર ગુણવત્તા માટે જવાબદાર છે.

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

સ્ટેજ પૂર્ણ થવાની ગેરસમજ

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

CD DevOps/CI ના સંદર્ભમાં થઈ ગયું (DoD) ની વ્યાખ્યા એ એક શક્તિશાળી સાધન છે. તે ટીમ શું અને કેવી રીતે બનાવે છે તેના ગુણવત્તા ધોરણોને વધુ સારી રીતે સમજવામાં મદદ કરે છે.

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

DoD પ્રક્રિયાને વધુ પારદર્શક બનાવે છે અને CI/CDને અમલમાં મૂકવાનું સરળ બનાવે છે જો તે તમામ ટીમના સભ્યો દ્વારા સમજાય અને પરસ્પર સંમત થાય.

વાસ્તવિક, સ્પષ્ટ રીતે વ્યાખ્યાયિત લક્ષ્યોનો અભાવ

આ સલાહના સૌથી વધુ વારંવાર ટાંકવામાં આવેલા ટુકડાઓમાંનું એક છે, પરંતુ તે પુનરાવર્તન કરે છે. CI/CD અથવા DevOps સહિતના કોઈપણ મોટા પ્રયાસમાં સફળ થવા માટે, તમારે વાસ્તવિક લક્ષ્યો નક્કી કરવા અને તેમની સામે પ્રદર્શનને માપવાની જરૂર છે. તમે CI/CD સાથે શું હાંસલ કરવાનો પ્રયાસ કરી રહ્યાં છો? શું આ બહેતર ગુણવત્તા સાથે ઝડપી રિલીઝની મંજૂરી આપે છે?

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

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

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

ઘણી સંસ્થાઓ માટે, એકલું CI પૂરતું છે, અને CD માત્ર ત્યારે જ લાગુ થવી જોઈએ જો તે મૂલ્ય ઉમેરે.

યોગ્ય ડેશબોર્ડ અને મેટ્રિક્સનો અભાવ

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

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

કેટલીક ટીમો CI/CD ની સ્થિતિનું મૂલ્યાંકન કરવા માટે લાલ, પીળા અને લીલા સૂચકાંકો સાથેના ડેશબોર્ડનો ઉપયોગ કરે છે તે સમજવા માટે કે શું તેઓ બધું બરાબર કરી રહ્યા છે કે શું તેમાં કોઈ ભૂલ છે. લાલ રંગનો અર્થ છે કે તમારે શું થઈ રહ્યું છે તેના પર ધ્યાન આપવાની જરૂર છે.

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

કોઈ મેન્યુઅલ પરીક્ષણો નથી

ટેસ્ટ ઓટોમેશન સારી CI/CD પાઇપલાઇન માટે પાયો નાખે છે. પરંતુ તમામ તબક્કે સ્વચાલિત પરીક્ષણનો અર્થ એ નથી કે તમારે મેન્યુઅલ પરીક્ષણ કરવું જોઈએ નહીં. 

અસરકારક CI/CD પાઇપલાઇન બનાવવા માટે, તમારે મેન્યુઅલ પરીક્ષણોની પણ જરૂર છે. પરીક્ષણના કેટલાક પાસાઓ હંમેશા હશે જેને માનવીય વિશ્લેષણની જરૂર હોય છે.

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

પરીક્ષણોમાં સુધારો કરવાનો પ્રયાસ કરશો નહીં

અસરકારક CI/CD પાઈપલાઈન માટે યોગ્ય ટૂલ્સની ઍક્સેસ જરૂરી છે, પછી તે ટેસ્ટ મેનેજમેન્ટ હોય કે એકીકરણ અને ચાલુ દેખરેખ.

મજબૂત, ગુણવત્તા-લક્ષી સંસ્કૃતિ બનાવવાનો હેતુ છે પરીક્ષણોનો અમલ, જમાવટ પછી ગ્રાહકની ક્રિયાપ્રતિક્રિયાઓ અને ટ્રેકિંગ સુધારણાઓનું નિરીક્ષણ કરવું. 

અહીં કેટલીક વ્યવહારુ ટીપ્સ છે જેનો તમે સરળતાથી અમલ કરી શકો છો:

1. ખાતરી કરો કે તમારા પરીક્ષણો લખવામાં સરળ છે અને જ્યારે તમે કોડ રિફેક્ટ કરો ત્યારે તૂટી ન જાય તેટલા લવચીક છે.
2. ડેવલપમેન્ટ ટીમોને પરીક્ષણ પ્રક્રિયામાં સામેલ કરવી જોઈએ - સીઆઈ પાઇપલાઇન્સ દરમિયાન પરીક્ષણ કરવા માટે મહત્વપૂર્ણ હોય તેવા વપરાશકર્તા સમસ્યાઓ અને વિનંતીઓની સૂચિ જુઓ.
3. તમારી પાસે સંપૂર્ણ પરીક્ષણ કવરેજ ન હોઈ શકે, પરંતુ હંમેશા ખાતરી કરો કે UX અને ગ્રાહક અનુભવ માટે મહત્વપૂર્ણ એવા પ્રવાહોનું પરીક્ષણ કરવામાં આવે છે.

છેલ્લો પરંતુ ઓછામાં ઓછો મહત્વનો મુદ્દો નથી

CI/CD માં સંક્રમણ સામાન્ય રીતે નીચેથી ઉપરથી ચલાવવામાં આવે છે, પરંતુ આખરે તે એક પરિવર્તન છે જેને કંપની તરફથી નેતૃત્વ ખરીદવા, સમય અને સંસાધનોની જરૂર પડે છે. છેવટે, CI/CD એ કૌશલ્યો, પ્રક્રિયાઓ, સાધનો અને સાંસ્કૃતિક પુનઃરચનાનો સમૂહ છે; આવા ફેરફારો ફક્ત વ્યવસ્થિત રીતે જ લાગુ કરી શકાય છે.

વિષય પર બીજું શું વાંચવું:

1. કેવી રીતે તકનીકી દેવું તમારા પ્રોજેક્ટને મારી નાખે છે.
2. DevOps કેવી રીતે સુધારવું.
3. 2020 માટે નવ ટોચના DevOps વલણો.

સોર્સ: www.habr.com