આજે, મોટાભાગના સોફ્ટવેર ઉત્પાદનો ટીમોમાં વિકસાવવામાં આવે છે. સફળ ટીમના વિકાસ માટેની શરતોને સરળ રેખાકૃતિના રૂપમાં રજૂ કરી શકાય છે.

એકવાર તમે તમારો કોડ લખી લો, પછી તમારે તેની ખાતરી કરવાની જરૂર છે:

1. .
2. તે તમારા સાથીદારોએ લખેલા કોડ સહિત કંઈપણ તોડતું નથી.

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

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

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

એવિટો મોબાઇલ ડેવલપમેન્ટ ટીમમાં સતત એકીકરણ કેવી રીતે અમલમાં આવ્યું અને વિકસિત થયું, તેઓ દરરોજ 0 થી 450 બિલ્ડ કેવી રીતે ગયા અને તે બિલ્ડ મશીનો દિવસમાં 200 કલાક ભેગા થાય છે, નિકોલાઈ નેસ્ટેરોવ કહે છે (નેસ્ટેરોવ) CI/CD એન્ડ્રોઇડ એપ્લિકેશનના તમામ ઉત્ક્રાંતિવાદી ફેરફારોમાં સહભાગી છે.

વાર્તા એન્ડ્રોઇડ કમાન્ડના ઉદાહરણ પર આધારિત છે, પરંતુ મોટાભાગના અભિગમો iOS પર પણ લાગુ પડે છે.

એક સમયે, એક વ્યક્તિ એવિટો એન્ડ્રોઇડ ટીમમાં કામ કરતી હતી. વ્યાખ્યા મુજબ, તેને સતત એકીકરણમાંથી કંઈપણની જરૂર નહોતી: તેની સાથે સંકલન કરવા માટે કોઈ નહોતું.

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

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

ચકાસે છે

તમારી આંખોથી કોડ જોવો એ સરસ છે, પરંતુ પૂરતું નથી. તેથી, સ્વચાલિત તપાસની રજૂઆત કરવામાં આવી રહી છે.

• સૌ પ્રથમ, અમે તપાસીએ છીએ ARK એસેમ્બલી.
• ઘણું જુનીટ પરીક્ષણો.
• અમે કોડ કવરેજને ધ્યાનમાં લઈએ છીએ, કારણ કે અમે પરીક્ષણો ચલાવી રહ્યા છીએ.

આ તપાસો કેવી રીતે ચલાવવા જોઈએ તે સમજવા માટે, ચાલો એવિટોમાં વિકાસ પ્રક્રિયા જોઈએ.

તે આ રીતે યોજનાકીય રીતે રજૂ કરી શકાય છે:

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

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

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

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

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

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

મૂળભૂત CI (ત્યારબાદ સમય અંદાજ અંદાજિત છે, સ્કેલ માટે જરૂરી છે) ને સંપૂર્ણપણે સેટ કરવામાં અમને બે દિવસ લાગ્યા.

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

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

આ કરવા માટે, અમે એક સરળ બેશ સ્ક્રિપ્ટ લખી છે premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

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

સમસ્યાનું સ્થાનિકીકરણ કરવામાં, ઉકેલ શોધવામાં અને આ સ્ક્રિપ્ટ લખવામાં ત્રણ દિવસ લાગ્યા.

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

આ કેવી રીતે થાય છે તેનું ઉદાહરણ:

બે ડેવલપર્સ એક સાથે A અને B ફીચર્સ પર કામ કરવાનું શરૂ કરે છે. ફીચર Aના ડેવલપર પ્રોજેક્ટમાં એક વણવપરાયેલ ફીચર શોધે છે. answer() અને, એક સારા છોકરા સ્કાઉટની જેમ, તેને દૂર કરે છે. તે જ સમયે, ફીચર B ના ડેવલપર તેની શાખામાં આ કાર્ય માટે એક નવો કોલ ઉમેરે છે.

