ભાગ 1: વેબ/એન્ડ્રોઇડ

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

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

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

સોર્સ: http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

અહીં અમે કદાચ પ્રારંભિક ભાગ સાથે સમાપ્ત કરીશું અને આ લેખના હેતુ પર ધ્યાન કેન્દ્રિત કરીશું. 

આ લેખ શેના વિશે છે?

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

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

આ લેખમાં શું નથી

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

આ કરવામાં આવે છે કારણ કે: 

• આ સામગ્રી વિવિધ સ્રોતો (દસ્તાવેજીકરણ, પુસ્તકો, વિડિઓ અભ્યાસક્રમો) માં શોધવા માટે ખૂબ જ સરળ છે;
• જો આપણે વધુ ઊંડાણમાં જવાની શરૂઆત કરીએ, તો આપણે આ લેખના 10, 20, 30 ભાગ લખવા પડશે (જ્યારે યોજનાઓ 2-3 છે);
• હું ફક્ત તમારો સમય બગાડવા માંગતો નથી કારણ કે તમે સમાન લક્ષ્યોને પ્રાપ્ત કરવા માટે અન્ય સાધનોનો ઉપયોગ કરવા માગો છો.

પ્રેક્ટિસ

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

યોજના

પગલું
ટેકનોલોજી
સાધનો

1
સ્થાનિક ચાલી (વેબ / એન્ડ્રોઇડ ડેમો પરીક્ષણો તૈયાર કરો અને તેને સ્થાનિક રીતે ચલાવો) 
Node.js, સેલેનિયમ, Appium

2
સંસ્કરણ નિયંત્રણ સિસ્ટમો 
ગિટ

3
કન્ટેનરાઇઝેશન
ડોકર, સેલેનિયમ ગ્રીડ, સેલેનોઇડ (વેબ, એન્ડ્રોઇડ)

4
CI/CD
Gitlab CI

5
મેઘ પ્લેટફોર્મ
Google Cloud Platform

6
ઓર્કેસ્ટ્રેશન
ક્યુબર્નેટિસ

7
કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર (IaC)
ટેરાફોર્મ, જવાબી

દરેક વિભાગનું માળખું

વર્ણનને સ્પષ્ટ રાખવા માટે, દરેક વિભાગનું વર્ણન નીચેની રૂપરેખા અનુસાર કરવામાં આવ્યું છે:

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

1. સ્થાનિક સ્તરે પરીક્ષણો ચલાવો

તકનીકીનું સંક્ષિપ્ત વર્ણન

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

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

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

ઓટોમેશન ઈન્ફ્રાસ્ટ્રક્ચર માટે મૂલ્ય

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

ઈન્ફ્રાસ્ટ્રક્ચરની વર્તમાન સ્થિતિનું ચિત્ર

અન્વેષણ કરવા માટેની લિંક્સ

• સેલેનિયમ
• એપિયમ
• એન્ડ્રોઇડ એમ્યુલેટર
• સેલેનિયમ જેએસ ગિટહબ ઉદાહરણો
• Appium JS GitHub ઉદાહરણો

સમાન સાધનો

• સેલેનિયમ/એપિયમ પરીક્ષણો સાથે જોડાણમાં તમને ગમે તેવી કોઈપણ પ્રોગ્રામિંગ ભાષા;
• કોઈપણ પરીક્ષણો;
• કોઈપણ ટેસ્ટ રનર.

2. સંસ્કરણ નિયંત્રણ સિસ્ટમો (Git)

તકનીકીનું સંક્ષિપ્ત વર્ણન

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

ઓટોમેશન ઈન્ફ્રાસ્ટ્રક્ચર માટે મૂલ્ય

અને અહીં તમે વાજબી પ્રશ્ન પૂછી શકો છો: “તે અમને ગિટ વિશે કેમ કહે છે? દરેક વ્યક્તિ આ જાણે છે અને તેનો ઉપયોગ વિકાસ કોડ અને સ્વતઃ-પરીક્ષણ કોડ બંને માટે કરે છે. તમે બિલકુલ સાચા હશો, પરંતુ આ લેખમાં આપણે ઈન્ફ્રાસ્ટ્રક્ચર વિશે વાત કરી રહ્યા છીએ અને આ વિભાગ વિભાગ 7 માટે પૂર્વાવલોકન તરીકે કાર્ય કરે છે: “કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર (IaC)”. અમારા માટે, આનો અર્થ એ છે કે પરીક્ષણ સહિત સમગ્ર ઈન્ફ્રાસ્ટ્રક્ચર કોડના રૂપમાં વર્ણવેલ છે, તેથી અમે તેમાં વર્ઝનિંગ સિસ્ટમ્સ પણ લાગુ કરી શકીએ છીએ અને વિકાસ અને ઓટોમેશન કોડ જેવા જ લાભ મેળવી શકીએ છીએ.

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

