Mēs runājam par DevOps saprotamā valodā

Vai ir grÅ«ti saprast galveno, runājot par DevOps? Mēs esam apkopojuÅ”i jums spilgtas analoÄ£ijas, pārsteidzoÅ”us formulējumus un ekspertu padomus, kas palÄ«dzēs pat nespeciālistiem tikt pie lietas. Beigās bonuss ir Red Hat darbinieku paÅ”u DevOps.

Mēs runājam par DevOps saprotamā valodā

Termins DevOps radās pirms 10 gadiem un ir kļuvis no Twitter atsauces lÄ«dz spēcÄ«gai kultÅ«ras kustÄ«bai IT pasaulē ā€” patiesai filozofijai, kas mudina izstrādātājus paveikt lietas ātrāk, eksperimentēt un virzÄ«ties uz priekÅ”u. DevOps ir kļuvis nesaraujami saistÄ«ts ar digitālās transformācijas jēdzienu. Taču, kā tas bieži notiek ar IT terminoloÄ£iju, pēdējo desmit gadu laikā DevOps ir ieguvis daudz definÄ«ciju, interpretāciju un nepareizu priekÅ”statu par sevi.

Tāpēc bieži var dzirdēt jautājumus par DevOps, piemēram, vai tas ir tas pats, kas veikls? Vai arÄ« tā ir kāda Ä«paÅ”a metodika? Vai arÄ« tas ir tikai vēl viens sinonÄ«ms vārdam ā€œsadarbÄ«baā€?

DevOps ietver daudz dažādu jēdzienu (nepārtraukta piegāde, nepārtraukta integrācija, automatizācija utt.), tāpēc svarÄ«gā noteikÅ”ana var bÅ«t sarežģīta, it Ä«paÅ”i, ja Ŕī tēma aizraujas. Tomēr Ŕī prasme ir ļoti noderÄ«ga neatkarÄ«gi no tā, vai jÅ«s mēģināt nodot savas idejas saviem priekÅ”niekiem vai vienkārÅ”i pastāstÄ«t kādam no Ä£imenes vai draugiem par savu darbu. Tāpēc pagaidām noliksim malā DevOps terminoloÄ£iskās nianses un koncentrēsimies uz kopējo ainu.

Kas ir DevOps: 6 definīcijas un analoģijas

LÅ«dzām ekspertus pēc iespējas vienkārŔāk un Ä«si izskaidrot DevOps bÅ«tÄ«bu, lai tā vērtÄ«ba kļūtu skaidra lasÄ«tājiem ar jebkāda lÄ«meņa tehniskajām zināŔanām. Pamatojoties uz Å”o sarunu rezultātiem, mēs esam atlasÄ«juÅ”i visspilgtākās analoÄ£ijas un pārsteidzoŔākos formulējumus, kas palÄ«dzēs jums izveidot stāstu par DevOps.

1. DevOps ir kultūras kustība

"DevOps ir kultÅ«ras kustÄ«ba, kurā abas puses (programmatÅ«ras izstrādātāji un IT sistēmu darbÄ«bas speciālisti) atzÄ«st, ka programmatÅ«ra nedod reālus ieguvumus, kamēr kāds to nesāk lietot: klienti, klienti, darbinieki, nevis bÅ«tÄ«ba," saka EvelÄ«na Ērliha, vecākā pētniece. analÄ«tiÄ·is DevOps institÅ«tā. "Tāpēc abas Ŕīs puses kopÄ«gi nodroÅ”ina ātru un kvalitatÄ«vu programmatÅ«ras piegādi."

2. DevOps ir izstrādātāju pilnvaru pieŔķirŔana.

"DevOps dod iespēju izstrādātājiem piederēt lietojumprogrammām, palaist tās un pārvaldīt piegādi no sākuma līdz beigām."

"Parasti par DevOps tiek runāts kā par veidu, kā paātrināt lietojumprogrammu piegādi ražoÅ”anai, veidojot un ievieÅ”ot automatizētus procesus," saka Jai ā€‹ā€‹Schniepp, apdroÅ”ināŔanas kompānijas Liberty Mutual DevOps platformu direktors. "Bet man tā ir daudz bÅ«tiskāka lieta." DevOps sniedz izstrādātājiem iespēju iegÅ«t Ä«paÅ”umā lietojumprogrammas vai noteiktas programmatÅ«ras daļas, palaist tās un pārvaldÄ«t to piegādi no sākuma lÄ«dz beigām. DevOps novērÅ” atbildÄ«bas neskaidrÄ«bas un palÄ«dz visiem, kas iesaistÄ«ti automatizētas, izstrādātāju vadÄ«tas infrastruktÅ«ras izveidē.