વિકાસકર્તાઓ તેમનું કાર્ય પૂર્ણ કરે છે અને તે જ સમયે પુલ વિનંતી ખોલે છે. બિલ્ડ્સ લોંચ કરવામાં આવે છે, premerge.sh નવીનતમ વિકાસ સ્થિતિ સંબંધિત પુલ વિનંતીઓને તપાસે છે - તમામ ચેક લીલા છે. તે પછી, લક્ષણ A ની પુલ વિનંતી મર્જ કરવામાં આવે છે, લક્ષણ B ની પુલ વિનંતી મર્જ કરવામાં આવે છે... બૂમ! ડેવલપ બ્રેક્સ કારણ કે ડેવલપ કોડમાં અસ્તિત્વમાં ન હોય તેવા ફંક્શન માટે કૉલ છે.

જ્યારે તે વિકસિત થવાનું નથી, તે છે સ્થાનિક આપત્તિ. આખી ટીમ કંઈપણ એકત્રિત કરી શકતી નથી અને તેને પરીક્ષણ માટે સબમિટ કરી શકતી નથી.

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

આ અમને અનુકૂળ ન હોવાથી, અમે તેને કેવી રીતે અટકાવી શકાય તેના વિકલ્પો શોધવાનું શરૂ કર્યું.

વિકાસ કેવી રીતે તોડવો નહીં

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

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

સૈદ્ધાંતિક રીતે, તે સારું છે. પરંતુ અમે આંકડાઓ જોયા, અને અમારી ટીમમાં સામાન્ય પરિસ્થિતિ 10 ઓપન PR હતી, અને પછી ચેકની સંખ્યા એ પ્રગતિનો સરવાળો છે: 10 + 9 +... + 1 = 55. એટલે કે 10 સ્વીકારવા માટે PRs, તમારે 55 વખત પુનઃબીલ્ડ કરવાની જરૂર છે. અને આ એક આદર્શ પરિસ્થિતિ છે, જ્યારે તમામ તપાસો પ્રથમ વખત પસાર થાય છે, જ્યારે આ ડઝન પર પ્રક્રિયા કરવામાં આવી રહી હોય ત્યારે કોઈ વધારાની પુલ વિનંતી ખોલતું નથી.

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

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

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

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

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

આ પ્લગઇનને અમલમાં મૂકતા પહેલા, અમે પુલ વિનંતી દીઠ સરેરાશ 2,7 સમીક્ષા રન કરીએ છીએ. પ્લગઇન સાથે 3,6 લોન્ચ થયા. આ અમને અનુકૂળ હતું.

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

બિટબકેટ પ્લગઇનનું પ્રથમ સંસ્કરણ લખવામાં અમને બે અઠવાડિયા લાગ્યાં.

નવા ચેક

દરમિયાન, અમારી ટીમ સતત વધતી ગઈ. નવા ચેક ઉમેરવામાં આવ્યા છે.

અમે વિચાર્યું: જો તેમને રોકી શકાય તો ભૂલો શા માટે કરવી? અને તેથી જ તેઓએ અમલ કર્યો સ્ટેટિક કોડ વિશ્લેષણ. અમે લિન્ટથી શરૂઆત કરી, જે એન્ડ્રોઇડ SDK માં સમાવવામાં આવેલ છે. પરંતુ તે સમયે તે કોટલિન કોડ સાથે કેવી રીતે કામ કરવું તે જાણતો ન હતો, અને અમારી પાસે પહેલેથી જ કોટલિનમાં 75% એપ્લિકેશન લખેલી હતી. તેથી, બિલ્ટ-ઇનને લિન્ટમાં ઉમેરવામાં આવ્યા હતા એન્ડ્રોઇડ સ્ટુડિયો તપાસે છે.

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

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

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

ફાયરબેઝ ટેસ્ટ લેબ

તે પસંદ કરવામાં આવ્યું હતું કારણ કે Firebase એ Google ઉત્પાદન છે, એટલે કે તે વિશ્વસનીય અને ક્યારેય મૃત્યુ પામે તેવી શક્યતા નથી. કિંમતો વાજબી છે: વાસ્તવિક ઉપકરણના સંચાલનના કલાક દીઠ $5, ઇમ્યુલેટરના સંચાલનના કલાક દીઠ 1 $.

