અમે GitLab માં સોફ્ટવેર પેચ કેવી રીતે રિલીઝ કરીએ છીએ

GitLab પર, અમે સોફ્ટવેર ફિક્સને બે રીતે પ્રોસેસ કરીએ છીએ: મેન્યુઅલી અને ઑટોમૅટિકલી. gitlab.com પર સ્વયંસંચાલિત જમાવટ દ્વારા મહત્વપૂર્ણ અપડેટ્સ બનાવવા અને વિતરિત કરવાના રીલીઝ મેનેજરના કામ વિશે જાણવા માટે વાંચો, તેમજ વપરાશકર્તાઓને તેમના પોતાના ઇન્સ્ટોલેશન પર કામ કરવા માટેના પેચ વિશે.

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

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

«અમે સુનિશ્ચિત કરીએ છીએ કે વિકાસકર્તાઓ બનાવેલ દરેક વસ્તુને GitLab.com પર રોલઆઉટ કરતા પહેલા દરરોજ તમામ વાતાવરણમાં તૈનાત કરવામાં આવે છે.", સમજાવે છે મારિન જાનકોવકી, વરિષ્ઠ ટેકનિકલ મેનેજર, ઈન્ફ્રાસ્ટ્રક્ચર વિભાગ. "તમારા ઇન્સ્ટોલેશન માટેના પ્રકાશનોને gitlab.com ડિપ્લોયમેન્ટ્સ માટે સ્નેપશોટ તરીકે વિચારો, જેના માટે અમે પેકેજ બનાવવા માટે અલગ પગલાં ઉમેર્યા છે જેથી અમારા વપરાશકર્તાઓ તેમના ઇન્સ્ટોલેશન પર ઇન્સ્ટોલ કરવા માટે તેનો ઉપયોગ કરી શકે.».

બગ અથવા નબળાઈને ધ્યાનમાં લીધા વિના, gitlab.com ગ્રાહકો પ્રકાશિત થયા પછી તરત જ સુધારાઓ પ્રાપ્ત કરશે, જે સ્વયંસંચાલિત CD પ્રક્રિયાનો લાભ છે. તેમના પોતાના ઇન્સ્ટોલેશનવાળા વપરાશકર્તાઓ માટેના પેચોને રિલીઝ મેનેજર દ્વારા અલગ તૈયારીની જરૂર છે.

ડિલિવરી ટીમ ઘટાડવા માટે પ્રકાશનો બનાવવા સાથે સંકળાયેલી મોટાભાગની પ્રક્રિયાઓને સ્વચાલિત કરવા માટે સખત મહેનત કરી રહી છે MTTP (ઉત્પાદન માટેનો સરેરાશ સમય, એટલે કે ઉત્પાદન પર વિતાવેલો સમય), વિકાસકર્તા દ્વારા મર્જ વિનંતી પર પ્રક્રિયા કરવાથી gitlab.com પર જમાવટ સુધીનો સમયગાળો.

«ડિલિવરી ટીમનો ધ્યેય એ સુનિશ્ચિત કરવાનો છે કે અમે એક કંપની તરીકે વધુ ઝડપથી આગળ વધી શકીએ, અથવા ઓછામાં ઓછું ડિલિવરી કરનારા લોકો વધુ ઝડપથી કામ કરી શકીએ.?, મારિન કહે છે.

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

રીલીઝ મેનેજર શું કરે છે?

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

સ્વ-ઇન્સ્ટોલેશન રીલીઝ અને gitlab.com રીલીઝ સમાન વર્કફ્લોનો ઉપયોગ કરે છે પરંતુ જુદા જુદા સમયે ચાલે છે, મારિન સમજાવે છે.

સૌપ્રથમ અને અગ્રણી, રિલીઝ મેનેજર, પ્રકાશન પ્રકારને ધ્યાનમાં લીધા વિના, ખાતરી કરે છે કે gitlab.com પર એપ્લિકેશન શરૂ થાય ત્યારથી જ GitLab ઉપલબ્ધ અને સુરક્ષિત છે, જેમાં ગ્રાહકોના ઈન્ફ્રાસ્ટ્રક્ચરમાં સમાન સમસ્યાઓનો અંત ન આવે તેની ખાતરી કરવા સહિત. પોતાની ક્ષમતાઓ.

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

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

