DevOps LEGO: અમે પાઇપલાઇનને ક્યુબ્સમાં કેવી રીતે નાખ્યો

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

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

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

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

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

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

તેથી, અમારી પાસે એક તરફ સમસ્યાઓનો સમૂહ છે, તો બીજી તરફ અમારી પાસે DevOps જ્ઞાન, પ્રથાઓ અને સાધનો છે. શા માટે દરેક સાથે અનુભવ શેર કરતા નથી?

DevOps કન્સ્ટ્રક્ટર બનાવવું

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

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

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

પ્રક્રિયાઓ

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

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

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

સંસ્કૃતિ

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

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

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

લોકો

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

ટેકનોલોજી

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

કોડ તરીકે ઈન્ફ્રાસ્ટ્રક્ચર

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

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

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

સતત ડિલિવરી અને દેખરેખ

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

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

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

કોને અમારી જરૂર પડશે DevOps ડિઝાઇનર?

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

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

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

સોર્સ: www.habr.com