ઈન્ફ્રાસ્ટ્રક્ચરની વર્તમાન સ્થિતિનું ચિત્ર

અન્વેષણ કરવા માટેની લિંક્સ

• સંસ્કરણ નિયંત્રણ શું છે
• ગિટ
• પ્રારંભ કરવું - સંસ્કરણ નિયંત્રણ વિશે

સમાન સાધનો

• એસવીએન
• મર્ક્યુરિયલ 
• માઈક્રોસોફ્ટ TFS (હવે Azure DevOps સેવાઓનો ભાગ છે)

3. કન્ટેનરાઇઝેશન (ડોકર)

તકનીકીનું સંક્ષિપ્ત વર્ણન

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

ઉત્ક્રાંતિનો આગળનો તબક્કો વર્ચ્યુઅલ મશીનો (VMs) હતો, જેણે બિનઉપયોગી સંસાધનો પર નાણાં બગાડવાની સમસ્યાને હલ કરી હતી. આ ટેક્નોલોજીએ સંપૂર્ણપણે અલગ જગ્યા ફાળવીને સમાન સર્વરમાં એકબીજાથી સ્વતંત્ર રીતે એપ્લિકેશન ચલાવવાનું શક્ય બનાવ્યું. પરંતુ, કમનસીબે, કોઈપણ તકનીકમાં તેની ખામીઓ છે. VM ચલાવવા માટે સંપૂર્ણ ઓપરેટિંગ સિસ્ટમની જરૂર છે, જે CPU, RAM, સ્ટોરેજનો ઉપયોગ કરે છે અને OS પર આધાર રાખીને, લાયસન્સ ખર્ચને ધ્યાનમાં લેવાની જરૂર છે. આ પરિબળો લોડિંગ ઝડપને અસર કરે છે અને પોર્ટેબિલિટીને મુશ્કેલ બનાવે છે.

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

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

ઓટોમેશન ઈન્ફ્રાસ્ટ્રક્ચર માટે મૂલ્ય

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

• સેલેનિયમ અને ખાસ કરીને એપિયમ ઇન્સ્ટોલ કરતી વખતે મોટી સંખ્યામાં અવલંબન;
• બ્રાઉઝર્સ, સિમ્યુલેટર અને ડ્રાઇવરોના સંસ્કરણો વચ્ચે સુસંગતતા સમસ્યાઓ;
• બ્રાઉઝર્સ/સિમ્યુલેટર માટે અલગ જગ્યાનો અભાવ, જે ખાસ કરીને સમાંતર દોડવા માટે મહત્વપૂર્ણ છે;
• જો તમારે એક જ સમયે 10, 50, 100 અથવા તો 1000 બ્રાઉઝર ચલાવવાની જરૂર હોય તો તેનું સંચાલન અને જાળવણી મુશ્કેલ છે.

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

ડોકરમાં સેલેનિયમ ગ્રીડ

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

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

વેબ માટે સેલેનોઇડ

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

પરંતુ, અરે, સેલેનોઇડ હજી પણ સિલ્વર બુલેટ નથી. અમને 'બ્રાઉઝર ઓન ડિમાન્ડ' સુવિધા મળી છે, પરંતુ 'માગ પર સંસાધનો' સુવિધા હજી ઉપલબ્ધ નથી. સેલેનોઇડનો ઉપયોગ કરવા માટે, આપણે તેને ભૌતિક હાર્ડવેર પર અથવા VM પર જમાવવું જોઈએ, જેનો અર્થ છે કે આપણે અગાઉથી જાણવું જોઈએ કે કેટલા સંસાધનોની ફાળવણી કરવાની જરૂર છે. હું માનું છું કે નાના પ્રોજેક્ટ માટે આ કોઈ સમસ્યા નથી જે 10, 20 અથવા તો 30 બ્રાઉઝર્સને સમાંતરમાં ચલાવે છે. પરંતુ જો આપણને 100, 500, 1000 કે તેથી વધુની જરૂર હોય તો શું? આટલા બધા સંસાધનોની જાળવણી અને ચૂકવણી કરવાનો કોઈ અર્થ નથી. આ લેખના વિભાગો 5 અને 6 માં, અમે એવા ઉકેલોની ચર્ચા કરીશું જે તમને માપન કરવાની મંજૂરી આપે છે, જેનાથી કંપનીના ખર્ચમાં નોંધપાત્ર ઘટાડો થાય છે.