તે બધા સુધારાઓ વિશે છે

પેચો શું છે અને શા માટે અમને તેમની જરૂર છે?

રીલીઝ મેનેજર નક્કી કરે છે કે શું ભૂલની ગંભીરતાના આધારે ફિક્સ રીલીઝ કરવું.

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

જો કે, નબળાઈઓ S1 અથવા S2 નો અર્થ છે કે વપરાશકર્તાએ નવીનતમ સંસ્કરણ પર અપડેટ થવું જોઈએ નહીં, અથવા કોઈ નોંધપાત્ર બગ છે જે વપરાશકર્તાના કાર્યપ્રવાહને અસર કરે છે. જો તેઓ ટ્રેકરમાં શામેલ હોય, તો ઘણા વપરાશકર્તાઓએ તેમનો સામનો કર્યો છે, તેથી રિલીઝ મેનેજર તરત જ ફિક્સ તૈયાર કરવાનું શરૂ કરે છે.

એકવાર નબળાઈઓ S1 અથવા S2 માટેનો પેચ તૈયાર થઈ જાય, પછી રિલીઝ મેનેજર પેચને રિલીઝ કરવાનું શરૂ કરે છે.

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

જ્યારે ઘણા બધા S4, S3 અને S2 એકઠા થાય છે, ત્યારે રીલીઝ મેનેજર ફિક્સ રિલીઝ કરવાની તાકીદને નિર્ધારિત કરવા માટે સંદર્ભને જુએ છે, અને જ્યારે તેમાંથી ચોક્કસ સંખ્યા પર પહોંચી જાય છે, ત્યારે તે બધાને એકીકૃત કરવામાં આવે છે અને રિલીઝ કરવામાં આવે છે. પોસ્ટ-રિલીઝ ફિક્સેસ અથવા સુરક્ષા અપડેટ્સનો સારાંશ બ્લોગ પોસ્ટ્સમાં આપવામાં આવ્યો છે.

રીલીઝ મેનેજર પેચો કેવી રીતે બનાવે છે

અમે પેચ જનરેટ કરવા માટે GitLab CI અને અમારા ChatOps જેવી અન્ય સુવિધાઓનો ઉપયોગ કરીએ છીએ. રીલીઝ મેનેજર અમારી આંતરિક ચેનલ પર ChatOps ટીમને સક્રિય કરીને ફિક્સની રજૂઆત શરૂ કરે છે #releases સ્લેક માં.

/chatops run release prepare 12.10.1

ChatOps વિવિધ ઇવેન્ટ્સને ટ્રિગર કરવા માટે Slack ની અંદર કામ કરે છે, જે પછી GitLab દ્વારા પ્રક્રિયા કરવામાં આવે છે અને ચલાવવામાં આવે છે. ઉદાહરણ તરીકે, ડિલિવરી ટીમે પેચ રીલીઝ કરવા માટે વિવિધ વસ્તુઓને સ્વચાલિત કરવા માટે ChatOps સેટ કર્યા છે.

એકવાર રીલીઝ મેનેજર Slack માં ChatOps ટીમ શરૂ કરી દે, પછી બાકીનું કામ CICD નો ઉપયોગ કરીને GitLab માં આપમેળે થાય છે. રીલીઝ પ્રક્રિયા દરમિયાન સ્લેક અને ગિટલેબમાં ચેટઓપ્સ વચ્ચે દ્વિ-માર્ગી સંચાર છે કારણ કે રીલીઝ મેનેજર પ્રક્રિયામાં કેટલાક મુખ્ય પગલાઓને સક્રિય કરે છે.

નીચેનો વિડીયો GitLab માટે પેચ તૈયાર કરવાની તકનીકી પ્રક્રિયા બતાવે છે.

gitlab.com પર સ્વચાલિત જમાવટ કેવી રીતે કાર્ય કરે છે

gitlab.com ને અપડેટ કરવા માટે વપરાતી પ્રક્રિયા અને સાધનો પેચ બનાવવા માટે ઉપયોગમાં લેવાતા સમાન છે. gitlab.com ને અપડેટ કરવા માટે રિલીઝ મેનેજરના દૃષ્ટિકોણથી ઓછા મેન્યુઅલ કાર્યની જરૂર છે.

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