અમારા CI માં ફાયરબેઝ ટેસ્ટ લેબને લાગુ કરવામાં લગભગ ત્રણ અઠવાડિયા લાગ્યાં.

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

ડોકર + પાયથોન + બેશ

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

અમારું પોતાનું પરીક્ષણ વાતાવરણ બનાવવામાં પાંચ અઠવાડિયા લાગ્યા.

પરિણામે, દરેક પુલ વિનંતી માટે ચેકની વિસ્તૃત મર્જ-બ્લૉકિંગ સૂચિ હતી:

• ARK એસેમ્બલી;
• જુનીટ પરીક્ષણો;
• લીંટ;
• એન્ડ્રોઇડ સ્ટુડિયો તપાસો;
• ઇન્સ્ટ્રુમેન્ટેશન પરીક્ષણો;
• સ્ક્રીનશોટ પરીક્ષણો.

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

કેટલો લાંબો સમય ઘણો લાંબો છે? અમે Bitbucket અને TeamCity માંથી ડેટા વિશ્લેષણ સિસ્ટમમાં અપલોડ કર્યો અને તે સમજાયું સરેરાશ રાહ જોવાનો સમય 45 મિનિટ. એટલે કે, વિકાસકર્તા, પુલ વિનંતી ખોલતી વખતે, બિલ્ડ પરિણામો માટે સરેરાશ 45 મિનિટ રાહ જુએ છે. મારા મતે, આ ઘણું છે, અને તમે તેના જેવું કામ કરી શકતા નથી.

અલબત્ત, અમે અમારા તમામ બિલ્ડ્સને ઝડપી બનાવવાનું નક્કી કર્યું.

ચાલો ઝડપ વધારીએ

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

ખૂબ લાંબો સમય લેતા ચેકને દૂર કરી રહ્યાં છીએ

અમારું સતત એકીકરણ આ પ્રકારની ભૂલો અને સમસ્યાઓને પકડી શકે છે.

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

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

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

પરિણામે, અમારી પાસે બાકી હતું:

• ARK એસેમ્બલી;
• જુનીટ પરીક્ષણો;
• ઇન્સ્ટ્રુમેન્ટેશન પરીક્ષણો.

ગ્રેડલ રીમોટ કેશ

ભારે તપાસ વિના, બધું સારું થઈ ગયું. પરંતુ સંપૂર્ણતાની કોઈ મર્યાદા નથી!

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

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

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

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

નીચે કેશ મિસ ગ્રાફ છે.

ખૂબ જ શરૂઆતમાં, કેશ ચૂકી જવાની ટકાવારી લગભગ 65 હતી. ત્રણ અઠવાડિયા પછી, અમે આ મૂલ્યને 20% સુધી વધારવામાં વ્યવસ્થાપિત થયા. તે બહાર આવ્યું છે કે Android એપ્લિકેશન એકત્રિત કરે છે તે કાર્યોમાં વિચિત્ર સંક્રમિત અવલંબન છે, જેના કારણે ગ્રેડલ કેશ ચૂકી ગયો.

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

અસર વિશ્લેષણ

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

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

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

ઇન્સ્ટ્રુમેન્ટેશન ટેસ્ટના ઑપરેશનને અપગ્રેડ કરવામાં જેથી તેઓ માત્ર સામેલ મોડ્યુલોનું જ પરીક્ષણ કરી શકે તે માટે લગભગ આઠ અઠવાડિયા લાગ્યા.

નિરીક્ષણોને ઝડપી બનાવવાનાં પગલાં સફળતાપૂર્વક કામ કરી રહ્યાં છે. 45 મિનિટથી અમે લગભગ 15 સુધી ગયા. બિલ્ડ માટે એક ક્વાર્ટર કલાક રાહ જોવી તે પહેલાથી જ સામાન્ય છે.

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

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

છ અઠવાડિયા વિગતવાર પ્રતિસાદ પર ખર્ચવામાં આવ્યા હતા.

યોજનાઓ

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

આ ઉપરાંત, અન્ય યોજનાઓ છે.

