DevOps - VTB અનુભવનો ઉપયોગ કરીને સંપૂર્ણ ઇનહાઉસ ડેવલપમેન્ટ કેવી રીતે બનાવવું

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

 

પ્રસ્તાવના: DevOps એક ફિલસૂફી છે

છેલ્લા એક વર્ષમાં, અમે VTB પર DevOps પ્રથાઓના આંતરિક વિકાસ અને અમલીકરણને ગોઠવવા માટે ઘણું કામ કર્યું છે:

• અમે 12 સિસ્ટમો માટે આંતરિક વિકાસ પ્રક્રિયાઓ બનાવી છે;
• અમે 15 પાઇપલાઇન્સ શરૂ કરી, જેમાંથી ચાર ઉત્પાદનમાં લાવવામાં આવી;
• સ્વયંસંચાલિત 1445 પરીક્ષણ દૃશ્યો;
• અમે ઇન-હાઉસ ટીમો દ્વારા તૈયાર કરવામાં આવેલી સંખ્યાબંધ રિલીઝનો સફળતાપૂર્વક અમલ કર્યો છે.

ઇનહાઉસ ડેવલપમેન્ટ અને DevSecOps પ્રેક્ટિસના અમલીકરણનું આયોજન કરવું સૌથી મુશ્કેલ પૈકીનું એક FIS પ્રોફાઇલ સિસ્ટમ છે - બિન-સંબંધિત DBMS પર રિટેલ પ્રોડક્ટ પ્રોસેસર. તેમ છતાં, અમે ડેવલપમેન્ટનું નિર્માણ કરવામાં, પાઇપલાઇન શરૂ કરવામાં, ઉત્પાદન પર વ્યક્તિગત નૉન-રિલીઝ પૅકેજ ઇન્સ્ટોલ કરવામાં અને રિલીઝને કેવી રીતે એસેમ્બલ કરવું તે શીખ્યા. કાર્ય સરળ ન હતું, પરંતુ રસપ્રદ અને અમલીકરણમાં સ્પષ્ટ પ્રતિબંધો વિના: અહીં સિસ્ટમ છે - તમારે આંતરિક વિકાસ બનાવવાની જરૂર છે. ઉત્પાદક વાતાવરણ પહેલાં સીડીનો ઉપયોગ કરવાની એકમાત્ર શરત છે.

શરૂઆતમાં, અમલીકરણ અલ્ગોરિધમ સરળ અને સ્પષ્ટ લાગતું હતું:

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

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

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

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

આંતરિક વિકાસ ક્યાંથી શરૂ થાય છે? 

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

• વિચિત્ર ભાષા (MUMPS);
• કન્સોલ ઇન્ટરફેસ;
• લોકપ્રિય ઓટોમેશન ટૂલ્સ અને ફ્રેમવર્ક સાથે એકીકરણનો અભાવ;
• દસ ટેરાબાઇટ્સમાં ડેટા વોલ્યુમ;
• કલાક દીઠ 2 મિલિયનથી વધુ કામગીરીનો ભાર;
• મહત્વ- વ્યાપાર- જટિલ.

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

• કોડ જનરેશનના દસ્તાવેજીકરણ અને મૂળભૂત બાબતોનો અભ્યાસ કર્યો;
• અમે વિક્રેતા પાસેથી પ્રાપ્ત વિકાસ પરના ટૂંકા અભ્યાસક્રમનો અભ્યાસ કર્યો;
• પ્રારંભિક વિકાસ કુશળતામાં નિપુણતા;
• અમે ટીમના નવા સભ્યો માટે તાલીમ માર્ગદર્શિકાનું સંકલન કર્યું;
• અમે ટીમને "લડાઇ" મોડમાં સામેલ કરવા સંમત થયા છીએ;
• કોડ ગુણવત્તા નિયંત્રણ સાથે સમસ્યાનું નિરાકરણ;
• અમે વિકાસ માટે સ્ટેન્ડ ગોઠવ્યું.