"તેથી અમારી પાસે gitlab.com પહેલાં વિવિધ વાતાવરણમાં ઘણી બધી જમાવટ ચાલી રહી છે, અને તે વાતાવરણ સારી સ્થિતિમાં હોય અને પરીક્ષણ સારા પરિણામો બતાવે પછી, રિલીઝ મેનેજર gitlab.com ડિપ્લોયમેન્ટ ક્રિયાઓ શરૂ કરે છે," મારિન કહે છે.

gitlab.com અપડેટ્સને ટેકો આપવા માટેની CICD ટેક્નોલોજી સમગ્ર પ્રક્રિયાને તે બિંદુ સુધી સ્વચાલિત કરે છે જ્યાં પ્રકાશન સંચાલકે gitlab.com પર ઉત્પાદન પર્યાવરણની જમાવટ મેન્યુઅલી શરૂ કરવી જોઈએ.

મારિન નીચેની વિડિઓમાં gitlab.com અપડેટ પ્રક્રિયા વિશે વિગતવાર જાય છે.

ડિલિવરી ટીમ બીજું શું કરે છે?

gitlab.com અપડેટ પ્રક્રિયાઓ અને ઘરના ગ્રાહકોને પેચ રીલીઝ કરવા વચ્ચેનો મુખ્ય તફાવત એ છે કે પછીની પ્રક્રિયામાં પ્રકાશન મેનેજર પાસેથી વધુ સમય અને વધુ મેન્યુઅલ કાર્યની જરૂર પડે છે.

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

ડિલિવરી ટીમના ટૂંકા ગાળાના ધ્યેયોમાંથી એક પ્રકાશન મેનેજરના ભાગ પર મેન્યુઅલ કાર્યની માત્રા ઘટાડવાનું છે જેથી પ્રકાશનને ઝડપી બનાવવામાં આવે. ટીમ રિલીઝ પ્રક્રિયાને સરળ બનાવવા, સુવ્યવસ્થિત કરવા અને સ્વચાલિત કરવા માટે કામ કરી રહી છે, જે ઓછી ગંભીરતાના મુદ્દાઓ (S3 અને S4, આશરે અનુવાદક). ઝડપ પર ધ્યાન કેન્દ્રિત કરવું એ મુખ્ય પ્રદર્શન સૂચક છે: MTTP ઘટાડવું જરૂરી છે - મર્જ વિનંતી પ્રાપ્ત થવાથી લઈને gitlab.com પર પરિણામ જમાવવાનો સમય - વર્તમાન 50 કલાકથી 8 કલાક સુધી.

ડિલિવરી ટીમ gitlab.com ને Kubernetes આધારિત ઈન્ફ્રાસ્ટ્રક્ચરમાં સ્થાનાંતરિત કરવા પર પણ કામ કરી રહી છે.

સંપાદકના એન.બી.: જો તમે પહેલાથી જ કુબરનેટ્સ ટેક્નોલોજી વિશે સાંભળ્યું છે (અને મને કોઈ શંકા નથી કે તમારી પાસે છે), પરંતુ હજી સુધી તેને તમારા હાથથી સ્પર્શ કર્યો નથી, તો હું ઑનલાઇન સઘન અભ્યાસક્રમોમાં ભાગ લેવાની ભલામણ કરું છું કુબરનેટ્સ બેઝ, જે સપ્ટેમ્બર 28-30 યોજાશે, અને કુબરનેટ્સ મેગા, જે 14-16 ઓક્ટોબરે યોજાશે. આ તમને વિશ્વાસપૂર્વક નેવિગેટ કરવા અને ટેક્નોલોજી સાથે કામ કરવાની મંજૂરી આપશે.

આ બે અભિગમો છે જે સમાન ધ્યેયને અનુસરે છે: gitlab.com અને ગ્રાહકો માટે તેમની સુવિધાઓ બંને માટે અપડેટ્સની ઝડપી ડિલિવરી.

અમારા માટે કોઈ વિચારો અથવા ભલામણો?

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

સોર્સ: www.habr.com