એન્ડ્રોઇડ માટે સેલેનોઇડ

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

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

ઈન્ફ્રાસ્ટ્રક્ચરની વર્તમાન સ્થિતિનું ચિત્ર

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

અન્વેષણ કરવા માટેની લિંક્સ

• ડોકર: કન્ટેનર શું છે
• ડોકર: પ્રારંભ કરો
• ડોકર માટે 5 કન્ટેનર વિકલ્પો
• સેલેનિયમ ગ્રીડ
• સેલેનિયમ ડોકર
• સેલેનોઇડ
• સેલેનોઇડ ગીથબ
• Android ઇમ્યુલેટર માટે KVM સેટઅપ
• ડોકર ડીપ ડાઇવ પુસ્તક

સમાન સાધનો

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

4.CI/CD

તકનીકીનું સંક્ષિપ્ત વર્ણન

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

તેથી, ત્યાં 3 શરતો છે: CI - સતત એકીકરણ, CD - સતત ડિલિવરી અને ફરીથી CD - સતત ડિપ્લોયમેન્ટ. (નીચે હું અંગ્રેજીમાં આ શબ્દોનો ઉપયોગ કરીશ). દરેક ફેરફાર તમારી ડેવલપમેન્ટ પાઇપલાઇનમાં ઘણા વધારાના પગલાં ઉમેરે છે. પણ શબ્દ સતત (સતત) સૌથી મહત્વની વસ્તુ છે. આ સંદર્ભમાં, અમારો મતલબ એવો છે કે જે શરૂઆતથી અંત સુધી થાય છે, વિક્ષેપ અથવા મેન્યુઅલ હસ્તક્ષેપ વિના. ચાલો આ સંદર્ભમાં CI & CD અને CD જોઈએ.

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

ઓટોમેશન ઈન્ફ્રાસ્ટ્રક્ચર માટે મૂલ્ય

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

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

Gitlab CI/CD એ API સાથેની વેબ એપ્લિકેશન છે જે તેની સ્થિતિને ડેટાબેઝમાં સંગ્રહિત કરે છે, પ્રોજેક્ટ્સ/બિલ્ડ્સનું સંચાલન કરે છે અને વપરાશકર્તા ઇન્ટરફેસ પ્રદાન કરે છે. ગિટલેબ રનર એ એક એપ્લિકેશન છે જે બિલ્ડ્સની પ્રક્રિયા કરે છે. તેને અલગથી તૈનાત કરી શકાય છે અને API દ્વારા GitLab CI/CD સાથે કામ કરે છે. ચાલતા પરીક્ષણો માટે તમારે Gitlab દાખલા અને રનર બંનેની જરૂર છે.

ઈન્ફ્રાસ્ટ્રક્ચરની વર્તમાન સ્થિતિનું ચિત્ર

અન્વેષણ કરવા માટેની લિંક્સ

• માર્ટિન ફાઉલર: સતત એકીકરણ
• ગિટલેબ સીઆઈ/સીડી
• સતત એકીકરણ પુસ્તક
• સતત ડિલિવરી બુક

સમાન સાધનો

• જેનકિન્સ
• ટીમસિટી
• ટ્રેવિસ 
• અને બીજા ઘણા

5. ક્લાઉડ પ્લેટફોર્મ

તકનીકીનું સંક્ષિપ્ત વર્ણન

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

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

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

ઓટોમેશન ઈન્ફ્રાસ્ટ્રક્ચર માટે મૂલ્ય

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