અમે નિપુણતા વિકસાવવામાં અને સિસ્ટમમાં પોતાને નિમજ્જિત કરવામાં ત્રણ મહિના ગાળ્યા, અને 2019 ની શરૂઆતથી, આંતરિક વિકાસએ ઉજ્જવળ ભવિષ્ય તરફ તેની હિલચાલ શરૂ કરી, કેટલીકવાર મુશ્કેલી સાથે, પરંતુ વિશ્વાસપૂર્વક અને હેતુપૂર્વક.

રીપોઝીટરી સ્થળાંતર અને ઓટોટેસ્ટ

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

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

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

તે કેવી રીતે હતું: ઓટોમેશન પહેલાનું મોડેલ

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

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

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

કોડનું આવશ્યક સંસ્કરણ મેળવવા માટે, ઇન્સ્ટોલેશન ઓર્ડરનું સખતપણે પાલન કરવું જરૂરી હતું, જે દરમિયાન ઑબ્જેક્ટ્સ ઘણી વખત ભૌતિક રીતે ફરીથી લખવામાં આવ્યા હતા, લગભગ 10-12 વખત.

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

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

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

પ્રથમ અપડેટ્સ: કમિટ એસેમ્બલી અને ડિલિવરી

આ માર્ગ સાથે પાઇપ દ્વારા કોડ ટ્રાન્સમિટ કરીને ઓટોમેશન શરૂ થયું:

• સ્ટોરેજમાંથી તૈયાર ડિલિવરી પસંદ કરો;
• તેને સમર્પિત વાતાવરણ પર ઇન્સ્ટોલ કરો;
• ઑટોટેસ્ટ્સ ચલાવો;
• ઇન્સ્ટોલેશન પરિણામનું મૂલ્યાંકન કરો;
• પરીક્ષણ આદેશની બાજુમાં નીચેની પાઇપલાઇનને કૉલ કરો.

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

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

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

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

અંતિમ ઉકેલ: સંચિત ઇન્સ્ટોલેશન પેકેજો 

અમે સારી રીતે સમજી શક્યા છીએ કે વિક્રેતાની સૂચનાઓને સ્ક્રિપ્ટ કરવી એ એક ખૂબ જ ઓટોમેશન હતું; અમારે પ્રક્રિયા પર જ પુનર્વિચાર કરવો પડ્યો. ઉકેલ સ્પષ્ટ હતો - જરૂરી સંસ્કરણોના તમામ ઑબ્જેક્ટ્સ સાથે પ્રકાશન શાખામાંથી સંચિત પુરવઠો એકત્રિત કરવો.

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

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

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

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

એક વધારાનો પડકાર મોટી સંખ્યામાં બિન-પ્રકાશનનો હતો જેને ધ્યાનમાં લેવો પડ્યો હતો. પરંતુ પ્રોડ જેવી શાખા અને રીબેઝ સાથે, કાર્ય પારદર્શક બન્યું.

પ્રથમ વખત, ઝડપથી અને ભૂલો વિના

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

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

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

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

પરિણામો અને તારણો

એક વર્ષથી ઓછા સમયમાં અમે આમાં વ્યવસ્થાપિત થયા:

• વિદેશી સિસ્ટમનો ઉપયોગ કરીને સંપૂર્ણ આંતરિક વિકાસ બનાવો;
• નિર્ણાયક વિક્રેતા નિર્ભરતાને દૂર કરો;
• ખૂબ જ મૈત્રીપૂર્ણ વારસો માટે CI/CD લોંચ કરો;
• અમલીકરણ પ્રક્રિયાઓને નવા તકનીકી સ્તરે વધારવી;
• જમાવટનો સમય નોંધપાત્ર રીતે ઘટાડે છે;
• અમલીકરણની ભૂલોની સંખ્યામાં નોંધપાત્ર ઘટાડો;
• આત્મવિશ્વાસપૂર્વક તમારી જાતને અગ્રણી વિકાસ નિષ્ણાત તરીકે જાહેર કરો.

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

સોર્સ: www.habr.com