• રીટર્ન લિન્ટ (અને અન્ય સ્થિર વિશ્લેષણ). અમે આ દિશામાં પહેલેથી જ કામ કરી રહ્યા છીએ.
• PR બ્લોકર પર બધું ચલાવો અંત-થી-અંત પરીક્ષણો બધા SDK વર્ઝન પર.

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

ટિપ્સ

જો હું માત્ર એક સલાહ આપી શકું તો તે આ હશે:

કૃપા કરીને શેલ સ્ક્રિપ્ટો સાથે સાવચેત રહો!

Bash એ ખૂબ જ લવચીક અને શક્તિશાળી સાધન છે, તે સ્ક્રિપ્ટો લખવા માટે ખૂબ અનુકૂળ અને ઝડપી છે. પરંતુ તમે તેની સાથે જાળમાં ફસાઈ શકો છો, અને, કમનસીબે, અમે તેમાં પડ્યા.

તે બધું સરળ સ્ક્રિપ્ટોથી શરૂ થયું જે અમારી બિલ્ડ મશીનો પર ચાલતી હતી:

#!/usr/bin/env bash
./gradlew assembleDebug

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

તમે આવી સ્ક્રિપ્ટોના વિકાસ માટે શ્રમ ખર્ચની કલ્પના કરી શકો છો. હું તમને આ જાળમાં ન પડવાની સલાહ આપું છું.

શું બદલી શકાય છે?

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

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

ટીપ #2: કોડમાં ઈન્ફ્રાસ્ટ્રક્ચર સ્ટોર કરો.

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

સ્ક્રિપ્ટો પ્રોજેક્ટમાં સંગ્રહિત કરી શકાય છે. પર્યાવરણ સાથે શું કરવું?

ટીપ #3: ડોકર પર્યાવરણમાં મદદ કરી શકે છે.

તે ચોક્કસપણે Android વિકાસકર્તાઓને મદદ કરશે; કમનસીબે, iOS પાસે હજી સુધી એક નથી.

આ એક સરળ ડોકર ફાઇલનું ઉદાહરણ છે જેમાં jdk અને android-sdk છે:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

આ ડોકર ફાઇલ લખ્યા પછી (હું તમને એક રહસ્ય કહીશ, તમારે તેને લખવાની જરૂર નથી, પરંતુ ફક્ત તેને GitHub માંથી તૈયાર કરીને ખેંચો) અને છબીને એસેમ્બલ કર્યા પછી, તમને એક વર્ચ્યુઅલ મશીન મળશે જેના પર તમે એપ્લિકેશન બનાવી શકો છો. અને જુનીટ ટેસ્ટ ચલાવો.

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

ટીપ નંબર 4: ભૂલશો નહીં કે નિરીક્ષણો નિરીક્ષણો માટે નથી, પરંતુ લોકો માટે કરવામાં આવે છે.

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

ટીપ #5: સતત એકીકરણ વિકસાવતી વખતે વ્યવહારિક બનો.

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

ટીપ #6: તૈયાર સાધનોનો ઉપયોગ કરો.

હવે ઘણી કંપનીઓ છે જે ક્લાઉડ CI પ્રદાન કરે છે.

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

ટીપ #7: મોટી ટીમમાં, ઇન-હાઉસ સોલ્યુશન્સ વધુ નફાકારક હોય છે.

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

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

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

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

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

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

સતત એકીકરણની પ્રેક્ટિસ કરો. પરંતુ મધ્યસ્થતામાં.

માર્ગ દ્વારા, નિકોલાઈ નેસ્ટેરોવ માત્ર પોતે જ મહાન અહેવાલો આપતા નથી, પણ પ્રોગ્રામ કમિટીના સભ્ય પણ છે. AppsConf અને અન્ય લોકોને તમારા માટે અર્થપૂર્ણ ભાષણો તૈયાર કરવામાં મદદ કરે છે. આગામી કોન્ફરન્સ પ્રોગ્રામની સંપૂર્ણતા અને ઉપયોગિતાનું મૂલ્યાંકન વિષયો દ્વારા કરી શકાય છે અનુસૂચિ. અને વિગતો માટે, 22-23 એપ્રિલના રોજ ઇન્ફોસ્પેસ પર આવો.

સોર્સ: www.habr.com