વિકાસકર્તાઓ માટે શ્રેષ્ઠ DevOps પ્રથાઓ. એન્ટોન બોયકો (2017)

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

મને મારો પરિચય આપવા દો, હું સંપૂર્ણપણે કબૂલ કરું છું કે રૂમમાં એવા લોકો છે જે મને ઓળખતા નથી. મારું નામ એન્ટોન બોયકો છે, હું Microsoft Azure MVP છું. MVP શું છે? આ મોડેલ-વ્યૂ-પ્રેઝેન્ટર છે. મોડેલ-વ્યુ-પ્રેઝેન્ટર બરાબર હું છું.

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

મારા વિશે થોડાક શબ્દો:

• હું 10 વર્ષથી આ ક્ષેત્રમાં છું.
• મેં માઈક્રોસોફ્ટમાં કામ કર્યું.
• હું યુક્રેનિયન Azure સમુદાયનો સ્થાપક પિતા છું, જેની સ્થાપના અમે ક્યાંક 2014 માં કરી હતી. અને અમારી પાસે હજી પણ છે અને તેનો વિકાસ કરી રહ્યા છીએ.
• હું એઝ્યુર કોન્ફરન્સના સ્થાપકનો પિતા પણ છું, જે અમે યુક્રેનમાં હોસ્ટ કરી રહ્યા છીએ.
• હું કિવમાં ગ્લોબલ એઝ્યુર બૂટકેમ્પનું આયોજન કરવામાં પણ મદદ કરું છું.
• મેં કહ્યું તેમ, હું Microsoft Azure MVP છું.
• હું ઘણી વાર કોન્ફરન્સમાં બોલું છું. મને પરિષદોમાં બોલવાનું ખરેખર ગમે છે. છેલ્લા એક વર્ષમાં હું લગભગ 40 વખત પ્રદર્શન કરી શક્યો. જો તમે યુક્રેન, બેલારુસ, પોલેન્ડ, બલ્ગેરિયા, સ્વીડન, ડેનમાર્ક, નેધરલેન્ડ, સ્પેનમાંથી પસાર થાવ છો અથવા યુરોપમાં કોઈ અન્ય દેશ આપો છો અથવા લો છો, તો તે તદ્દન શક્ય છે કે જ્યારે તમે એવી કોન્ફરન્સમાં જાઓ છો કે જેની સ્ટ્રીમમાં ક્લાઉડ થીમ હોય, તમે મને વક્તાઓની યાદીમાં જોઈ શકો છો.
• હું પણ સ્ટાર ટ્રેકનો ચાહક છું.

ચાલો એજન્ડા વિશે થોડી વાત કરીએ. અમારો કાર્યસૂચિ ખૂબ જ સરળ છે:

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

એક પરંપરાગત ચિત્ર જે ઘણા લોકો બતાવે છે. ઘણા પ્રોજેક્ટ્સમાં આવું થાય છે. આ ત્યારે થાય છે જ્યારે અમારી પાસે વિકાસ અને કામગીરી વિભાગો હોય છે જે અમારા સૉફ્ટવેરને સમર્થન આપે છે. અને આ વિભાગો એકબીજા સાથે વાતચીત કરતા નથી.

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

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

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

અને જ્યારે આપણે DevOps વિશે વાત કરીએ છીએ, ત્યારે કોઈ તમને કહેશે કે DevOps તે છે જ્યારે પ્રોજેક્ટમાં સતત એકીકરણ હોય; કોઈ કહેશે કે જો પ્રોજેક્ટ “કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર” પ્રેક્ટિસનો અમલ કરે તો DevOps છે; કોઈ કહેશે કે DevOps માટેનું પ્રથમ પગલું એ ફીચર બ્રાન્ચિંગ, ફીચર ફ્લેગ્સ છે.

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

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

