તાજેતરના એક ડિપ્લોયમેન્ટને કારણે ત્રણ માઇક્રોસર્વિસ બગડી ગઈ, તેમ છતાં દરેક યુનિટ ટેસ્ટ, ઇન્ટિગ્રેશન ટેસ્ટ અને મોક-સર્વર ચેક સફળ રહ્યા હતા. ટીમે તેમના API મોક્સને બદલે કોન્ટ્રાક્ટ ટેસ્ટિંગનો ઉપયોગ કર્યો. છ મહિનામાં કોન્ટ્રાક્ટની સંખ્યા ત્રણથી વધીને 47 થઈ ગઈ અને માસિક ઇન્ટિગ્રેશન-નિષ્ફળતાનો દર બે ઘટનાઓથી ઘટીને શૂન્ય થઈ ગયો.
મોક્સ (mocks) તમને કેમ સુરક્ષિત કરી શકતા નથી
મોક સર્વર ફક્ત કન્ઝ્યુમર (consumer) જે આકારની અપેક્ષા રાખે છે તેનું જ અનુકરણ કરે છે; તે ક્યારેય એ તપાસતું નથી કે પ્રોવાઈડર (provider) ખરેખર તે જ આકાર આપે છે કે નહીં. જો પ્રોવાઈડર કોઈ ફિલ્ડનું નામ બદલે—ધારો કે name થી display_name માં—તો મોક હજુ પણ જૂનો પેલોડ (payload) જ રિટર્ન કરશે, કન્ઝ્યુમરના ટેસ્ટ હજુ પણ ગ્રીન (સફળ) રહેશે, અને લાઈવ સિસ્ટમ ક્રેશ થઈ જશે. મંગળવારે બપોરે 2 વાગ્યે જે પ્રોડક્શન ફેલ્યોર થયું તે બરાબર આવું જ હતું: મોકે વાસ્તવિક કોન્ટ્રાક્ટ વિશે "ખોટું" કહ્યું હતું.
કોન્ટ્રાક્ટ ટેસ્ટિંગ અંતરને પૂરું કરે છે
કોન્ટ્રાક્ટ ટેસ્ટિંગ કોઈપણ કોડ પ્રોડક્શનમાં જાય તે પહેલાં API ના બંને પક્ષોને વહેંચાયેલ વ્યાખ્યા (shared definition) પર સહમત થવા માટે મજબૂર કરે છે. અહીં બે સામાન્ય અભિગમો છે:
- Consumer-driven contracts – કન્ઝ્યુમિંગ સર્વિસ અપેક્ષાઓ લખે છે; પ્રોવાઈડિંગ સર્વિસ તેને વેલિડેટ કરે છે. આ અભિગમ સાથે મળીને વિકસતા આંતરિક માઇક્રોસર્વિસ માટે સારી રીતે કામ કરે છે.
- Provider-driven contracts – પ્રોવાઈડર એક સ્પષ્ટીકરણ (specification) પ્રકાશિત કરે છે; કન્ઝ્યુમર્સ તેમના કોડને તેની સામે તપાસે છે. પબ્લિક API માટે આ સામાન્ય પેટર્ન છે.
પ્રથમ અભિગમ સામાન્ય રીતે માઇક્રોસર્વિસ આર્કિટેક્ચરની અંદર બગડેલા ઇન્ટિગ્રેશનને અટકાવે છે.
કન્ઝ્યુમર-ડ્રિવન કોન્ટ્રાક્ટ કેવી રીતે કામ કરે છે
- કન્ઝ્યુમર એક ટેસ્ટ લખે છે જે પ્રોવાઈડર પાસેથી તેને ચોક્કસપણે શું જોઈએ છે તેનું વર્ણન કરે છે.
- ટેસ્ટ ચલાવવાથી એક pact file જનરેટ થાય છે – જે એક JSON ડોક્યુમેન્ટ છે જે તે અપેક્ષાઓને રેકોર્ડ કરે છે.
- પ્રોવાઈડર તેના CI પાઇપલાઇનમાં pact file સામે તેની વાસ્તવિક સર્વિસ ચલાવે છે.
- જો પ્રોવાઈડર કોઈ ફિલ્ડ બદલે છે, તો વેરિફિકેશન નિષ્ફળ જાય છે અને બિલ્ડ બ્લોક થઈ જાય છે.
કારણ કે વેરિફિકેશન વાસ્તવિક પ્રોવાઈડર કોડ પર ચાલતું હોવાથી, કોઈપણ બ્રેકિંગ ચેન્જ (breaking change) ડિપ્લોયમેન્ટ પછી નહીં, પણ વહેલી તકે પકડાઈ જાય છે.
તમારા ટેસ્ટ પિરામિડમાં કોન્ટ્રાક્ટ ટેસ્ટ ક્યાં હોવા જોઈએ
- Unit tests – ઝડપી, અલગ કરેલા લોજિકનું પરીક્ષણ કરે છે.
- Contract tests – મધ્યમ ગતિ, API કરારો જળવાય છે તેની ખાતરી કરે છે.
- End-to-end tests – ધીમા, સંપૂર્ણ બિઝનેસ ફ્લોનું પરીક્ષણ કરે છે.
કોન્ટ્રાક્ટ ટેસ્ટને યુનિટ ટેસ્ટના ઝડપી ફીડબેક અને એન્ડ-ટુ-એન્ડ સૂટ્સના વ્યાપક કવરેજ વચ્ચેના સેતુ (bridge) તરીકે ગણો. જે ઇન્ટિગ્રેશન પોઈન્ટ્સ વારંવાર બગડે છે તેને લક્ષ્ય બનાવો અને બે અથવા ત્રણ મહત્વપૂર્ણ એન્ડપોઈન્ટ્સથી શરૂઆત કરો.
વાસ્તવિક દુનિયાની અપનાવવાની વાર્તા
આ લેખને પ્રેરણા આપનાર ટીમે તેમની સૌથી નાજુક કોલ્સને આવરી લેતા ત્રણ કોન્ટ્રાક્ટથી શરૂઆત કરી હતી. છ મહિના પછી તેમની પાસે ઇન્ટર-સર્વિસ ટ્રાફિકના મોટાભાગના ભાગને આવરી લેતા 47 કોન્ટ્રાક્ટ હતા. તે સમયગાળા દરમિયાન API બ્રેકેજની ઘટનાઓ દર મહિને બેથી ઘટીને શૂન્ય થઈ ગઈ.
ક્યારે કોન્ટ્રાક્ટ ટેસ્ટિંગ કરવા જેવું નથી
- તમે સોલો ડેવલપર છો જે બધી સર્વિસને સિંગલ રિપોઝિટરીમાં રાખે છે.
- API અસાધારણ રીતે સ્થિર છે અને વર્ષોથી બદલાયું નથી.
- તમે એવો પ્રોટોટાઇપ બનાવી રહ્યા છો જે ટૂંક સમયમાં ફેંકી દેવામાં આવશે.
આવા કિસ્સાઓમાં, કોન્ટ્રાક્ટ જાળવવાનો ઓવરહેડ તેના ફાયદા કરતા વધી શકે છે.
સંભવિત ગેરફાયદા અને તેને કેવી રીતે ઘટાડવા
- કોન્ટ્રાક્ટને તેઓ જે કોડનું વર્ણન કરે છે તેની સાથે વર્ઝન કરેલા રાખો.
- જૂના (stale) કોન્ટ્રાક્ટથી બચવા માટે દરેક CI રન માં વેરિફિકેશન ઓટોમેટ કરો.
- અકસ્માતે થતા બ્રેકેજને પકડવા માટે પુલ રિક્વેસ્ટ્સ (pull requests) માં કોન્ટ્રાક્ટ ફેરફારોની સમીક્ષા કરો.
મુખ્ય વાત (Takeaway)
જો તમે હજુ પણ તમારી સર્વિસ એકબીજા સાથે વાત કરી શકે છે તેવું પોતાને ખાતરી આપવા માટે હાથે બનાવેલા મોક્સ (hand-crafted mocks) પર નિર્ભર છો, તો તમે ખોટા વચન પર દાવ લગાવી રહ્યા છો. કોન્ટ્રાક્ટ ટેસ્ટિંગ તે દાવને એક વેરિફાઈ કરી શકાય તેવા કરારમાં ફેરવે છે, જે પ્રોડક્શનમાં પહોંચતા પહેલા જ બ્રેકિંગ ચેન્જને પકડી લે છે અને, જેમ કે ટીમ દ્વારા દર્શાવવામાં આવેલા આંકડાઓ બતાવે છે, તે ઇન્ટિગ્રેશન નિષ્ફળતાઓને સંપૂર્ણપણે દૂર કરી શકે છે.