3. DevOps ir par sadarbību lietojumprogrammu izveidē un piegādē.

"VienkārŔi sakot, DevOps ir pieeja programmatūras ražoŔanai un piegādei, kurā visi strādā kopā," saka Gur Staf, BMC prezidents un digitālā biznesa automatizācijas vadītājs.

4. DevOps ir cauruļvads

"Konveijera montāža ir iespējama tikai tad, ja visas detaļas sader kopā."

"Es salÄ«dzinātu DevOps ar automaŔīnu montāžas lÄ«niju," turpina Gur Staff. ā€“ Ideja ir iepriekÅ” projektēt un izgatavot visas detaļas, lai pēc tam tās varētu salikt bez individuālas pielāgoÅ”anas. Konveijera montāža ir iespējama tikai tad, ja visas detaļas sader kopā. Tiem, kas projektē un bÅ«vē dzinēju, jāapsver, kā to piestiprināt pie korpusa vai rāmja. Tiem, kas taisa bremzes, jādomā par riteņiem utt. Tam vajadzētu bÅ«t arÄ« ar programmatÅ«ru.

Izstrādātājam, kas veido biznesa loÄ£iku vai lietotāja saskarni, ir jādomā par datubāzi, kurā tiek glabāta klienta informācija, droŔības pasākumiem lietotāju datu aizsardzÄ«bai un par to, kā tas viss darbosies, kad pakalpojums sāks apkalpot lielu, iespējams, pat vairāku miljonu dolāru lietotāju auditoriju. ā€.

ā€œLielākais Ŕķērslis, kas jāpārvar, ir likt cilvēkiem sadarboties un domāt par darba daļām, ko veic citi, nevis koncentrēties tikai uz saviem uzdevumiem. Ja jÅ«s to varat izdarÄ«t, jums ir lieliskas digitālās transformācijas iespējas,ā€ piebilst Gur Staff.

5. DevOps ir pareizā cilvēku, procesu un automatizācijas kombinācija

Jayne Groll, DevOps institÅ«ta izpilddirektors, piedāvāja lielisku analoÄ£iju, lai izskaidrotu DevOps. Viņas vārdiem sakot, ā€œDevOps ir kā recepte ar trim galvenajām sastāvdaļu kategorijām: cilvēki, process un automatizācija. Lielāko daļu Å”o sastāvdaļu var iegÅ«t no citām jomām un avotiem: Lean, Agile, SRE, CI/CD, ITIL, vadÄ«ba, kultÅ«ra, instrumenti. DevOps, tāpat kā jebkuras labas receptes, noslēpums ir tas, kā iegÅ«t pareizās proporcijas un Å”o sastāvdaļu maisÄ«jumu, lai palielinātu lietojumprogrammu izveides un izlaiÅ”anas ātrumu un efektivitāti.

6. DevOps ir tad, kad programmētāji strādā kā Formula 1 komanda

"Sacensības nav plānotas no sākuma līdz finiŔam, bet tieŔi otrādi, no finiŔa līdz startam."

"Kad es runāju par to, ko sagaidÄ«t no DevOps iniciatÄ«vas, es domāju par NASCAR vai Formula 1 sacÄ«kÅ”u komandu kā piemēru," saka Kriss Å orts, Red Hat mākoņa platformas mārketinga vecākais menedžeris un DevOps'ish biļetena izdevējs. ā€“ Šādas komandas lÄ«derim ir viens mērÄ·is: sacensÄ«bu noslēgumā ieņemt pēc iespējas augstāku vietu, ņemot vērā komandai pieejamos resursus un izaicinājumus, kas to piemeklēja. Å ajā gadÄ«jumā sacensÄ«bas tiek plānotas nevis no starta lÄ«dz finiÅ”am, bet tieÅ”i otrādi, no finiÅ”a lÄ«dz startam. Vispirms tiek izvirzÄ«ts ambiciozs mērÄ·is, un tad tiek noteikti veidi, kā to sasniegt. Pēc tam tie tiek sadalÄ«ti apakÅ”uzdevumos un deleģēti komandas locekļiem.

