Көп продуктылуу программалык камсыздоону сатуучулар көп кездешкен көйгөйлөрдүн бири - дээрлик ар бир командада инженерлердин - иштеп чыгуучулардын, тестирлөөчүлөрдүн жана инфраструктуралык администраторлордун компетенцияларынын кайталанышы. Бул ошондой эле кымбат инженерлерге - жүктөрдү сыноо тармагындагы адистерге тиешелүү.
Түз милдеттерин аткаруунун жана жүктөмдү тестирлөө процессин куруу, методологияны, оптималдуу метриканы тандоо жана жүк профилдерине ылайык автотесттерди жазуу үчүн уникалдуу тажрыйбасын колдонуунун ордуна, инженерлер көбүнчө тесттик инфраструктураны нөлдөн баштап орнотуп, жүктөө куралдарын конфигурациялап, аларды киргизүүгө туура келет. өздөрүн CI системаларында, мониторинг жана отчетторду жарыялоону орнотуу.
Сиз Positive Technologies компаниясында колдонгон тестирлөөдөн кээ бир уюштуруу көйгөйлөрүнүн чечимдерин таба аласыз . Бул жерде мен "кызмат катары жүктөөнү тестирлөө" (кызмат катары жүктөө тести) түшүнүгүн колдонуу менен жүк сыноолорун жалпы CI түтүкчөсүнө интеграциялоо мүмкүнчүлүгү жөнүндө сүйлөшөм. Сиз жүктөө булактарынын кандай жана кайсы докер сүрөттөрүн CI түтүкчөсүндө колдонсо болорун билесиз; куруу үлгүсүн колдонуу менен жүктөө булактарын CI долбооруна кантип туташтыруу керек; жүк сыноолорду жүргүзүү жана натыйжаларды жарыялоо үчүн демо түтүк кандай көрүнөт. Макала жүктөө тутумунун архитектурасы жөнүндө ойлонуп жаткан CIдеги программалык камсыздоону сыноо инженерлери жана автоматташтыруу инженерлери үчүн пайдалуу болушу мүмкүн.
Концепциянын маңызы
Кызмат катары жүктөмдү тестирлөө концепциясы жүктөө куралдарын Apache JMeter, Yandex.Tank жана өзүңүздүн алкактарыңызды ыктыярдуу үзгүлтүксүз интеграциялоо тутумуна интеграциялоо мүмкүнчүлүгүн билдирет. Демо GitLab CI үчүн болот, бирок принциптер бардык CI системалары үчүн жалпы.
Кызмат катары жүктөөнү тестирлөө - жүктөмдү текшерүү үчүн борборлоштурулган кызмат. Жүктөлгөн тесттер атайын агент бассейндеринде аткарылат, натыйжалар GitLab Pages, Influx DB жана Grafana же тесттик отчеттуулук системаларында (TestRail, ReportPortal ж.б.) автоматтык түрдө жарыяланат. Автоматташтыруу жана масштабдоо мүмкүн болушунча жөнөкөй - GitLab CI долбооруна кадимки gitlab-ci.yml шаблонун кошуу жана параметрлөө аркылуу ишке ашырылат.
Бул ыкманын артыкчылыгы – бүт CI инфраструктурасы, жүктөө агенттери, жүк булактарынын докер сүрөттөрү, тестирлөө өткөргүчтөрү жана отчеттуулуктун жарыяланышы борборлоштурулган автоматташтыруу бөлүмү (DevOps инженерлери) тарабынан камсыздалат жана жүктөрдү сыноо боюнча инженерлер өз күч-аракетин тестти иштеп чыгууга жана инфраструктура маселелери менен алектенбестен, алардын натыйжаларын талдоо.
Сүрөттөмөнүн жөнөкөйлүгү үчүн биз текшерилип жаткан максаттуу тиркеме же сервер алдын ала жайгаштырылган жана конфигурацияланган деп ойлойбуз (бул үчүн Python, SaltStack, Ansible ж.б. автоматташтырылган скрипттерди колдонсо болот). Андан кийин кызмат катары жүк тестирлөөнүн бүт түшүнүгү үч этапка туура келет: отчетторду даярдоо, сыноо, жарыялоо. Диаграмма боюнча көбүрөөк маалымат (бардык сүрөттөр чыкылдатса болот):
Жүк тестирлөөдөгү негизги түшүнүктөр жана аныктамалар
жүк сыноолорду жүргүзүүдө, биз карманууга аракет кылабыз , тиешелүү терминологияны жана сунушталган көрсөткүчтөрдү колдонуңуз. Мен жүк тестирлөөдө негизги түшүнүктөрдүн жана аныктамалардын кыскача тизмесин берем.
Жүктөө агенти - тиркеме ишке киргизиле турган виртуалдык машина - жүктөө булагы (Apache JMeter, Yandex.Tank же өз алдынча жазылган жүктөө модулу).
Сыноо максаты (максат) - жүктөөгө дуушар боло турган сервер же серверде орнотулган тиркеме.
Сыноо сценарийи (сыноо иши) - параметрлештирилген кадамдардын жыйындысы: колдонуучунун аракеттери жана бул аракеттерге күтүлгөн реакциялар, белгиленген параметрлерге жараша белгиленген тармактык суроо-талаптар жана жооптор.
Профиль же жүктөө планы (профиль) - in (4.2.4-бөлүм, 43-б.) жүк профилдери белгилүү бир сыноо үчүн маанилүү болгон көрсөткүчтөрдү жана сыноо учурунда жүктүн параметрлерин өзгөртүү варианттарын аныктайт. Сиз сүрөттө профилдердин мисалдарын көрө аласыз.
Сыноо — алдын ала белгиленген параметрлер топтому бар скрипт.
Сыноо планы (тест планы) - тесттердин комплекси жана жүк профили.
Testran (testrun) - толук аткарылган жүктөө сценарийи жана алынган отчет менен бир сыноону жүргүзүүнүн бир итерациясы.
Тармак сурамы (суроо) — Агенттен максатка жөнөтүлгөн HTTP сурамы.
Тармак жообу (жооп) — Максаттан агентке жөнөтүлгөн HTTP жообу.
HTTP жооп коду (HTTP жоопторунун абалы) - колдонмо серверинен стандарттык жооп коду.
Транзакция – бул суроо-жооптун толук цикли. Бүтүм суроо-талапты (суроо-талапты) жөнөтүүнүн башталышынан жоопту (жоопту) алуу аяктаганга чейин эсептелет.
Транзакциянын абалы - суроо-жооп циклин ийгиликтүү аяктоо мүмкүн болгонбу. Бул циклде кандайдыр бир ката бар болсо, анда бүт транзакция ийгиликсиз деп эсептелет.
Жооп убактысы (кечигитүү) - суроо-талапты (суроо-талапты) жөнөтүү аяктагандан жоопту (жоопту) алуу башталганга чейинки убакыт.
Өлчөмдөрдү жүктөө — жүктөөчү кызматтын жана жүктөөнү сыноо процессинде аныкталган жүктөө агентинин мүнөздөмөлөрү.
Жүктөө параметрлерин өлчөө үчүн негизги көрсөткүчтөр
Методологияда эң көп колдонулган жана сунушталгандардын айрымдары (36, 52-б.) көрсөткүчтөр төмөнкү таблицада көрсөтүлгөн. Агент жана максат үчүн окшош көрсөткүчтөр бир сапта келтирилген.
Жүктөө агенти үчүн көрсөткүчтөр
Максаттуу тутумдун же колдонмонун көрсөткүчтөрү жүктөм астында текшерилип жатат
сан vCPU жана эс RAM,
диск - жүктөөчү агенттин "темир" мүнөздөмөлөрү
CPU, Эстутум, дискти колдонуу - CPU, эстутум жана диск жүктөө динамикасы
сыноо процессинде. Адатта пайыз менен ченелет
максималдуу жеткиликтүү маанилер
тармак өткөрүү жөндөмдүүлүгү (жүк агенти боюнча) - өткөрүү жөндөмдүүлүгү
сервердеги тармак интерфейси,
жүк агенти орнотулган жерде.
Адатта секундасына байт менен ченелет (бит/с)
тармак өткөрүү жөндөмдүүлүгү(максат боюнча) - тармак интерфейсинин өткөрүү жөндөмдүүлүгү
максаттуу серверде. Адатта секундасына байт менен ченелет (бит/сек)
Виртуалдык колдонуучулар- виртуалдык колдонуучулардын саны,
жүктөө сценарийлерин ишке ашыруу жана
чыныгы колдонуучунун аракеттерин туурап
Виртуалдык колдонуучулардын абалы, Өттү/Өткөн жок/Бардыгы — ийгиликтүү жана саны
виртуалдык колдонуучулардын ийгиликсиз статустары
жүктөө сценарийлери үчүн, ошондой эле алардын жалпы саны.
Бул жалпысынан бардык колдонуучулар бүтүрө алган деп күтүлүүдө
жүктөө профилинде көрсөтүлгөн бардык тапшырмаларыңыз.
Ар кандай ката чыныгы колдонуучу кыла албайт дегенди билдирет
система менен иштөөдө көйгөйүңүздү чечиңиз
секундасына суроо-талаптар (мүнөт)- секундасына (же мүнөтүнө) тармактык суроо-талаптардын саны.
Жүктөө агентинин маанилүү өзгөчөлүгү - бул канча суроо-талаптарды жаратышы.
Чынында, бул виртуалдык колдонуучулардын тиркемеге кирүү мүмкүнчүлүгүн имитациялоо
Секундадагы жооптор (мүнөт)
- секундасына (же мүнөтүнө) тармактык жооптордун саны.
Максаттуу кызматтын маанилүү мүнөздөмөсү: канча
менен суроолорго жоопторду түзүү жана жөнөтүү
жүктөө агенти
HTTP жооп абалы— ар кандай жооп коддорунун саны
жүктөө агенти тарабынан алынган колдонмо серверинен.
Мисалы, 200 OK ийгиликтүү чалууну билдирет,
жана 404 - бул ресурс табылган жок
кечигүү (жооп убактысы) - аягына чейинки убакыт
жооп (жооп) ала баштаганга чейин суроо-талап (суроо) жөнөтүү.
Адатта миллисекунд менен ченелет (мс)
Транзакцияга жооп берүү убактысы- бир бүтүмдүн убактысы,
суроо-жооп циклинин аякташы.
Бул суроо-талап (суроо) жөнөтүлгөндөн берки убакыт
жооп (жооп) алуу аяктаганга чейин.
Транзакция убактысы секундалар (же мүнөттөр) менен өлчөнө алат
бир нече жолдор менен: минималдуу карап,
максималдуу, орточо жана, мисалы, 90-проценттиль.
Минималдуу жана максималдуу көрсөткүчтөр экстремалдуу
системанын аткаруу абалы.
Токсонунчу пайыздык эң көп колдонулган,
колдонуучулардын көбү көрсөткөндөй,
системанын иштешинин босогосунда ыңгайлуу иштөө
секундасына транзакциялар (мүнөт) - толук саны
секундасына транзакциялар (мүнөт),
башкача айтканда, арыз канча кабыл алган жана
суроо-талаптарды иштеп чыгуу жана жоопторду берүү.
Чынында, бул системанын өткөрүү жөндөмдүүлүгү
Транзакциянын абалы , Өттү / Болбой калды / Бардыгы - саны
ийгиликтүү, ийгиликсиз жана бүтүмдөрдүн жалпы саны.
чыныгы колдонуучулар үчүн ийгиликсиз
бүтүм иш жүзүндө билдирет
жүк астында система менен иштөө мүмкүн эместиги
Жүктөлгөн тестирлөө схемасы
Жүктөлгөн тестирлөө түшүнүгү абдан жөнөкөй жана мен айтып өткөн үч негизги этаптан турат: Даярдоо-сыноо-отчет, башкача айтканда, сыноо максаттарын даярдоо жана жүк булактары үчүн параметрлерди коюу, андан кийин жүктөө сыноолорун жүргүзүү жана аягында сыноо отчетун түзүү жана жарыялоо.
Схематикалык эскертүүлөр:
- QA.Tester жүк тестирлөө боюнча эксперт болуп саналат,
- Максат - бул жүктөө астында анын жүрүм-турумун билгиңиз келген максаттуу колдонмо.
Диаграммадагы объекттердин классификатору, этаптары жана кадамдары
Этаптар жана кадамдар
Эмне болуп жатат
Кире бериште эмне бар
чыгаруу кандай
Даярдоо: тестирлөөгө даярдоо этабы
LoadParameters
Орнотуу жана инициализация
колдонуучу
жүктөө параметрлери,
көрсөткүчтөрдү тандоо жана
сыноо планын даярдоо
(профиль жүктөө)
үчүн ыңгайлаштырылган параметрлер
жүктөө агентин инициализациялоо
Сыноо планы
Тесттин максаты
VM
Булутту жайылтуу
менен виртуалдык машина
талап кылынган мүнөздөмөлөр
Жүктөө агенти үчүн VM жөндөөлөрү
үчүн автоматташтыруу скрипттери
VM түзүү
VM конфигурацияланган
булут
Энв
OS орнотуу жана даярдоо
үчүн чөйрө
жүк агентинин иши
үчүн айлана-чөйрөнүн жөндөөлөрү
жүктөө агенти
үчүн автоматташтыруу скрипттери
чөйрө жөндөөлөрү
Даярдалган чөйрө:
OS, кызматтар жана тиркемелер,
иш үчүн зарыл
жүктөө агенти
LoadAgents
Орнотуу, конфигурациялоо жана параметрлөө
жүктөө агенти.
Же докер сүрөтүн жүктөп алуу
алдын ала конфигурацияланган жүк булагы
Булак докер сүрөтүн жүктөө
(YAT, JM же өз алдынча жазылган алкак)
Орнотуулар
жүктөө агенти
Орнотуу жана даяр
жумуш жүктөө агентине
Сыноо: жүк сыноолорду аткаруу баскычы. Булактар GitLab CI үчүн атайын агент бассейндеринде жайгаштырылган жүктөө агенттери
жүк
Жүктөө агентин баштоо
тандалган тест планы менен
жана жүктөө параметрлери
Колдонуучу параметрлери
баштоо үчүн
жүктөө агенти
Сыноо планы
Тесттин максаты
Аткаруу журналдары
жүк тесттер
Системалык журналдар
Максаттын көрсөткүчтөрүндөгү өзгөрүүлөрдүн динамикасы жана жүктөө агенти
Run Agents
Агенттин аткарылышы
көптөгөн сыноо скрипттери
ылайык
жүктөө профили
Агенттин өз ара аракеттенүүсүн жүктөө
сыноо максатында
Сыноо планы
Тесттин максаты
журналдар
"Чийки" журналдарды чогултуу
жүк сыноо учурунда:
жүктөө агентинин иш жазуулары,
сыноо максатынын абалы
жана агентти башкарган VM
Аткаруу журналдары
жүк тесттер
Системалык журналдар
ченемдер
Сыноо учурунда "чийки" көрсөткүчтөрдү чогултуу
Максаттын көрсөткүчтөрүндөгү өзгөрүүлөрдүн динамикасы
жана жүктөө агенти
Отчет: сыноо отчетун даярдоо этабы
генератор
Кайра иштетүү чогултулду
жүктөө системасы жана
мониторинг системасы "чийки"
көрсөткүчтөр жана журналдар
Отчетту түзүү
адам окуй турган форма
элементтер менен мүмкүн
талдоочулар
Аткаруу журналдары
жүк тесттер
Системалык журналдар
Метрикадагы өзгөрүүлөрдүн динамикасы
максаттуу жана жүктөө агенти
Иштелген "чийки" журналдар
ылайыктуу форматта
тышкы сактагычка жүктөөлөр
Статикалык жүктөө отчету,
адам окуй алат
чыгаруу
Докладды жарыялоо
жүк жөнүндө
тышкы сыноо
кызмат
"Чийки" иштетилген
ылайыктуу форматта журналдар
сыртка түшүрүү үчүн
репозиторийлер
Сырттан сакталган
сактоо боюнча отчеттор
жүк, ылайыктуу
адам анализи үчүн
CI шаблонунда жүктөө булактарын туташтыруу
Келгиле, практикалык бөлүгүнө өтөбүз. Мен компаниянын кээ бир долбоорлорунда кантип көрсөткүм келет биз кызмат катары жүк тестирлөө концепциясын ишке ашырдык.
Биринчиден, DevOps инженерлерибиздин жардамы менен биз GitLab CIде жүк сыноолорун жүргүзүү үчүн атайын агенттер пулун түздүк. Аларды шаблондордо башкалары менен чаташтырбоо үчүн, мисалы, монтаждык бассейндер, биз бул агенттерге тегдерди коштук, : жүктөө. Сиз башка түшүнүктүү тегдерди колдоно аласыз. Алар сурайт GitLab CI Rnners.
Аппараттык камсыздоо боюнча керектүү кубаттуулукту кантип билсе болот? Жүктөө агенттеринин мүнөздөмөлөрү - жетиштүү сандагы vCPU, RAM жана Диск - агентте Docker, Python (Yandex.Tank үчүн), GitLab CI агенти, Java (Apache JMeter үчүн) иштеши керек экендигинин негизинде эсептелсе болот. . JMeter астындагы Java үчүн, ошондой эле эң аз 512 МБ оперативдүү эстутумду колдонуу сунушталат жана жогорку чек катары, .
Ошентип, тажрыйбабыздын негизинде биз жүктөө агенттери үчүн жок дегенде 4 vCPU, 4 ГБ оперативдүү эс, 60 ГБ SSD колдонууну сунуштайбыз. Тармактык картанын өткөрүү жөндөмдүүлүгү жүк профилинин талаптарынын негизинде аныкталат.
Биз негизинен эки жүктөө булагын колдонобуз - Apache JMeter жана Yandex.Tank докер сүрөттөрү.
жүк тестирлөө үчүн Yandex ачык булагы болуп саналат. Анын модулдук архитектурасы Phantom'тун жогорку натыйжалуу асинхрондук хитке негизделген HTTP сурам генераторуна негизделген. Танкта SSH протоколу аркылуу текшерилип жаткан сервердин ресурстарына орнотулган мониторинг бар, белгиленген шарттарда тестти автоматтык түрдө токтото алат, натыйжаларды консолдо да, графиктер түрүндө да көрсөтө алат, модулдарыңызды туташтыра аласыз. ага функцияларды кеңейтүү үчүн. Баса, биз Танкты али негизги агым боло элек кезде колдондук. макаласында"» сиз 2013-жылы аны менен жүктөмдү тестирлөөдөн өткөнүбүз тууралуу баянды окуй аласыз биздин компаниянын продукцияларынын бири болуп саналат.
Apacheден ачык булак жүктөмүн текшерүү куралы. Бул статикалык жана динамикалык желе колдонмолорун сыноо үчүн бирдей жакшы колдонсо болот. JMeter көптөгөн протоколдорду жана тиркемелер менен иштешүүнүн жолдорун колдойт: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, ж.б.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) жана IMAP(S), JDBC аркылуу берилиштер базалары кабык буйруктарын аткарып, Java объектилери менен иштей алат. JMeterде тест пландарын түзүү, мүчүлүштүктөрдү оңдоо жана аткаруу үчүн IDE бар. Ошондой эле ар кандай Java шайкеш операциялык тутумунда (Linux, Windows, Mac OS X) буйрук сабын иштетүү үчүн CLI бар. Бул курал динамикалык түрдө HTML тест отчетун түзө алат.
Биздин компаниянын ичинде колдонууга ыңгайлуу болушу үчүн, тестирлөөчүлөрдүн өздөрү чөйрөнү өзгөртүү жана кошуу мүмкүнчүлүгү үчүн, биз GitLab CIде жүктөө булактарынын докер сүрөттөрүн түздүк. . Бул жүктү сыноо үчүн аларды түтүктөргө туташтырууну тезирээк жана оңой кылат. GitLab CI аркылуу реестрге докер push кантип жасоо керек - караңыз .
Биз Yandex.Tank үчүн бул негизги докер файлын алдык:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Жана Apache JMeter үчүн бул:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Биздин үзгүлтүксүз интеграция системабыз кандай иштээрин макаладан окуй аласыз "«.
Шаблон жана түтүк
Долбоордо жүк сыноолорду жүргүзүү үчүн үлгү үлгүсү бар . The Сиз шаблонду колдонуу боюнча нускамаларды окуй аласыз. Шаблондун өзүндө (файл ) ар бир кадам эмне үчүн жооптуу экендиги жөнүндө жазуулар бар.
Шаблон абдан жөнөкөй жана жогорудагы диаграммада сүрөттөлгөн жүктөмдү текшерүүнүн үч баскычын көрсөтөт: отчетторду даярдоо, сыноо жана жарыялоо. Бул үчүн жооптуу : Даярдоо, сыноо жана отчет.
- Этап сыноо максаттарын алдын ала конфигурациялоо же алардын жеткиликтүүлүгүн текшерүү үчүн колдонулушу керек. Жүктөө булактары үчүн чөйрөнү конфигурациялоонун кереги жок, алар докердин сүрөттөрү катары алдын ала курулуп, докер реестрине жайгаштырылат: жөн гана Сыноо стадиясында керектүү версияны көрсөтүңүз. Бирок сиз аларды кайра куруп, өзүңүздүн өзгөртүлгөн сүрөттөрүңүздү жасай аласыз.
- Этап жүктөө булагын көрсөтүү, сыноолорду жүргүзүү жана сыноо артефакттарын сактоо үчүн колдонулат. Сиз каалаган жүктөө булагын тандай аласыз: Yandex.Tank, Apache JMeter, өзүңүздүн же бардыгы чогуу. Керексиз булактарды өчүрүү үчүн жөн гана комментарий калтырыңыз же жумушту өчүрүңүз. Жүктөө булактары үчүн кирүү пункттары:
- Yandex.Tank үчүн ишке киргизүү параметрлери көрсөтүлгөн.,
- Apache JMeter баштоо параметрлери файлда көрсөтүлгөн .
Эскертүү: Монтаж конфигурациясынын шаблону CI системасы менен өз ара аракеттенүүнү орнотуу үчүн колдонулат жана андагы тест логикасын жайгаштырууну билдирбейт. Тесттер үчүн башкаруучу баш сценарийи жайгашкан кирүү чекити көрсөтүлөт. Сыноолорду жүргүзүү, отчетторду түзүү жана сыноо скрипттеринин өзү QA инженерлери тарабынан ишке ашырылышы керек. Демонстрацияда эки жүктөө булагы үчүн эң жөнөкөй тест катары Яндекс башкы бетинин суроосу колдонулат. Скрипттер жана сыноо параметрлери каталогдо .
- Сахнада Сыноо стадиясында алынган тесттин натыйжаларын тышкы сактагычтарга, мисалы, GitLab Pages же атайын отчеттуулук системаларына кантип жарыялоону сүрөттөшүңүз керек. GitLab Pages ./public каталогу бош болбошун жана тесттер аяктагандан кийин жок дегенде index.html файлын камтышы керек. GitLab Pages сервисинин нюанстары жөнүндө окуй аласыз. .
Маалыматтарды кантип экспорттоого мисалдар:
- JMeter чейин ,
- Яндекс.Танктан .
Орнотуу нускамаларын жарыялоо:
- HTML статикасы ,
- InfluxDB жана андан кийин .
Демо мисалында, жүк сыноолору жана эки жүк булагы бар түтүк (керексизди өчүрө аласыз) мындай көрүнөт:
Apache JMeter HTML отчетун өзү түзө алат, андыктан стандарттык куралдарды колдонуу менен аны GitLab баракчаларында сактоо пайдалуураак. Apache JMeter отчету ушундай көрүнөт:
Yandex.Tank үчүн демо мисалында, сиз гана көрө аласыз GitLab баракчалары үчүн бөлүмдө. Сыноо учурунда Танк натыйжаларды InfluxDB маалымат базасына сактай алат жана ал жерден алар, мисалы, Графанада көрсөтүлүшү мүмкүн (конфигурация файлда жасалат) ). Танктын отчету Графанада мындайча көрүнөт:
на
Макалада мен "жүк тестирлөө кызматы катары" (load testing as a service) түшүнүгү жөнүндө айттым. Негизги идея - жүктөө агенттеринин алдын ала конфигурацияланган бассейндеринин инфраструктурасын, жүк булактарынын докер сүрөттөрүн, отчеттук системаларды жана жөнөкөй .gitlab-ci.yml шаблонунун негизинде аларды GitLab CIде бириктирген түтүктү колдонуу (мисалы ). Мунун бардыгын автоматташтыруу боюнча инженерлердин чакан тобу колдойт жана продуктылардын топторунун талабы боюнча кайталанат. Бул сиздин компанияңызда ушундай схеманы даярдоого жана ишке ашырууга жардам берет деп ишенем. Көңүл бурганыңыздарга рахмат!
PS Мен кесиптештерим Сергей Курбанов менен Николай Юсевге биздин компанияда кызмат катары жүктөмдү тестирлөө концепциясын ишке ашырууда техникалык жардам көрсөткөндүгү үчүн чоң рахмат айткым келет.
жазуучу: - орун басары Positive Technologies компаниясынын технология жана өнүгүү процесстеринин (DevOps) башчысы
Source: www.habr.com