સૌથી વધુ લોકપ્રિય ક્લાઉડ પ્રદાતાઓ એમેઝોન વેબ સેવાઓ (AWS), Microsoft Azure, Google Cloud Platform (GCP) છે. કેવી રીતે કરવું માર્ગદર્શિકા GCP નો ઉપયોગ કેવી રીતે કરવો તેના ઉદાહરણો પ્રદાન કરે છે, પરંતુ સામાન્ય રીતે તમે ઓટોમેશન કાર્યો માટે શું ઉપયોગ કરો છો તેનાથી કોઈ ફરક પડતો નથી. તે બધા લગભગ સમાન કાર્યક્ષમતા પ્રદાન કરે છે. સામાન્ય રીતે, પ્રદાતા પસંદ કરવા માટે, મેનેજમેન્ટ કંપનીના સમગ્ર ઈન્ફ્રાસ્ટ્રક્ચર અને વ્યવસાય જરૂરિયાતો પર ધ્યાન કેન્દ્રિત કરે છે, જે આ લેખના અવકાશની બહાર છે. ઓટોમેશન એન્જીનિયરો માટે, ક્લાઉડ પ્રદાતાઓના ઉપયોગની તુલના ખાસ કરીને પરીક્ષણ હેતુઓ માટે, જેમ કે સોસ લેબ્સ, બ્રાઉઝરસ્ટેક, બીટબાર અને તેથી વધુ માટે ક્લાઉડ પ્લેટફોર્મના ઉપયોગ સાથે કરવી વધુ રસપ્રદ રહેશે. તો ચાલો તે પણ કરીએ! મારા મતે, સોસ લેબ્સ એ સૌથી પ્રખ્યાત ક્લાઉડ ટેસ્ટિંગ ફાર્મ છે, તેથી જ મેં તેનો ઉપયોગ સરખામણી માટે કર્યો. 

ઓટોમેશન હેતુઓ માટે GCP વિ સોસ લેબ્સ:

ચાલો કલ્પના કરીએ કે આપણે એક સાથે 8 વેબ પરીક્ષણો અને 8 Android પરીક્ષણો ચલાવવાની જરૂર છે. આ માટે આપણે જીસીપીનો ઉપયોગ કરીશું અને સેલેનોઈડ સાથે 2 વર્ચ્યુઅલ મશીનો ચલાવીશું. પ્રથમ એક પર અમે બ્રાઉઝર સાથે 8 કન્ટેનર ઉભા કરીશું. બીજા પર એમ્યુલેટર સાથે 8 કન્ટેનર છે. ચાલો કિંમતો પર એક નજર કરીએ:  

Chrome સાથે એક કન્ટેનર ચલાવવા માટે, અમને જરૂર છે n1-ધોરણ-1 કાર એન્ડ્રોઇડના કિસ્સામાં તે હશે n1-ધોરણ-4 એક ઇમ્યુલેટર માટે. વાસ્તવમાં, વધુ લવચીક અને સસ્તી રીત એ છે કે CPU/મેમરી માટે ચોક્કસ વપરાશકર્તા મૂલ્યો સેટ કરો, પરંતુ આ ક્ષણે સોસ લેબ્સ સાથે સરખામણી કરવા માટે આ મહત્વપૂર્ણ નથી.

અને અહીં સોસ લેબ્સનો ઉપયોગ કરવા માટેના ટેરિફ છે:

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

જરૂરી સંસાધનો
મોન્ટલી
કામ નાં કલાકો(8am - 8pm)
કામ નાં કલાકો+ અગ્રિમ

વેબ માટે GCP
n1-ધોરણ-1 x 8 = n1-ધોરણ-8
$194.18
23 દિવસ * 12 કલાક * 0.38 = $104.88 
23 દિવસ * 12 કલાક * 0.08 = $22.08

વેબ માટે સોસ લેબ્સ
વર્ચ્યુઅલ Cloud8 સમાંતર પરીક્ષણો
$1.559
-
-

Android માટે GCP
n1-સ્ટાન્ડર્ડ-4 x 8: n1-સ્ટાન્ડર્ડ-16
$776.72
23 દિવસ * 12 કલાક * 1.52 = $419.52 
23 દિવસ * 12 કલાક * 0.32 = $88.32

Android માટે સોસ લેબ્સ
વાસ્તવિક ઉપકરણ ક્લાઉડ 8 સમાંતર પરીક્ષણો
$1.999
-
-

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

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

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

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

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