ā€œKomanda visu nedēļu pirms sacensÄ«bām velta, lai pilnveidotu pitstopu. ViņŔ nodarbojas ar spēka treniņiem un kardio, lai uzturētu formu nogurdinoÅ”ai sacensÄ«bu dienai. Prakse strādāt kopā, lai atrisinātu visas problēmas, kas var rasties sacensÄ«bu laikā. Tāpat izstrādes komandai ir jāapmāca prasme bieži izdot jaunas versijas. Ja jums ir Ŕādas prasmes un labi funkcionējoÅ”a droŔības sistēma, arÄ« jaunu versiju palaiÅ”ana ražoÅ”anā notiek biežāk. Å ajā pasaules skatÄ«jumā palielināts ātrums nozÄ«mē paaugstinātu droŔību,ā€ saka Å orts.

ā€œTas nav par ā€œpareizo lietuā€ darÄ«Å”anu,ā€ Å orts piebilst, ā€œtas ir par pēc iespējas vairāk lietu novērÅ”anu, kas traucē vēlamajam rezultātam. Sadarbojieties un pielāgojieties, pamatojoties uz reāllaikā saņemtajām atsauksmēm. Esiet gatavs anomālijām un strādājiet, lai uzlabotu kvalitāti, lai samazinātu to ietekmi uz virzÄ«bu uz jÅ«su mērÄ·i. Tas ir tas, kas mÅ«s sagaida DevOps pasaulē.

Mēs runājam par DevOps saprotamā valodā

Kā mērogot DevOps: 10 ekspertu padomi

VienkārÅ”i DevOps un masu DevOps ir pilnÄ«gi atŔķirÄ«gas lietas. Mēs jums pateiksim, kā pārvarēt ŔķērŔļus ceļā no pirmās uz otro.

Daudzām organizācijām ceļojums uz DevOps sākas viegli un patīkami. Tiek izveidotas mazas kaislīgas komandas, vecie procesi tiek aizstāti ar jauniem, un pirmie panākumi nav ilgi jāgaida.

Diemžēl tas ir tikai viltus mirdzums, progresa ilÅ«zija, saka Bens Grinnels, konsultāciju uzņēmuma North Highland rÄ«kotājdirektors un digitālās nodaļas vadÄ«tājs. AgrÄ«nās uzvaras noteikti ir iepriecinoÅ”as, taču tās nepalÄ«dz sasniegt galveno mērÄ·i ā€“ plaÅ”i izplatÄ«t DevOps visā organizācijā.

Ir viegli saprast, ka rezultāts ir dalÄ«juma kultÅ«ra starp ā€œmēsā€ un ā€œviņiemā€.

"Bieži vien organizācijas uzsāk Å”os novatoriskos projektus, domājot, ka tie pavērs ceļu galvenajai DevOps attÄ«stÄ«bai, neapsverot, vai citi spēs vai vēlēsies iet Å”o ceļu," skaidro Bens Grinnels. ā€“ Komandas Ŕādu projektu Ä«stenoÅ”anai parasti tiek komplektētas no paÅ”pārliecinātiem ā€œvarangieÅ”iemā€, kuri kaut ko lÄ«dzÄ«gu jau ir darÄ«juÅ”i citās vietās, bet ir jauni jÅ«su organizācijā. Tajā paŔā laikā viņi tiek mudināti pārkāpt un iznÄ«cināt noteikumus, kas joprojām ir saistoÅ”i visiem pārējiem. Ir viegli saprast, ka rezultāts ir ā€œmēsā€ un ā€œviņuā€ kultÅ«ra, kas kavē zināŔanu un prasmju nodoÅ”anu.

"Un Ŕī kultÅ«ras problēma ir tikai viens no iemesliem, kāpēc DevOps ir grÅ«ti mērogot. DevOps komandas saskaras ar pieaugoŔām tehniskām problēmām, kas ir raksturÄ«gas strauji augoÅ”iem IT uzņēmumiem, ā€sacÄ«ja StÄ«vs Ņūmens, Scalyr dibinātājs un priekÅ”sēdētājs.