જ્યારે તમે DevOps કલ્ચરને અમલમાં મૂકવાનું શરૂ કરો છો, ત્યારે તે ખૂબ જ મહત્વપૂર્ણ છે કે તે નીચેના ક્રમમાં લાગુ કરવામાં આવે.

શરૂઆતમાં તમારે લોકો સાથે વાત કરવાની જરૂર છે. અને તમારે લોકોને સમજાવવાની જરૂર છે કે તે શું છે અને તેઓ તેનાથી કેટલાક ફાયદા કેવી રીતે મેળવી શકે છે.

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

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

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

QA ને સૌથી વધુ શું જોઈએ છે? મને ખબર નથી કે તેઓ હોલમાં છે કે નહીં. મારા માટે એ કહેવું મુશ્કેલ છે કે મારે QA જોઈએ છે, કારણ કે હું ક્યારેય એક નહોતો. અને છોકરાઓ માટે કોઈ ગુનો નહીં, એવું કહેવામાં આવશે કે મને આશા છે કે હું ક્યારેય નહીં કરું. પરંતુ એ કારણથી નહીં કે હું તેમના કામને અર્થહીન અને નકામું માનું છું, પરંતુ કારણ કે હું મારી જાતને એવી વ્યક્તિ નથી માનતો કે જે આ કાર્ય કુશળતાપૂર્વક કરી શકે, તેથી હું તે કરવાનો પ્રયાસ પણ કરીશ નહીં. પરંતુ હું જે સમજું છું તેના પરથી, QA ને જે સૌથી વધુ ગમતું નથી તે સવારે કામ કરવા જઈ રહ્યું છે, સતત અમુક પ્રકારના રીગ્રેસન પરીક્ષણો ચલાવે છે, તે જ ભૂલો પર પગલું ભરવું જે તેઓએ 3 સ્પ્રિન્ટ પહેલા વિકાસકર્તાઓને જાણ કરી હતી અને કહે છે: “તમે ક્યારે કરશો? , મહાશય ડી 'આર્ટગનન, આ ભૂલને ઠીક કરો.' અને મોન્સિયર ડી'આર્ટગન તેને જવાબ આપે છે: "હા, હા, હા, મેં તેને પહેલેથી જ ઠીક કરી દીધું છે." અને તે કેવી રીતે થાય છે કે મેં એક ભૂલ સુધારી અને રસ્તામાં 5 બનાવ્યા.

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

અને જ્યારે તમે લોકોને સમજાવો છો કે તેઓ સમાન સમસ્યાઓને ઉકેલવાના લક્ષ્યમાં છે, ત્યારે તમે પ્રક્રિયાઓને ઔપચારિક બનાવવા માટે આગળ વધી શકો છો. તે ખૂબ જ મહત્વપૂર્ણ છે. શા માટે? કારણ કે જ્યારે આપણે "ઔપચારિકકરણ" કહીએ છીએ, ત્યારે તમારા માટે એનું વર્ણન કરવું મહત્વપૂર્ણ છે કે તમારી પ્રક્રિયાઓ ઓછામાં ઓછી ક્યાંક નેપકિન પર કેવી રીતે થાય છે. તમારે એ સમજવાની જરૂર છે કે જો તમે, ઉદાહરણ તરીકે, QA પર્યાવરણ અથવા ઉત્પાદન વાતાવરણમાં જમાવટ કરો છો, તો તે હંમેશા આ ક્રમમાં થાય છે; આ તબક્કે અમે ચલાવીએ છીએ, ઉદાહરણ તરીકે, સ્વચાલિત એકમ પરીક્ષણો અને UI પરીક્ષણો. જમાવટ પછી, અમે તપાસ કરીએ છીએ કે જમાવટ સારી રીતે થઈ કે ખરાબ રીતે. પરંતુ તમારી પાસે પહેલેથી જ ક્રિયાઓની સ્પષ્ટ સૂચિ છે કે જે તમે ઉત્પાદનમાં જમાવતા હો ત્યારે વારંવાર પુનરાવર્તિત થવી જોઈએ.