ઈન્ફ્રાસ્ટ્રક્ચરની વર્તમાન સ્થિતિનું ચિત્ર

અન્વેષણ કરવા માટેની લિંક્સ

• જીસીપી
• GCP: પ્રીમ્પ્ટીબલ
• GCP: VM કિંમત
• સોસલેબ્સ
• ક્લાઉડ પ્રદાતાઓની તુલના

સમાન સાધનો:

• AWS 
• નીલમ

6. ઓર્કેસ્ટ્રેશન

તકનીકીનું સંક્ષિપ્ત વર્ણન

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

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

સત્યમાં, કુબરનેટ્સને શરૂઆતથી મેન્યુઅલી જમાવવું એ બિલકુલ મામૂલી કાર્ય નથી. હું પ્રખ્યાત માર્ગદર્શિકા "કુબરનેટ્સ ધ હાર્ડ વે" ની એક લિંક મૂકીશ અને જો તમને રસ હોય, તો તમે તેનો અભ્યાસ કરી શકો છો. પરંતુ, સદભાગ્યે, ત્યાં વૈકલ્પિક પદ્ધતિઓ અને સાધનો છે. GCP માં Google Kubernetes Engine (GKE) નો ઉપયોગ કરવાનો સૌથી સરળ રસ્તો છે, જે તમને થોડા ક્લિક્સમાં તૈયાર ક્લસ્ટર મેળવવાની મંજૂરી આપશે. હું શીખવાનું શરૂ કરવા માટે આ અભિગમનો ઉપયોગ કરવાની ભલામણ કરું છું, કારણ કે તે તમને આંતરિક ઘટકોને એકબીજા સાથે કેવી રીતે સંકલિત કરવા જોઈએ તે શીખવાને બદલે તમારા કાર્યો માટે K8 નો ઉપયોગ કેવી રીતે કરવો તે શીખવા પર ધ્યાન કેન્દ્રિત કરવાની મંજૂરી આપશે. 

ઓટોમેશન ઈન્ફ્રાસ્ટ્રક્ચર માટે મૂલ્ય

ચાલો K8s પ્રદાન કરે છે તે કેટલીક નોંધપાત્ર સુવિધાઓ પર એક નજર કરીએ:

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

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

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

હવે ઉપરોક્ત શરતોના સંદર્ભમાં અમારા ટૂલ્સ જોઈએ.

સેલેનિયમ ગ્રીડ

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

સેલેનોઇડ:

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

ચંદ્ર:

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

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

તેથી, ચંદ્ર એક મહાન ઉકેલ છે, પરંતુ એક સમસ્યા છે: તે મફત નથી. કિંમત સત્રોની સંખ્યા પર આધારિત છે. તમે માત્ર 0-4 સત્રો જ મફતમાં ચલાવી શકો છો, જે ખાસ ઉપયોગી નથી. પરંતુ, પાંચમા સત્રથી શરૂ કરીને, તમારે દરેક માટે $5 ચૂકવવા પડશે. પરિસ્થિતિ કંપનીએ અલગ અલગ હોઈ શકે છે, પરંતુ અમારા કિસ્સામાં, ચંદ્રનો ઉપયોગ અર્થહીન છે. મેં ઉપર વર્ણવ્યા મુજબ, અમે માંગ પર સેલેનિયમ ગ્રીડ સાથે VM ચલાવી શકીએ છીએ અથવા ક્લસ્ટરમાં નોડ્સની સંખ્યા વધારી શકીએ છીએ. લગભગ એક પાઇપલાઇન માટે, અમે 500 બ્રાઉઝર લોન્ચ કરીએ છીએ અને પરીક્ષણો પૂર્ણ થયા પછી તમામ સંસાધનો બંધ કરીએ છીએ. જો આપણે ચંદ્રનો ઉપયોગ કરીએ, તો અમારે દર મહિને વધારાના 500 x 5 = $2500 ચૂકવવા પડશે, પછી ભલે આપણે કેટલી વાર પરીક્ષણો ચલાવીએ. ફરીથી, હું એમ નથી કહેતો કે ચંદ્રનો ઉપયોગ કરશો નહીં. તમારા કાર્યો માટે, આ એક અનિવાર્ય ઉકેલ હોઈ શકે છે, ઉદાહરણ તરીકે, જો તમારી પાસે તમારી સંસ્થામાં ઘણા પ્રોજેક્ટ/ટીમ છે અને તમારે દરેક માટે એક વિશાળ સામાન્ય ક્લસ્ટરની જરૂર છે. હંમેશની જેમ, હું અંતમાં એક લિંક છોડું છું અને તમારા કાર્યના સંદર્ભમાં તમામ જરૂરી ગણતરીઓ કરવાની ભલામણ કરું છું.