ā€œMÅ«sdienu pasaulē pakalpojumi mainās, tiklÄ«dz rodas vajadzÄ«ba. Ir lieliski pastāvÄ«gi ieviest un ieviest jaunas funkcijas, taču Ŕī procesa koordinÄ“Å”ana un raduÅ”os problēmu novērÅ”ana ir Ä«stas galvassāpes, piebilst StÄ«vs Ņūmens. ā€“ Ä»oti strauji augoŔās organizācijās inženieriem starpfunkcionālajās komandās ir grÅ«ti saglabāt redzamÄ«bu pārmaiņām un to radÄ«tajiem atkarÄ«bas lÄ«meņa kaskādes efektiem. Turklāt inženieri nav priecÄ«gi, ja viņiem tiek liegta Ŕī iespēja, un rezultātā viņiem kļūst grÅ«tāk izprast raduÅ”os problēmu bÅ«tÄ«bu.

Kā pārvarēt Å”os iepriekÅ” aprakstÄ«tos izaicinājumus un pāriet uz DevOps masveida ievieÅ”anu lielā organizācijā? Eksperti aicina bÅ«t pacietÄ«giem, pat ja jÅ«su galvenais mērÄ·is ir paātrināt programmatÅ«ras izstrādes ciklu un biznesa procesus.

1. Atcerieties, ka kultūras maiņa prasa laiku.

Džeina Grola, DevOps institÅ«ta izpilddirektore: ā€œManuprāt, DevOps paplaÅ”ināŔanai vajadzētu bÅ«t tikpat pakāpeniskai un iteratÄ«vai kā elastÄ«gai attÄ«stÄ«bai (un vienlÄ«dz skartai kultÅ«rai). Agile un DevOps uzsver mazas komandas. Taču, pieaugot Å”o komandu skaitam un integrācijai, arvien vairāk cilvēku pieņem jaunus darba veidus, un rezultātā notiek milzÄ«ga kultÅ«ras transformācija.

2. Pavadiet pietiekami daudz laika, plānojot un izvēloties platformu

Erans Kinsbruners, Perfecto vadoÅ”ais tehniskais evaņģēlists: ā€œLai mērogoÅ”ana darbotos, DevOps komandām vispirms jāiemācās apvienot tradicionālos procesus, rÄ«kus un prasmes, un pēc tam lēnām jākopj un jāstabilizē katrs atseviŔķais DevOps posms. Viss sākas ar rÅ«pÄ«gu lietotāju stāstu un vērtÄ«bu plÅ«smu plānoÅ”anu, kam seko programmatÅ«ras rakstÄ«Å”ana un versiju kontrole, izmantojot uz maÄ£istrāli balstÄ«tu izstrādi vai citas pieejas, kas vislabāk piemērotas koda sazaroÅ”anai un apvienoÅ”anai.

ā€œTad nāk integrācijas un testÄ“Å”anas posms, kurā jau ir nepiecieÅ”ama mērogojama automatizācijas platforma. Å eit DevOps komandām ir svarÄ«gi izvēlēties pareizo platformu, kas atbilst viņu prasmju lÄ«menim un projekta galamērÄ·iem.

Nākamais posms ir izvietoÅ”ana ražoÅ”anā, un tam jābÅ«t pilnÄ«bā automatizētam, izmantojot orÄ·estrÄ“Å”anas rÄ«kus un konteinerus. Ir svarÄ«gi, lai visos DevOps posmos bÅ«tu virtualizētas vides (ražoÅ”anas simulators, kvalitātes nodroÅ”ināŔanas vide un faktiskā ražoÅ”anas vide), un testiem vienmēr izmantot tikai jaunākos datus, lai iegÅ«tu atbilstoÅ”us secinājumus. Analytics ir jābÅ«t gudrai un jāspēj apstrādāt lielus datus ar ātru un praktisku atgriezenisko saiti.

3. Izņemiet vainu no atbildības.

Gordons Hafs, RedHat evaņģēlists: ā€œSistēmas un atmosfēras izveide, kas ļauj un veicina eksperimentÄ“Å”anu, ļauj pieļaut tā sauktās veiksmÄ«gās neveiksmes veiklā programmatÅ«ras izstrādē. Tas nenozÄ«mē, ka neviens cits nav atbildÄ«gs par neveiksmēm. Faktiski atbildÄ«go identificÄ“Å”ana kļūst vēl vienkārŔāka, jo ā€œbÅ«t atbildÄ«gamā€ vairs nenozÄ«mē ā€œizraisÄ«t negadÄ«jumuā€. Tas ir, atbildÄ«bas bÅ«tÄ«ba mainās kvalitatÄ«vi. Četri faktori kļūst kritiski: traucējumu apjoms, pieejas, ražoÅ”anas procesi un stimuli. (Vairāk par Å”iem faktoriem varat lasÄ«t Gordona Hafa rakstā ā€œDevOps stundas: 4 veselÄ«gu eksperimentu aspektiā€.)

