Лог жүргізу мен тестілеудің маңыздылығы туралы
Қолданбаның толық жұмыс циклін тексерудің маңыздылығы туралы ескертпе, тек өзің жұмыс істеген бөлігін ғана емес.
«Етікші етіксіз» деген сөз бар. Бұл бүгінгі күні мен туралы айтылғандай. Мен вебхуктарды жеткізу, тексеру және аудит қызметін әзірлейтінімді ескерсек, жағдай екі есе күлкілі көрінеді. Бірақ алдымен тарихы.
Бүгін Adal CLI v0.1.2 жаңа нұсқасы шықты, сонымен қатар сервер жағында кейбір жаңартулар болды.
Бұл өзгерістердің бірі вебхуктарды Adal ішінде сақтау әдісін өзгерту болды. Соңғы пайдаланушы үшін бұл көшу байқалмады, бірақ Adal инфрақұрылымы үшін бұл тұрақтылық пен жұмыс сапасын айтарлықтай арттыру болды.
Алдағы жақсартулардың бірі сұрау body сақтау шектеуі болады. Бұл вебхуктар арқылы құпия деректерді жіберетін кейбір пайдаланушылар санаты үшін маңызды болуы мүмкін, олардың мазмұнын үшінші тарап сақтауға тыйым салынған.
Кодқа тиісті өзгерістер енгізгеннен кейін, оның жұмысын сынап көрдім. Вебхуктар қабылданады, өңделеді, сақтау жалаушалары орнатылады, бәрі CLI-ге жетеді және соңғы destination-ға жіберіледі.
Соңғы destinations ретінде менде екі мекенжай орнатылған: біреуі нақты жұмыс істейтін хостқа сілтейді, ал екіншісі нақты жұмыс істемейтін хостқа сілтейді. Бұл вебхуктарды жеткізудің әртүрлі сценарийлерін қалай өңделетінін көру үшін түсінікті.
Бірақ мен бір нәрсені ескермедім: соңғы хост нақты не алады? Ол бастапқы body мен тақырыптарсыз сұрау алды. Күтілетін payload орнына оған тек соңғы алушыға арналмаған ішкі қызметтік деректер жетті.
Жағдай жағымсыз, бірақ сындарлы емес. Бақытымызға орай, қате вебхуктарды қабылдау мен сақтауға әсер етпеді. Сұраулар дұрыс қабылданып, сақталып, өңдеу конвейерінен өтті. Мәселе тек жеткізу үшін payload қалыптастыру кезеңінде пайда болды.
Қате сұрауды сақтау кезінде сақтау түрінің жалаушасы орнатылғанымен, оны пайдаланушыға жеткізу қызметі тексермегенінде болды. Пайдаланушыға жеткізу үшін payload қалыптастыратын қызмет белгісіз сақтау түрін алды және бұл жағдайда бос нәтиже қайтарды.
Әрине, қате жағымсыз болды. Бірақ маған жүйенің бұл жағдайдағы әрекеті ұнады. Жүйе әдепкі мәндерді қоймауды және «не айтылғанын» болжауға тырыспауды жөн көрді.
«Егер түрін білмесек, оны әдепкі түр деп санаймыз» деген шарт жасауға болар еді, бірақ мен «бұл не екенін білмесек, оны өңдемейміз» деп санаған дұрыс деп ойладым. Өйткені «әдепкі деп санау» — бұл blackbox-тан бір нәрсе, кейін «неге бұл сұрауға осындай жауап алдық» деп болжауға тура келеді.
Бұл жағдай маған тағы бір қарапайым нәрсені еске салды: жеке қызметті немесе жеке функцияны емес, бүкіл пайдаланушы сценарийін толықтай тестілеу қажет. Вебхук қабылданғанына көз жеткізуге болады. Оның сақталғанына көз жеткізуге болады. Оның кезекке қойылып, жеткізілгеніне көз жеткізуге болады. Бірақ соңғы endpoint нақты не алғанын көрмейінше, тексеру аяқталмайды. Сондықтан жақсы логтар мен бақылау бизнес логикасы сияқты маңызды.
Сондықтан мен бақылау үшін тағы бір endpoint жасадым және нақты жұмыс істейтін хосттың мекенжайын жаңа endpoint мекенжайына өзгерттім. Енді сұрауда нақты не келетінін нақты көретін боламын. Және тағы бір рет көз жеткіздім: өз өніміңді күн сайын қолданудан артық багтарды ештеңе таппайды. Әсіресе бұл өнім өзіңнің жеке мәселелеріңді шешуге арналған болса.