અને જ્યારે તમારી પ્રક્રિયાઓ ઔપચારિક થઈ જાય, ત્યારે જ તમે ઉત્પાદનો પસંદ કરવાનું શરૂ કરો છો જે તમને આ પ્રક્રિયાઓને સ્વચાલિત કરવામાં મદદ કરશે.

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

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

ચાલો સામાન્ય રીતે DevOps પ્રથાઓ વિશે વાત કરીએ. તેઓ શું છે? શું તફાવત છે? તેમના પર કેવી રીતે પ્રયાસ કરવો? શા માટે તેઓ મહત્વપૂર્ણ છે?

તમે જે પ્રથમ પ્રેક્ટિસ વિશે સાંભળ્યું હશે તેને સતત એકીકરણ કહેવાય છે. કદાચ પ્રોજેક્ટ પર કોઈની પાસે સતત એકીકરણ (CI) છે.

સૌથી મોટી સમસ્યા એ છે કે મોટાભાગે જ્યારે હું કોઈ વ્યક્તિને પૂછું છું: "શું તમારી પાસે પ્રોજેક્ટ પર CI છે?" અને તે કહે છે: "હા," પછી જ્યારે હું પૂછું છું કે તે શું કરે છે, ત્યારે તે મને સંપૂર્ણ ઓટોમેશન પ્રક્રિયાનું વર્ણન કરે છે. આ સંપૂર્ણ રીતે સાચું નથી.

વાસ્તવમાં, CI ની પ્રેક્ટિસનો હેતુ એ કોડને એકીકૃત કરવાનો છે જે વિવિધ લોકો અમુક પ્રકારના સિંગલ કોડ બેઝમાં લખે છે. બસ એટલું જ.

CI ની સાથે, રસ્તામાં સામાન્ય રીતે અન્ય પ્રથાઓ હોય છે - જેમ કે સતત જમાવટ, પ્રકાશન વ્યવસ્થાપન, પરંતુ અમે તેના વિશે પછીથી વાત કરીશું.

CI પોતે અમને કહે છે કે અલગ-અલગ લોકો કોડ લખે છે અને આ કોડ સતત એક કોડ બેઝમાં એકીકૃત હોવો જોઈએ.

આ આપણને શું આપે છે અને તે શા માટે મહત્વપૂર્ણ છે? જો અમારી પાસે DotNet છે, તો તે સારું છે, તે સંકલિત ભાષા છે, અમે અમારી એપ્લિકેશનને કમ્પાઈલ કરી શકીએ છીએ. જો તે કમ્પાઇલ કરે છે, તો આ પહેલેથી જ એક સારો સંકેત છે. આનો અર્થ હજી સુધી કંઈ નથી, પરંતુ તે પ્રથમ સારી નિશાની છે જે આપણે ઓછામાં ઓછું કમ્પાઈલ કરી શકીએ છીએ.

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

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

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

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

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

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

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

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

આપણે આ પ્રથાની સફળતા કે નિષ્ફળતાને કેવી રીતે માપી શકીએ? જો તમે મોટા બોસને જાણ કરો કે અમે CI પ્રોજેક્ટ પર શું અમલમાં મૂક્યું છે, તો તે બ્લા બ્લા બ્લા સાંભળશે. અમે તેને અમલમાં મૂક્યું, ઠીક છે, પરંતુ શા માટે, તે આપણા માટે શું લાવ્યા, અમે તેને કેવી રીતે માપીશું, અમે તેને કેટલી સાચી કે ખોટી રીતે અમલમાં મૂકીએ છીએ?

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

અમારી પાસે બીજી પ્રેક્ટિસ છે ઓટોમેશન ટેસ્ટિંગ પ્રેક્ટિસ, જે મોટાભાગે CI પ્રેક્ટિસ સાથે આવે છે. તેઓ હાથ જોડીને જાય છે.

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