4. Atbrīvojiet ceļu uz priekŔu

Bens Grinnels, konsultāciju uzņēmuma North Highland rÄ«kotājdirektors un digitālās nodaļas vadÄ«tājs: ā€œLai sasniegtu mērogu, es iesaku uzsākt ā€œceļu attÄ«rÄ«Å”anasā€ programmu kopā ar novatoriskajiem projektiem. Å Ä«s programmas mērÄ·is ir iztÄ«rÄ«t atkritumus, ko DevOps pionieri atstāj, piemēram, novecojuÅ”us noteikumus un tamlÄ«dzÄ«gas lietas, lai ceļŔ uz priekÅ”u bÅ«tu skaidrs.

ā€œSniedziet cilvēkiem organizatorisku atbalstu un impulsu, izmantojot komunikāciju, kas ir daudz plaŔāka nekā pionieru grupa, plaÅ”i atzÄ«mējot jaunu darba veidu panākumus. ApmācÄ«t cilvēkus, kuri ir iesaistÄ«ti nākamajā DevOps projektu vilnÄ« un ir satraukti par DevOps izmantoÅ”anu pirmo reizi. Un atcerieties, ka Å”ie cilvēki ļoti atŔķiras no pionieriem.

5. Demokratizēt instrumentus

StÄ«vs Ņūmens, Scalyr dibinātājs un priekÅ”sēdētājs: ā€œInstrumentus nedrÄ«kst slēpt no cilvēkiem, un tiem jābÅ«t salÄ«dzinoÅ”i viegli apgÅ«stamiem ikvienam, kas vēlas veltÄ«t laiku. Ja iespēja vaicāt žurnālus ir ierobežota lÄ«dz trim personām, kas ir ā€œsertificētasā€ rÄ«ka lietoÅ”anai, problēmas risināŔanai vienmēr bÅ«s pieejami ne vairāk kā trÄ«s cilvēki, pat ja jums ir ļoti liela skaitļoÅ”anas vide. Citiem vārdiem sakot, Å”eit ir vājÅ” kakls, kas var izraisÄ«t nopietnas (biznesa) sekas.ā€

6. Radīt ideālus apstākļus komandas darbam

Toms Klārks, ITV kopējās platformas vadÄ«tājs: ā€œJÅ«s varat darÄ«t jebko, bet ne visu uzreiz. Tāpēc uzstādiet lielus mērÄ·us, sāciet ar mazumiņu un virzieties uz priekÅ”u ātrās iterācijās. Laika gaitā jÅ«s iegÅ«sit reputāciju, lai paveiktu lietas, tāpēc arÄ« citi vēlēsies izmantot jÅ«su metodes. Un neuztraucieties par ļoti efektÄ«vas komandas izveidi. Tā vietā nodroÅ”iniet cilvēkiem ideālus darba apstākļus, un efektivitāte sekos.

7. Neaizmirstiet par Konveja likumu un Kanban dēļiem

Logans Deigls, CollabNetVersionOne programmatÅ«ras piegādes un DevOps stratēģijas direktors: ā€œIr svarÄ«gi saprast Konveja likuma sekas. Manā pārfrāzējumā Å”is likums nosaka, ka produkti, ko mēs radām, un procesi, ko izmantojam, tostarp DevOps, izrādās strukturēti tāpat kā mÅ«su organizācija.

ā€œJa organizācijā ir daudz tvertņu un, plānojot, veidojot un izlaižot programmatÅ«ru, vadÄ«ba daudzas reizes maina Ä«paÅ”niekus, mērogoÅ”anas efekts bÅ«s nulle vai Ä«slaicÄ«gs. Ja organizācija veido starpfunkcionālas komandas ap produktiem, kas tiek finansēti, koncentrējoties uz tirgu, tad veiksmes iespējas ievērojami palielinās.