કેલિસ્ટો: (ધ્યાન આપો! આ મૂળ લેખમાં નથી અને ફક્ત રશિયન અનુવાદમાં જ સમાયેલ છે)

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

ઈન્ફ્રાસ્ટ્રક્ચરની વર્તમાન સ્થિતિનું ચિત્ર

અન્વેષણ કરવા માટેની લિંક્સ

• કુબરનેટ્સ: સેટઅપ
• કુબરનેટ્સ: સખત રસ્તો
• કુબરનેટ્સ: સેલેનિયમ
• GCP: કુબરનેટ્સ એન્જિન
• ચંદ્ર
• કુબરનેટ્સ બુક
• કુબરનેટ્સનો ઉપયોગ કરીને વિતરિત ઓટોમેશન
• સેલેનિયમ ગ્રીડ 4
• Callisto GitHub
• Wrike TechClub (કૅલિસ્ટો)

સમાન સાધનો

• ડોકર સ્વોર્મ 
• મેરેથોન 

7. કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર (IaC)

તકનીકીનું સંક્ષિપ્ત વર્ણન

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

ચાલો આ અભિગમનો ઉપયોગ કરવાની પ્રેરણાથી પ્રારંભ કરીએ. અમે પહેલેથી જ ચર્ચા કરી છે કે GitlabCI માં પરીક્ષણો ચલાવવા માટે, અમને Gitlab રનરને ચલાવવા માટે ઓછામાં ઓછા સંસાધનોની જરૂર પડશે. અને બ્રાઉઝર્સ/ઇમ્યુલેટર સાથે કન્ટેનર ચલાવવા માટે, અમારે VM અથવા ક્લસ્ટર આરક્ષિત કરવાની જરૂર છે. સંસાધનોના પરીક્ષણ ઉપરાંત, અમને વિકાસ, સ્ટેજીંગ, ઉત્પાદન વાતાવરણને ટેકો આપવા માટે ક્ષમતાની નોંધપાત્ર માત્રાની જરૂર છે, જેમાં ડેટાબેઝ, સ્વચાલિત સમયપત્રક, નેટવર્ક ગોઠવણી, લોડ બેલેન્સર્સ, વપરાશકર્તા અધિકારો વગેરેનો પણ સમાવેશ થાય છે. મુખ્ય મુદ્દો તે બધાને સમર્થન આપવા માટે જરૂરી પ્રયત્નો છે. અમે ફેરફારો કરી શકીએ છીએ અને અપડેટ્સ રોલ આઉટ કરી શકીએ છીએ તે ઘણી રીતો છે. ઉદાહરણ તરીકે, GCP ના સંદર્ભમાં, અમે બ્રાઉઝરમાં UI કન્સોલનો ઉપયોગ કરી શકીએ છીએ અને બટનો પર ક્લિક કરીને બધી ક્રિયાઓ કરી શકીએ છીએ. ક્લાઉડ એન્ટિટી સાથે ક્રિયાપ્રતિક્રિયા કરવા માટે API કૉલ્સનો ઉપયોગ કરવો અથવા ઇચ્છિત મેનિપ્યુલેશન્સ કરવા માટે gcloud કમાન્ડ લાઇન ઉપયોગિતાનો ઉપયોગ કરવાનો વિકલ્પ હશે. પરંતુ ખરેખર મોટી સંખ્યામાં વિવિધ એકમો અને ઈન્ફ્રાસ્ટ્રક્ચર તત્વો સાથે, બધી કામગીરી જાતે કરવી મુશ્કેલ અથવા તો અશક્ય બની જાય છે. તદુપરાંત, આ બધી મેન્યુઅલ ક્રિયાઓ અનિયંત્રિત છે. અમે અમલ પહેલાં તેમને સમીક્ષા માટે સબમિટ કરી શકતા નથી, વર્ઝન કંટ્રોલ સિસ્ટમનો ઉપયોગ કરી શકતા નથી અને ઘટના તરફ દોરી જતા ફેરફારોને ઝડપથી પાછા ખેંચી શકતા નથી. આવી સમસ્યાઓને ઉકેલવા માટે, એન્જિનિયરોએ ઓટોમેટિક બેશ/શેલ સ્ક્રિપ્ટો બનાવી અને બનાવી, જે અગાઉની પદ્ધતિઓ કરતાં વધુ સારી નથી, કારણ કે તે પ્રક્રિયાગત શૈલીમાં ઝડપથી વાંચવા, સમજવા, જાળવવા અને સંશોધિત કરવા એટલી સરળ નથી.