અમારી પાસે એકીકરણ પરીક્ષણો પણ છે જે અમને સમજવા દે છે કે વિવિધ મોડ્યુલો એકબીજા સાથે કેવી રીતે એકીકૃત થાય છે. તે પણ સારું છે.

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

તમે ચલાવો છો તે વિશિષ્ટ પરીક્ષણો તમે તેને કેટલી વાર ચલાવો છો તે અસર કરી શકે છે. એકમ પરીક્ષણો સામાન્ય રીતે ટૂંકા અને નાના લખવામાં આવે છે. અને તેઓ નિયમિતપણે શરૂ કરી શકાય છે.

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

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

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

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

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

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

ઉપરાંત, જ્યારે તમે એકબીજા વચ્ચે કોડને એકીકૃત કરો છો, એટલે કે. આદેશની વચ્ચે, આ તમને તે UI પર કેવી દેખાય છે તે પણ જોવાની મંજૂરી આપે છે.

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

અમારી પાસે જે આગળની પ્રેક્ટિસ છે તે ઑટોમેટિક રિસ્ટોરની પ્રેક્ટિસ છે, એટલે કે ઍપ્લિકેશનના પાછલા સંસ્કરણ પર પાછા ફરવું.

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

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

પરંતુ, જો તમે કૅલેન્ડર ન જોયું હોય, તો 90નું દશક લગભગ 30 વર્ષ પહેલાંનું હતું. હવે બધું થોડું અલગ રીતે થઈ રહ્યું છે. અને જ્યારે તેઓ તમને કહે ત્યારે દુર્ઘટનાના સ્કેલની કલ્પના કરવાનો પ્રયાસ કરો: “અમે ઉત્પાદન માટે તૈનાત કર્યા હતા, પરંતુ ત્યાં કંઈક ખોટું થયું હતું. અહીં તમારું FTP લૉગિન અને પાસવર્ડ છે, પ્રોડક્શન સાથે કનેક્ટ કરો અને તેને ત્યાં ઝડપથી ઠીક કરો.” જો તમે ચક નોરિસ છો, તો આ કામ કરશે. જો નહિં, તો તમે જોખમ લો છો કે જો તમે એક બગને ઠીક કરો છો, તો તમે 10 વધુ બનાવશો. આ જ કારણ છે કે પાછલા સંસ્કરણ પર પાછા ફરવાની આ પ્રથા તમને ઘણું પ્રાપ્ત કરવાની મંજૂરી આપે છે.

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

હવે ચાલો કોઈક રીતે અગાઉની બે પ્રથાઓને એકસાથે જોડવાનો પ્રયાસ કરીએ. અમને રિલીઝ મેનેજમેન્ટ નામનું ત્રીજું મળશે.

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

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

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

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

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

પછી અમે તેને લઈએ છીએ અને તેને આપમેળે દેવ પર્યાવરણમાં જમાવીએ છીએ. અમે ત્યાં રેસ કરીએ છીએ, અને જો બધું સારું હોય, તો અમે સ્ટેજ પર જમાવટ કરીએ છીએ. જો બધું બરાબર છે, તો અમે ઉત્પાદનમાં સમાન આર્કાઇવને જમાવીએ છીએ, સમાન દ્વિસંગી, બરાબર એક જ વાર સંકલિત.

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

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

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

વિચાર એ છે કે કોડ પ્રેક્ટિસ તરીકે ઈન્ફ્રાસ્ટ્રક્ચરનો ઉપયોગ કરીને, તમે તમારા વર્ચ્યુઅલ ઈન્ફ્રાસ્ટ્રક્ચરને માત્ર અન્ય સ્ત્રોત તરીકે ગણી શકો છો.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

