Yek ji wan pirsgirêkên ku firoşkarên nermalava pir-hilberî bi gelemperî bi wan re rû bi rû dimînin duberkirina jêhatîbûna endezyaran - pêşdebiran, ceribandin û rêvebirên binesaziyê - hema hema li ser her tîmê ye. Ev ji bo endezyarên biha jî derbas dibe - pisporên di warê ceribandina barkirinê de.
Li şûna ku peywirên xwe yên rasterast bikin û ezmûna xwe ya yekta bikar bînin da ku pêvajoyek ceribandina barkirinê ava bikin, rêbazek, metrîkên çêtirîn hilbijêrin û li gorî profîlên barkirinê testên xweser binivîsin, endezyar bi gelemperî neçar in ku binesaziya ceribandinê ji sifrê vebikin, amûrên barkirinê mîheng bikin, û wan bi cih bikin. xwe di pergalên CI de, çavdêrîkirin û weşandina raporan saz kirin.
Hûn dikarin di ceribandina ku em li Teknolojiyên Positive de bikar tînin de çareseriyên hin pirsgirêkên rêxistinî bibînin . Û di vê yekê de, ez ê li ser îhtîmala yekkirina ceribandinên barkirinê di boriyek CI ya hevpar de bi karanîna têgeha "ceribandina barkirinê wekî karûbar" (ceribandina barkirinê wekî karûbar) biaxivim. Hûn ê fêr bibin ka çawa û kîjan wêneyên docker ên çavkaniyên barkirinê dikarin di lûleya CI de werin bikar anîn; meriv çawa bi karanîna şablonek çêkirinê çavkaniyên barkirinê bi projeya CI-ya xwe ve girêdide; ji bo ceribandinên barkirinê û weşandina encaman xeta demo çawa xuya dike. Dibe ku gotar ji bo endezyarên ceribandina nermalavê û endezyarên otomasyonê yên li CI-yê ku li ser mîmariya pergala barkirina xwe difikirin kêrhatî be.
Esasê têgînê
Têgeha ceribandina barkirinê wekî karûbar tê wateya ku hûn amûrên barkirinê Apache JMeter, Yandex.Tank û çarçoveyên xwe di nav pergalek entegrasyona domdar a keyfî de yek bikin. Demo dê ji bo GitLab CI be, lê prensîb ji hemî pergalên CI re hevpar in.
Testkirina barkirinê wekî karûbar karûbarek navendîkirî ye ji bo ceribandina barkirinê. Testên barkirinê di hewzên ajansê yên diyarkirî de têne meşandin, encam bixweber di GitLab Rûpelên, Influx DB û Grafana an di pergalên raporkirina testê de têne weşandin (TestRail, ReportPortal, hwd.). Otomasyon û pîvandin bi qasî ku gengaz dibe têne bicîh kirin - bi lê zêdekirin û parameterîzekirina şablona gitlab-ci.yml ya gelemperî di projeya GitLab CI de.
Feydeya vê nêzîkatiyê ev e ku tevahiya binesaziya CI, ajanên barkirinê, wêneyên docker ên çavkaniyên barkirinê, lûleyên ceribandinê, û raporên weşandinê ji hêla dezgehek otomasyona navendî (endazyarên DevOps) ve têne parastin, dema ku endezyarên ceribandina barkirinê dikarin hewildanên xwe li ser pêşkeftina ceribandinê bikin. û analîzkirina encamên wan, bêyî ku bi pirsgirêkên binesaziyê re mijûl bibin.
Ji bo hêsaniya danasînê, em ê texmîn bikin ku serîlêdana armanc an servera di bin ceribandinê de berê berê hatî bicîh kirin û mîheng kirin (nivîsên otomatîk ên Python, SaltStack, Ansible, hwd. dikarin ji bo vê werin bikar anîn). Dûv re tevahiya têgeha ceribandina barkirinê wekî karûbar di sê qonaxan de cih digire: amadekirin, ceribandin, weşandina raporan. Zêdetir hûrgulî li ser diagramê (hemî wêne têne klîk kirin):
Di ceribandina barkirinê de têgîn û pênaseyên bingehîn
Dema ku ceribandinên barkirinê pêk tînin, em hewl didin ku pêgir bin , termînolojiya guncaw û metrîkên pêşniyarkirî bikar bînin. Ez ê di ceribandina barkirinê de navnîşek kurt a têgîn û pênaseyên sereke bidim.
Agent Load - makîneyek virtual ya ku dê serîlêdan li ser were destpêkirin - çavkaniya barkirinê (Apache JMeter, Yandex.Tank an modulek barkirinê ya bixwe-nivîsandî).
Armanca testê (armanc) - server an serîlêdana ku li ser serverê hatî saz kirin ku dê were barkirin.
Senaryoya testê (doza testê) - komek gavên parameterkirî: kiryarên bikarhêner û reaksiyonên bendewar ên li ser van çalakiyan, bi daxwaz û bersivên torê yên sabît, li gorî pîvanên diyarkirî.
Profîl an plana barkirinê (profîl) - di (Beş 4.2.4, r. 43) profîlên barkirinê metrîkên ku ji bo ceribandinek taybetî krîtîk in û vebijarkên ji bo guhertina parametreyên barkirinê di dema ceribandinê de diyar dikin. Hûn dikarin nimûneyên profîlan di wêneyê de bibînin.
Îmtîhan - skrîptek bi komek parametreyên pêşwextkirî.
Plana testê (test-plan) - komek ceribandin û profîlek barkirinê.
Testran (testun) - Yek dubarekirina ceribandinek bi senaryoyek barkirinê ya bi tevahî hatî darve kirin û rapora wergirtî.
Daxwaza torê (daxwaz) - Daxwazek HTTP ji karmendek ji armancek re hatî şandin.
Bersiva torê (bersiv) - Bersiva HTTP-ê ji armancê ji nûnerê re hatî şandin.
Koda bersiva HTTP (rewşa bersivên HTTP) - koda bersivê ya standard ji servera serîlêdanê.
Danûstandin çerxa daxwaz-bersivê ya bêkêmasî ye. Danûstandinek ji destpêka şandina daxwazek (daxwazek) heya bidawîbûna wergirtina bersivê (bersiv) tê hesibandin.
Rewşa danûstandinê - gelo gengaz bû ku bi serfirazî çerxa daxwaz-bersiv biqede. Ger di vê çerçoveyê de xeletiyek hebe, wê hingê tevahiya danûstendinê neserkeftî tê hesibandin.
Dema bersivê (derengî) - dema ji dawiya şandina daxwazekê (daxwaz) heya destpêka wergirtina bersivekê (bersiv).
Metrîkên barkirinê - taybetmendiyên karûbarê barkirî û kargêrê barkirinê di pêvajoya ceribandina barkirinê de têne destnîşankirin.
Metrîkên bingehîn ji bo pîvandina pîvanên barkirinê
Hin ji yên ku herî gelemperî di metodolojiyê de têne bikar anîn û pêşniyar kirin (r. 36, 52) metrîk di tabloya jêrîn de têne xuyang kirin. Metrîkên wekhev ên ji bo ajan û armancê li ser heman rêzê têne navnîş kirin.
Metrics ji bo agent load
Metrîkên pergala armanc an serîlêdana ku di bin barkirinê de têne ceribandin
Hejmara vCPU û bîranîn BERAN,
dîskê - Taybetmendiyên "hesin" ên barkêşê
CPU, Bîr, bikaranîna dîskê - dînamîkên CPU, bîranîn û barkirina dîskê
di pêvajoya ceribandinê de. Bi gelemperî wekî ji sedî tê pîvandin
herî zêde nirxên berdest
berbi torê (li ser kargêrê barkirinê) - berbi
pêwendiya torê ya li ser serverê,
cihê ku agent load tê sazkirin.
Bi gelemperî bi bytes per second (bps) tê pîvandin
berbi torê(li ser armancê) - band pêwendiya torê
li ser server hedef. Bi gelemperî bi bytes per second (bps) tê pîvandin
bikarhênerên virtual- hejmara bikarhênerên virtual,
pêkanîna senaryoyên load û
teqlîdkirina kiryarên bikarhênerê rastîn
Rewşa bikarhênerên virtual, Derbas bû / Biserneket / Tev - hejmara serketî û
statûyên neserkeftî yên bikarhênerên virtual
ji bo senaryoyên barkirinê, û her weha jimara giştî ya wan.
Bi gelemperî tê çaverê kirin ku hemî bikarhêneran karîbûn temam bikin
hemî karên we di profîla barkirinê de hatine destnîşan kirin.
Her xeletî dê were vê wateyê ku bikarhênerek rastîn dê nikaribe
dema ku bi pergalê re dixebitin pirsgirêka xwe çareser bikin
Daxwazên di çirkeyê de (deqqe)- hejmara daxwazên torê li her çirke (an minute).
Taybetmendiyek girîng a agentek barkirinê ev e ku ew çend daxwazan dikare çêbike.
Bi rastî, ev teqlîdek gihîştina serîlêdanê ji hêla bikarhênerên virtual ve ye
Bersiv her çirke (deqe)
- hejmara bersivên torê li her çirke (an hûrdem).
Taybetmendiyek girîng a karûbarê armanc: çiqas
biafirînin û bersivên pirsan bişînin
agent barkirinê
Rewşa bersiva HTTP- hejmara kodên bersivên cihêreng
ji servera serîlêdanê ya ku ji hêla kargêrê barkirinê ve hatî wergirtin.
Mînakî, 200 OK tê wateya bangek serketî,
û 404 - ku çavkanî nehat dîtin
Latînî (dema bersivê) - dem ji dawiyê
şandina daxwazek (daxwaz) berî ku dest bi wergirtina bersivekê (bersiv) bike.
Bi gelemperî di milliseconds (ms) de têne pîvandin
dema bersivdana danûstandinê- dema yek danûstendina tevahî,
temamkirina çerxa daxwaz-bersiv.
Ev dem ji destpêka şandina daxwazê (daxwaz)
heta temamkirina wergirtina bersivekê (bersiv).
Demjimêra danûstendinê dikare bi çirkeyan (an hûrdeman) were pîvandin.
bi çend awayan: kêmtirîn bifikirin,
herî zêde, navîn û, ji bo nimûne, sedî 90.
Xwendinên herî kêm û herî zêde zehf in
rewşa performansa pergalê.
Ji sedî nodemîn ya ku herî zêde tê bikar anîn e,
wekî ku ew piraniya bikarhêneran nîşan dide,
bi rehetî li ber deriyê performansa pergalê dixebite
Danûstendinên di çirkeyê de (minute) - hejmara temam
danûstendinên di çirkeyê de (minute),
ew e, ku serlêdana çiqas karibûye qebûl bike û
daxwazên pêvajoyê bikin û bersivên pirsgirêkê bikin.
Di rastiyê de, ev hilbera pergalê ye
Rewşa danûstandinê , Derbas bû / Biserneket / Bi tevahî - hejmar
serketî, neserkeftî û hejmara giştî ya danûstandinan.
Ji bo bikarhênerên rastîn neserkeftî
danûstendin bi rastî tê wê wateyê
nekarîna bi pergalê re di bin barkirinê de bixebite
Diagrama Schematic Testkirina Barkirinê
Têgeha ceribandina barkirinê pir hêsan e û ji sê qonaxên sereke pêk tê, ku min berê behs kir: Amade-Test-Raport bikin, ango amadekirina armancên ceribandinê û danîna parametreyên ji bo çavkaniyên barkirinê, dûv re ceribandinên barkirinê û, di dawiyê de, hilberandin û weşandina raportek ceribandinê.
Nîşaneyên Schematic:
- QA.Tester di ceribandina barkirinê de pispor e,
- Target serîlêdana armanc e ku hûn dixwazin tevgera wê di bin barkirinê de bizanibin.
Klasifkerê pêkhateyan, qonax û gavên di diagramê de
Qonax û gav
Çi diqewime
Çi li derî ye
Hilber çi ye
Amadekirin: qonaxa amadekariyê ji bo ceribandinê
LoadParameters
Sazkirin û destpêkirin
bikaranîvan
Parametreyên barkirinê,
hilbijartina metrics û
amadekirina plana testê
(profîla barkirinê)
Vebijarkên Custom ji bo
destpêkirina agent load
Plana testê
Armanca ceribandinê
VM
bicihkirina ewr
makîneya virtual bi
taybetmendiyên pêwîst
Mîhengên VM-ê ji bo nûnerê barkirinê
Nivîsarên Otomatîkî ji bo
Afirandina VM
VM tê vesaz kirin
ewr
Şandin
Sazkirin û amadekirina OS
jîngehê ji bo
karê agent load
Mîhengên jîngehê ji bo
agent load
Nivîsarên Otomatîkî ji bo
mîhengên jîngehê
Jîngeha amadekirî:
OS, karûbar û sepanan,
ji bo xebatê pêwîst e
agent load
LoadAgents
Sazkirin, veavakirin û parametrekirin
agent barkirinê.
An jî wêneyek docker ji dakêşin
çavkaniya barkirinê ji berê ve hatî mîheng kirin
Wêneyê dokera çavkaniyê bar bike
(YAT, JM an çarçoveya xwe-nivîskî)
Settings
agent load
Saz kirin û amade kirin
ji bo kar agent load
Test: qonaxa pêkanîna ceribandinên barkirinê. Çavkanî ajanên barkirinê ne ku ji bo GitLab CI di hewzên nûnerê veqetandî de têne bicîh kirin
Gazîname
Destpêkirina Agent Load
bi plana testê ya hilbijartî
û pîvanên barkirinê
Vebijêrkên Bikarhêner
ji bo destpêkê
agent load
Plana testê
Armanca ceribandinê
Têketinên darvekirinê
testên barkirinê
Têketinên pergalê
Dînamîkên guhertinên di metrîkên armanc û ajansê barkirinê de
Ajansên Run
Agent Pêkanîna
gelek nivîsarên testê
li gorî
profîla barkirinê
Têkiliya Agent Load
ji bo armanca ceribandinê
Plana testê
Armanca ceribandinê
Logs
Berhevoka têketinên "raw".
di dema ceribandina barkirinê de:
tomarên çalakiya nûnerê barkirin,
rewşa armanca testê
û VM ajanê dimeşîne
Têketinên darvekirinê
testên barkirinê
Têketinên pergalê
Metrics
Di dema ceribandinê de metrîkên "raw" berhev dikin
Dînamîkên guhertinên di metrîkên armancê de
û agent barkirin
Rapor: qonaxa amadekirina rapora testê
Jenerator
Processing komkirin
sîstema barkirinê û
pergala çavdêriyê "raw"
metrics û têketin
Amadekirina raporê li
forma mirovî ya xwendinê
bi hêmanan mimkun e
analîstên
Têketinên darvekirinê
testên barkirinê
Têketinên pergalê
Dînamîkên guhertinên di metrîkan de
hedef û agent load
Têketinên "xav" hatine pêvajo kirin
di forma minasib ji bo
barkirinên hilanîna derve
Rapora barkirina statîk,
mirov-xwende
Weşandin
Belavkirina raporê
li ser barkirinê
testkirina li derve
karûbar
Pêvajoya "xav"
têketin di formatek guncan de
ji bo barkirina derve
depoyên
Li derve hatiye tomarkirin
raporên hilanînê li ser
barkirin, guncaw
ji bo analîzkirina mirovan
Girêdana çavkaniyên barkirinê di şablonê CI de
Ka em derbasî beşa pratîkî bibin. Ez dixwazim li ser hin projeyên di pargîdaniyê de nîşan bidim me têgeha ceribandina barkirinê wekî karûbar bicîh kiriye.
Pêşîn, bi arîkariya endezyarên xwe yên DevOps, me di GitLab CI de hewzek ji ajanên taybetî çêkir da ku ceribandinên barkirinê bimeşînin. Ji bo ku em wan di şablonan de bi yên din re, wek hewzên meclîsê, tevlihev nekin, me etîket li van ajanan zêde kir, : barkirin. Hûn dikarin etîketên din ên têgihîştî bikar bînin. Dipirsin GitLab CI Runners.
Meriv çawa ji hêla hardware ve hêza pêwîst fêr dibe? Taybetmendiyên ajanên barkirinê - hejmarek têr a vCPU, RAM û Disk - dikare li ser bingeha vê rastiyê were hesibandin ku Docker, Python (ji bo Yandex.Tank), nûnerê GitLab CI, Java (ji bo Apache JMeter) divê li ser ajansê were xebitandin. . Ji bo Java di bin JMeter de, di heman demê de tê pêşniyar kirin ku herî kêm 512 MB RAM bikar bînin û, wekî sînorê jorîn, .
Bi vî rengî, li ser bingeha ezmûna me, em pêşniyar dikin ku bi kêmî ve 4 vCPU, 4 GB RAM, 60 GB SSD ji bo ajanên barkirinê bikar bînin. Rêjeya qerta torê li gorî hewcedariyên profîla barkirinê tê destnîşankirin.
Em bi giranî du çavkaniyên barkirinê bikar tînin - Wêneyên dokera Apache JMeter û Yandex.Tank.
Ji bo ceribandina barkirinê amûrek çavkaniyek vekirî ya Yandex e. Mîmariya wê ya modularî li ser bingeha jeneratora daxwaza HTTP-ya asynchronous-based hit-bingeha Phantom-ê ye. Tankê bi protokola SSH-ê çavdêriyek çêkirî ya çavkaniyên servera di bin ceribandinê de ye, dikare bixweber ceribandinê di bin şert û mercên diyarkirî de rawestîne, dikare encaman hem di konsolê de û hem jî di forma grafîkan de nîşan bide, hûn dikarin modulên xwe girêdin. ji bo berfirehkirina fonksiyonê. Bi awayê, me Tank bikar anî dema ku ew hîn ne sereke bû. Di gotara "»hûn dikarin çîroka ku me di sala 2013-an de ceribandina barkirinê bi wê re kir, bixwînin yek ji hilberên pargîdaniya me ye.
amûrek ceribandina barkirina çavkaniya vekirî ya ji Apache ye. Ew dikare ji bo ceribandina serîlêdanên malperê yên statîk û dînamîkî bi heman rengî baş were bikar anîn. JMeter gelek protokol û awayên danûstendina bi serîlêdanan re piştgirî dike: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, hwd.), Xizmetên Malperê SOAP / REST, FTP, TCP, LDAP, SMTP(S), POP3( S) ) û IMAP(S), databasên bi navgîniya JDBC, dikarin fermanên şêlê bicîh bînin û bi tiştên Java re bixebitin. JMeter ji bo çêkirin, debugkirin û pêkanîna planên testê IDE heye. Di heman demê de ji bo xebata rêzika fermanê li ser her pergala xebitandinê ya Java-ya hevgirtî (Linux, Windows, Mac OS X) CLI jî heye. Amûr dikare bi dînamîkî raporek testa HTML-ê çêbike.
Ji bo hêsaniya karanîna di hundurê pargîdaniya me de, ji bo kapasîteya ceribandiner bixwe ku biguhezînin û hawîrdorê zêde bikin, me bi weşana hundurîn re wêneyên doker ên çavkaniyên barkirinê li ser GitLab CI çêkirin. . Bi vî rengî girêdana wan di boriyan de ji bo ceribandinên barkirinê zûtir û hêsantir dike. Meriv çawa bi navgîniya GitLab CI-ê qeydê bi docker push dike - binêre .
Me ji bo Yandex.Tank ev pelê dokera bingehîn girt:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Û ji bo Apache JMeter ev yek:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Hûn dikarin di gotarê de bixwînin ka pergala meya yekbûna domdar çawa dixebite "".
Şablon û boriyê
Mînakek şablonek ji bo pêkanîna ceribandinên barkirinê di projeyê de heye . ew Hûn dikarin rêwerzên ji bo karanîna şablonê bixwînin. Di şablonê bixwe de (pel ) têbinî hene ku her gav ji ber çi berpirsiyar e.
Şablon pir hêsan e û sê qonaxên ceribandina barkirinê ku di diagrama jorîn de hatine destnîşan kirin destnîşan dike: amadekirin, ceribandin û weşandina raporan. Berpirsiyarê vê yekê ye : Amade bikin, ceribandin û rapor bikin.
- Şanocî Pêdivî ye ku ji bo pêşîvekirina armancên ceribandinê an kontrolkirina hebûna wan were bikar anîn. Jîngeha ji bo çavkaniyên barkirinê ne hewce ye ku were mîheng kirin, ew wekî wêneyên docker-ê pêş-avakirî ne û di qeydkirina dokerê de têne şandin: tenê di qonaxa Testê de guhertoya xwestinê diyar bikin. Lê hûn dikarin wan ji nû ve ava bikin û wêneyên xwe yên guhertî çêbikin.
- Şanocî ji bo destnîşankirina çavkaniya barkirinê, ceribandinan, û hilanîna hilberên ceribandinê têne bikar anîn. Hûn dikarin her çavkaniyek barkirinê hilbijêrin: Yandex.Tank, Apache JMeter, ya xwe, an hemî bi hev re. Ji bo neçalakkirina çavkaniyên nepêwist, tenê kar şîrove bikin an jêbirin. Xalên têketinê ji bo çavkaniyên barkirinê:
- Parametreyên destpêkirinê ji bo Yandex.Tank di nav de têne diyar kirin.,
- Parametreyên destpêkirina Apache JMeter di pelê de têne diyar kirin .
Nîşe: Şablona veavakirina meclîsê ji bo sazkirina danûstendina bi pergala CI-ê re tê bikar anîn û tê wateya cîhkirina mantiqa testê di nav de. Ji bo ceribandinan, xala têketinê tê destnîşan kirin, ku li wir nivîsara bash-a kontrolê lê ye. Rêbaza xebitandina ceribandinan, hilberîna raporan, û nivîsarên testê bixwe divê ji hêla endezyarên QA ve bêne bicîh kirin. Di demo de, ji bo her du çavkaniyên barkirinê, daxwaza rûpela sereke ya Yandex wekî ceribandina herî hêsan tê bikar anîn. Skrîpt û parametreyên testê di pelrêçê de ne .
- Di qonaxê de Pêdivî ye ku hûn diyar bikin ka meriv çawa encamên testê yên ku di qonaxa Testê de hatine bidestxistin li depoyên derveyî, mînakî, ji Rûpelên GitLab an pergalên raporkirina taybetî re biweşînin. Rûpelên GitLab hewce dike ku pelrêça ./public ne vala be û bi kêmanî pelek index.html hebe piştî ceribandinan temam bibin. Hûn dikarin li ser hûrgelên karûbarê Rûpelên GitLab bixwînin. .
Nimûneyên çawaniya hinardekirina daneyan:
- ji JMeter heta ,
- ji Yandex.Tank ber .
Talîmatên sazkirinê şandin:
- Statîkên HTML-ê tê de ,
- ji InfluxDB re û paşê jî .
Di mînaka demo de, xeta boriyê bi ceribandinên barkirinê û du çavkaniyên barkirinê (hûn dikarin ya nehewce neçalak bikin) bi vî rengî xuya dike:
Apache JMeter dikare bi xwe raporek HTML-ê çêbike, ji ber vê yekê bi karanîna amûrên standard xilaskirina wê di Rûpelên GitLab de sûdmendtir e. Rapora Apache JMeter bi vî rengî xuya dike:
Di mînaka demo ya Yandex.Tank de, hûn ê tenê bibînin di beşa ji bo Rûpelên GitLab. Di dema ceribandinê de, Tank dikare encaman li databasa InfluxDB hilîne, û ji wir ew dikarin werin xuyang kirin, mînakî, li Grafana (veavakirin di pelê de tê kirin ). Bi vî rengî rapora Tank di Grafana de xuya dike:
Nîqaş
Di gotarê de, min li ser têgeha "ceribandina barkirinê wekî karûbar" (ceribandina barkirinê wekî karûbar) peyivî. Fikra sereke ev e ku meriv binesaziya hewzên ji berê vesazkirî yên ajanên barkirinê, wêneyên dokerê yên çavkaniyên barkirinê, pergalên raporkirinê û boriyek ku wan di GitLab CI-ê de li ser bingeha şablonek .gitlab-ci.yml ya hêsan berhev dike, bikar bîne (mînak ). Hemî ev ji hêla tîmek piçûk a endezyarên otomasyonê ve têne piştgirî kirin û li ser daxwaza tîmên hilberê têne dubare kirin. Ez hêvî dikim ku ev dê ji we re bibe alîkar ku hûn di pargîdaniya we de nexşeyek weha amade bikin û bicîh bikin. Spas ji bo baldariya we!
PS Ez dixwazim spasiyek mezin ji hevkarên xwe, Sergey Kurbanov û Nikolai Yusev re bibêjim, ji bo alîkariya teknîkî ya di pêkanîna konsepta ceribandina barkirinê de wekî karûbarê di pargîdaniya me de.
nivîskar: - Wekîl Serokê Teknolojî û Pêvajoyên Pêşketinê (DevOps) li Teknolojiyên Positive
Source: www.habr.com