આ લેખ અને કેવી રીતે કરવું તે માર્ગદર્શિકામાં, હું IaC પ્રેક્ટિસથી સંબંધિત 2 સાધનોનો ઉપયોગ કરું છું. આ Terraform અને Ansible છે. કેટલાક લોકો માને છે કે તે જ સમયે તેનો ઉપયોગ કરવાનો કોઈ અર્થ નથી, કારણ કે તેમની કાર્યક્ષમતા સમાન છે અને તેઓ વિનિમયક્ષમ છે. પરંતુ હકીકત એ છે કે શરૂઆતમાં તેમને સંપૂર્ણપણે અલગ કાર્યો આપવામાં આવે છે. અને હકીકત એ છે કે આ સાધનો એકબીજાના પૂરક હોવા જોઈએ તે HashiCorp અને RedHatનું પ્રતિનિધિત્વ કરતા વિકાસકર્તાઓ દ્વારા સંયુક્ત પ્રસ્તુતિમાં પુષ્ટિ કરવામાં આવી હતી. વૈચારિક તફાવત એ છે કે ટેરાફોર્મ એ સર્વરોનું સંચાલન કરવા માટેનું એક જોગવાઈ સાધન છે. જ્યારે Ansible એ રૂપરેખાંકન વ્યવસ્થાપન સાધન છે જેનું કાર્ય આ સર્વર્સ પર સોફ્ટવેરને ઇન્સ્ટોલ, રૂપરેખાંકિત અને સંચાલિત કરવાનું છે.

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

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

ઓટોમેશન ઈન્ફ્રાસ્ટ્રક્ચર માટે મૂલ્ય

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

ટેસ્ટ ઓટોમેશનના સંદર્ભમાં ટેરાફોર્મ અને એન્સિબલનો ઉપયોગ કરવાના કેટલાક ઉદાહરણો અને અમે પહેલાં ચર્ચા કરેલ ટૂલ્સ અહીં આપ્યા છે:

1. ટેરાફોર્મનો ઉપયોગ કરીને VM અને ક્લસ્ટરોની જરૂરી લાક્ષણિકતાઓ અને પરિમાણોનું વર્ણન કરો.

2. Ansible નો ઉપયોગ કરીને, પરીક્ષણ માટે જરૂરી ટૂલ્સ ઇન્સ્ટોલ કરો: ડોકર, સેલેનોઇડ, સેલેનિયમ ગ્રીડ અને બ્રાઉઝર/ઇમ્યુલેટરના જરૂરી વર્ઝન ડાઉનલોડ કરો.

3. ટેરાફોર્મનો ઉપયોગ કરીને, VM ની લાક્ષણિકતાઓનું વર્ણન કરો જેમાં GitLab રનરને લોન્ચ કરવામાં આવશે.

4. Ansible, સેટ સેટિંગ્સ અને રૂપરેખાંકનોનો ઉપયોગ કરીને GitLab રનર અને જરૂરી સાથેના સાધનો ઇન્સ્ટોલ કરો.

ઈન્ફ્રાસ્ટ્રક્ચરની વર્તમાન સ્થિતિનું ચિત્ર

અન્વેષણ કરવા માટેની લિંક્સ:

• ટેરાફોર્મ
• Ansible
• Ansible અને Terraform એકસાથે વધુ સારી રીતે
• ટેરાફોર્મ માટે વ્યાપક માર્ગદર્શિકા
• શા માટે આપણે ટેરાફોર્મનો ઉપયોગ કરીએ છીએ અને શેફ, પપેટ, એન્સિબલ, સોલ્ટસ્ટેક અથવા ક્લાઉડફોર્મેશનનો ઉપયોગ નથી
• GCP: IaC

સમાન સાધનો

• વડા
• પપેટ
• સોલ્ટસ્ટેક
• જાગ્રત

ચાલો તેનો સરવાળો કરીએ!

પગલું
ટેકનોલોજી
સાધનો
ઓટોમેશન ઈન્ફ્રાસ્ટ્રક્ચર માટે મૂલ્ય

1
લોકલ ચાલી
Node.js, સેલેનિયમ, Appium

• વેબ અને મોબાઇલ માટે સૌથી લોકપ્રિય સાધનો
• ઘણી ભાષાઓ અને પ્લેટફોર્મને સપોર્ટ કરે છે (Node.js સહિત)

2
સંસ્કરણ નિયંત્રણ સિસ્ટમો 
ગિટ

• વિકાસ કોડ સાથે સમાન લાભો

3
કન્ટેનરાઇઝેશન
ડોકર, સેલેનિયમ ગ્રીડ, સેલેનોઇડ (વેબ, એન્ડ્રોઇડ)

• સમાંતર પરીક્ષણો ચાલી રહ્યા છે
• અલગ વાતાવરણ
• સરળ, લવચીક સંસ્કરણ અપગ્રેડ
• બિનઉપયોગી સંસાધનોને ગતિશીલ રીતે રોકવું
• સેટ કરવા માટે સરળ

4
CI/CD
Gitlab CI

• પાઇપલાઇનના ભાગનું પરીક્ષણ કરે છે
• ઝડપી પ્રતિસાદ
• સમગ્ર કંપની/ટીમ માટે દૃશ્યતા

5
મેઘ પ્લેટફોર્મ
Google Cloud Platform

• માંગ પર સંસાધનો (જરૂરી હોય ત્યારે જ ચૂકવણી કરીએ છીએ)
• સંચાલન અને અપડેટ કરવા માટે સરળ
• તમામ સંસાધનોની દૃશ્યતા અને નિયંત્રણ

6
ઓર્કેસ્ટ્રેશન
ક્યુબર્નેટિસ
પોડ્સની અંદર બ્રાઉઝર્સ/ઇમ્યુલેટરવાળા કન્ટેનરના સંદર્ભમાં:

• સ્કેલિંગ/ઓટો સ્કેલિંગ
• સ્વ-ઉપચાર
• વિક્ષેપ વિના અપડેટ્સ અને રોલબેક

7
કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર (IaC)
ટેરાફોર્મ, જવાબી

• વિકાસ ઈન્ફ્રાસ્ટ્રક્ચર સાથે સમાન લાભો
• કોડ વર્ઝનિંગના તમામ ફાયદા
• ફેરફારો કરવા અને જાળવવા માટે સરળ
• સંપૂર્ણપણે સ્વચાલિત

માઇન્ડ મેપ ડાયાગ્રામ: ઇન્ફ્રાસ્ટ્રક્ચરનું ઉત્ક્રાંતિ

પગલું 1: સ્થાનિક

પગલું 2: VCS

પગલું 3: કન્ટેનરાઇઝેશન 

પગલું 4: CI/CD 

પગલું 5: ક્લાઉડ પ્લેટફોર્મ્સ

પગલું 6:ઓર્કેસ્ટ્રેશન

પગલું 7: IaC

શું આગામી છે?

તેથી, આ લેખનો અંત છે. પરંતુ નિષ્કર્ષમાં, હું તમારી સાથે કેટલાક કરારો સ્થાપિત કરવા માંગુ છું.

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

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

મારી બાજુથી

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

ઉપરાંત, મેં મોનિટરિંગને લગતા મોટા વિષયોનો ઉલ્લેખ કર્યો નથી. ભાગ 3 માં, હું સૌથી વધુ લોકપ્રિય ઈન્ફ્રાસ્ટ્રક્ચર મોનિટરિંગ ટૂલ્સ અને કયા ડેટા અને મેટ્રિક્સને ધ્યાનમાં લેવા તે જોવા જઈ રહ્યો છું.

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

સોર્સ: www.habr.com