હું જાણું છું કે હું જે ટીમ સાથે કામ કરું છું તેમાંથી આ કોન્ફરન્સમાં ઘણા લોકો છે. અને હું જે ટીમો સાથે કામ કરું છું તેની સાથે અમે આ પ્રથાનો ઉપયોગ કરીએ છીએ.

શા માટે? અલબત્ત, જો દરેક ડેવલપર પાસે વર્ચ્યુઅલ મશીન હોય જે 24/7 કામ કરશે તો તે સારું રહેશે. પરંતુ કદાચ આ તમારા માટે સમાચાર છે, કદાચ તમે ધ્યાન આપ્યું નથી, પરંતુ વિકાસકર્તા પોતે 24/7 કામ કરતું નથી. ડેવલપર સામાન્ય રીતે દિવસમાં 8 કલાક કામ કરે છે. જો તે કામ પર વહેલો આવે તો પણ તેની પાસે એક મોટું લંચ છે જે દરમિયાન તે જીમમાં જાય છે. જ્યારે ડેવલપર ખરેખર આ સંસાધનોનો ઉપયોગ કરે ત્યારે તેને 12 કલાક થવા દો. અમારા કાયદા અનુસાર, અમારી પાસે અઠવાડિયાના 5 માંથી 7 દિવસ છે જેને કામકાજના દિવસો ગણવામાં આવે છે.

તદનુસાર, અઠવાડિયાના દિવસોમાં આ મશીન 24 કલાક નહીં, પરંતુ માત્ર 12 કલાક કામ કરવું જોઈએ, અને સપ્તાહના અંતે આ મશીન બિલકુલ કામ કરવું જોઈએ નહીં. એવું લાગે છે કે બધું ખૂબ જ સરળ છે, પરંતુ અહીં શું કહેવું મહત્વપૂર્ણ છે? આ મૂળભૂત શેડ્યૂલ પર આ સરળ પ્રેક્ટિસનો અમલ કરીને, તે તમને આ વાતાવરણને જાળવવાની કિંમત 70% ઘટાડવાની મંજૂરી આપે છે, એટલે કે તમે તમારા dev, QA, ડેમો, પર્યાવરણની કિંમત લીધી અને તેને 3 વડે વિભાજિત કરી.

સવાલ એ છે કે બાકીના પૈસાનું શું કરવું? ઉદાહરણ તરીકે, ડેવલપર્સે ReSharper ખરીદવું જોઈએ જો તેમની પાસે પહેલેથી ન હોય. અથવા કોકટેલ પાર્ટી કરો. જો તમારી પાસે અગાઉ એક જ વાતાવરણ હતું જેમાં dev અને QA બંને ચરતા હતા, અને બસ, હવે તમે 3 અલગ-અલગ બનાવી શકો છો અને લોકો એકબીજામાં દખલ નહીં કરે.

સતત પ્રદર્શન માપન સાથેની સ્લાઇડ અંગે, જો પ્રોજેક્ટમાં ડેટાબેઝમાં અમારી પાસે 1 રેકોર્ડ હોય, તો બે મહિના પછી એક મિલિયન હોય તો અમે કામગીરીની તુલના કેવી રીતે કરી શકીએ? કેવી રીતે સમજવું કે શા માટે અને પ્રદર્શનને માપવાનો મુદ્દો શું છે?

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

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

શું આપણે વિશિષ્ટ પરીક્ષણ વાતાવરણમાં પ્રદર્શનને માપવા વિશે વાત કરી રહ્યા છીએ? એટલે કે, આ ઉત્પાદન નથી?

હા, આ ઉત્પાદન નથી, આ એક પરીક્ષણ વાતાવરણ છે, જે હંમેશા સમાન હોય છે જેથી તમે તેની અગાઉના માપ સાથે સરખામણી કરી શકો.

સમજાયું આભાર!

જો ત્યાં કોઈ પ્રશ્નો નથી, તો મને લાગે છે કે અમે સમાપ્ત કરી શકીએ છીએ. આભાર!

સોર્સ: www.habr.com