ā€œVēl viens svarÄ«gs mērogoÅ”anas aspekts ir visu nepabeigto darbu (WIP, workinprogress) attēloÅ”ana Kanban dēļos. Ja organizācijai ir vieta, kur cilvēki var redzēt Ŕīs lietas, tas ļoti veicina sadarbÄ«bu, kas pozitÄ«vi ietekmē mērogoÅ”anu.

8. Meklējiet vecas rētas

Manuels Paiss, DevOps konsultants un Team Topologies lÄ«dzautors: ā€œDevOps prakses izmantoÅ”ana ārpus Dev un Ops un mēģinājumi tos piemērot citām funkcijām nav optimāla pieeja. Tam noteikti bÅ«s zināma ietekme (piemēram, automatizējot manuālo vadÄ«bu), taču daudz vairāk var panākt, ja sākam ar piegādes un atgriezeniskās saites procesu izpratni.

ā€œJa organizācijas IT sistēmā ir vecas rētas - procedÅ«ras un vadÄ«bas mehānismi, kas ieviesti pagātnes incidentu rezultātā, bet zaudējuÅ”i savu aktualitāti (produktu, tehnoloÄ£iju vai procesu izmaiņu dēļ), tad tās noteikti ir jānoņem. vai izlÄ«dzināt, nevis automatizēt neefektÄ«vus vai nevajadzÄ«gus procesus.

9. Neizmantojiet DevOps iespējas

Entonijs Edvardss, Eggplant operāciju direktors: ā€œDevOps ir ļoti neskaidrs termins, tāpēc katra komanda beidzas ar savu DevOps versiju. Un nekas nav sliktāks, ja organizācijai pēkŔņi ir 20 DevOps veidi, kas ne pārāk labi sader kopā. Katrai no trim izstrādes komandām nav iespējams izveidot savu Ä«paÅ”u saskarni starp izstrādi un produktu pārvaldÄ«bu. Produktiem nevajadzētu bÅ«t arÄ« savām unikālajām cerÄ«bām attiecÄ«bā uz atgriezenisko saiti, kad tie tiek pārsÅ«tÄ«ti uz ražoÅ”anas simulatoru. Pretējā gadÄ«jumā jÅ«s nekad nevarēsit mērogot DevOps.

10. Sludiniet DevOps biznesa vērtību

StÄ«vs Ņūmens, Scalyr dibinātājs un priekÅ”sēdētājs: ā€œStrādājiet, lai atpazÄ«tu DevOps vērtÄ«bu. Mācieties un jÅ«tieties brÄ«vi runāt par to, ko jÅ«s darāt. DevOps ir neticami laika un naudas ietaupÄ«jums (padomājiet: mazāk dÄ«kstāves, Ä«sāks vidējais atveseļoÅ”anās laiks), un DevOps komandām nenogurstoÅ”i jāuzsver (un jāsludina) Å”o iniciatÄ«vu nozÄ«me biznesa panākumos. Tādā veidā var paplaÅ”ināt piekritēju loku un palielināt DevOps ietekmi organizācijā.ā€

BONUS

uz Red Hat forums Krievija MÅ«su paÅ”u DevOps ieradÄ«sies 13. septembrÄ« ā€“ jā, Red Hat kā programmatÅ«ras ražotājam ir savas DevOps komandas un prakses.

MÅ«su inženieris Marks Birgers, kurÅ” izstrādā iekŔējās automatizācijas pakalpojumus citām grupām visā organizācijā, pastāstÄ«s savu stāstu skaidrā krievu valodā - kā Red Hat DevOps komanda migrēja lietojumprogrammas no Hat Virtualization virtuālajām vidēm, kuras pārvalda Ansible uz pilnvērtÄ«gu konteinera formātu. platforma OpenShift.

Bet tas vēl nav viss:

Kad organizācijas ir pārvietojuÅ”as darba slodzi uz konteineriem, tradicionālās lietojumprogrammu uzraudzÄ«bas metodes var nedarboties. Otrajā runā mēs izskaidrosim savu motivāciju mainÄ«t reÄ£istrÄ“Å”anas veidu un parādÄ«sim tā ceļa turpinājumu, kas mÅ«s noveda pie modernām mežizstrādes un uzraudzÄ«bas metodēm.

Avots: www.habr.com

Pievieno komentāru