RIT 2019-ին մեր գործընկեր Ալեքսանդր Կորոտկովը պատրաստեց CIAN-ում զարգացման ավտոմատացման մասին. կյանքը և աշխատանքը հեշտացնելու համար մենք օգտագործում ենք մեր սեփական Integro հարթակը: Այն հետևում է առաջադրանքների կյանքի ցիկլին, ծրագրավորողներին ազատում է սովորական գործառնություններից և զգալիորեն նվազեցնում է արտադրության սխալների քանակը: Այս գրառման մեջ մենք կլրացնենք Ալեքսանդրի զեկույցը և կպատմենք ձեզ, թե ինչպես մենք անցանք պարզ սցենարներից մինչև մեր սեփական հարթակի միջոցով բաց կոդով արտադրանքի համադրումը և ինչ է անում մեր առանձին ավտոմատացման թիմը:
Զրոյական մակարդակ
«Զրոյական մակարդակ գոյություն չունի, ես նման բան չգիտեմ»
Վարպետ Շիֆուն «Kung Fu Panda» ֆիլմից
CIAN-ում ավտոմատացումը սկսվել է ընկերության հիմնադրումից 14 տարի անց: Այն ժամանակ մշակողների թիմում կար 35 մարդ։ Դժվար է հավատալ, չէ՞: Իհարկե, ավտոմատացումը ինչ-որ ձևով գոյություն ուներ, բայց շարունակական ինտեգրման և կոդերի առաքման առանձին ուղղություն սկսեց ձևավորվել 2015 թվականին:
Այն ժամանակ մենք ունեինք Python-ի, C#-ի և PHP-ի հսկայական մոնոլիտ, որը տեղակայված էր Linux/Windows սերվերների վրա: Այս հրեշը տեղակայելու համար մենք ունեինք մի շարք սցենարներ, որոնք մենք գործարկեցինք ձեռքով: Եղավ նաև մոնոլիտի հավաքում, որը ցավ ու տառապանք բերեց կոնֆլիկտների պատճառով՝ ճյուղերի միաձուլման, թերությունների շտկման և «կառուցման այլ առաջադրանքներով» վերակառուցման ժամանակ։ Պարզեցված գործընթացն այսպիսի տեսք ուներ.
Մենք գոհ չէինք դրանով, և մենք ցանկանում էինք կառուցել կրկնվող, ավտոմատացված և կառավարելի կառուցման և տեղակայման գործընթաց: Դրա համար մեզ անհրաժեշտ էր CI/CD համակարգ, և մենք ընտրեցինք Teamcity-ի անվճար տարբերակի և Jenkins-ի անվճար տարբերակի միջև, քանի որ մենք աշխատել ենք նրանց հետ և երկուսն էլ մեզ հարմար են գործառույթների հավաքածուի առումով: Մենք ընտրեցինք Teamcity-ն որպես ավելի թարմ արտադրանք: Այն ժամանակ մենք դեռ չէինք օգտագործել միկրոսերվիսային ճարտարապետություն և չէինք սպասում մեծ թվով առաջադրանքներ ու նախագծեր։
Մենք գալիս ենք մեր սեփական համակարգի գաղափարին
Teamcity-ի իրականացումը վերացրեց ձեռնարկի աշխատանքի միայն մի մասը. մնում է Pull Requests-ի ստեղծումը, հարցերի առաջխաղացումն ըստ կարգավիճակի Jira-ում և թողարկվող հարցերի ընտրությունը: Teamcity համակարգն այլևս չկարողացավ հաղթահարել սրան: Պետք էր ընտրել հետագա ավտոմատացման ուղին։ Մենք դիտարկել ենք Teamcity-ում սկրիպտների հետ աշխատելու կամ երրորդ կողմի ավտոմատացման համակարգերին անցնելու տարբերակներ: Բայց ի վերջո որոշեցինք, որ մեզ անհրաժեշտ է առավելագույն ճկունություն, որը կարող է ապահովել միայն մեր սեփական լուծումը։ Այսպես հայտնվեց Ինտեգրո կոչվող ներքին ավտոմատացման համակարգի առաջին տարբերակը։
Teamcity-ն զբաղվում է ավտոմատացման հետ՝ կառուցման և տեղակայման գործընթացների գործարկման մակարդակով, մինչդեռ Integro-ն կենտրոնացած է զարգացման գործընթացների վերին մակարդակի ավտոմատացման վրա: Անհրաժեշտ էր համատեղել աշխատանքը Jira-ի խնդիրների հետ Bitbucket-ում հարակից սկզբնական կոդի մշակման հետ: Այս փուլում Integro-ն սկսեց ունենալ իր աշխատանքային հոսքերը տարբեր տեսակի առաջադրանքների հետ աշխատելու համար:
Բիզնես գործընթացներում ավտոմատացման ավելացման շնորհիվ Teamcity-ում ավելացել է նախագծերի և գործարկումների քանակը: Այսպիսով, առաջացավ նոր խնդիր. Teamcity-ի մեկ անվճար օրինակը բավարար չէր (3 գործակալ և 100 նախագիծ), մենք ավելացրինք ևս մեկ օրինակ (ևս 3 գործակալ և 100 նախագիծ), հետո ևս մեկը: Արդյունքում մենք հայտնվեցինք մի քանի կլաստերներից բաղկացած համակարգով, որը դժվար էր կառավարել.
Երբ 4-րդ ատյանի հարցը ծագեց, մենք հասկացանք, որ չենք կարող այսպես շարունակել ապրել, քանի որ 4 ատյանների աջակցության ընդհանուր ծախսերն այլևս որևէ սահմանի մեջ չեն։ Հարց առաջացավ վճարովի Teamcity գնելու կամ անվճար Jenkins-ի ընտրության մասին։ Մենք հաշվարկներ արեցինք օրինակների և ավտոմատացման պլանների վերաբերյալ և որոշեցինք, որ ապրելու ենք Ջենքինսի վրա: Մի քանի շաբաթ անց մենք անցանք Jenkins-ին և վերացրեցինք մի քանի գլխացավ, որը կապված էր Teamcity-ի բազմաթիվ օրինակների պահպանման հետ: Հետևաբար, մենք կարողացանք կենտրոնանալ Integro-ի մշակման և Jenkins-ը մեզ համար հարմարեցնելու վրա:
Հիմնական ավտոմատացման աճով (Pull Requests-ի ավտոմատ ստեղծման, կոդի ծածկույթի և այլ ստուգումների հավաքագրման և հրապարակման տեսքով) մեծ ցանկություն կա հնարավորինս հրաժարվել ձեռքով թողարկումներից և այդ աշխատանքը տալ ռոբոտներին: Բացի այդ, ընկերությունը սկսեց տեղափոխվել ընկերության ներսում գտնվող միկրոսերվիսներ, որոնք պահանջում էին հաճախակի թողարկումներ և միմյանցից առանձին: Ահա թե ինչպես մենք աստիճանաբար հասանք մեր միկրոծառայությունների ավտոմատ թողարկումներին (գործընթացի բարդության պատճառով ներկայումս մոնոլիտը ձեռքով ենք թողարկում): Բայց, ինչպես սովորաբար լինում է, նոր բարդություն առաջացավ։
Մենք ավտոմատացնում ենք թեստավորումը
Թողարկումների ավտոմատացման շնորհիվ զարգացման գործընթացներն արագացել են՝ մասամբ որոշ փորձարկման փուլերի բացթողման պատճառով։ Եվ դա հանգեցրեց որակի ժամանակավոր կորստի: Դա չնչին է հնչում, բայց թողարկումների արագացմանը զուգահեռ անհրաժեշտ էր փոխել արտադրանքի մշակման մեթոդոլոգիան։ Պետք էր մտածել թեստավորման ավտոմատացման, անձնական պատասխանատվություն սերմանելու մասին (այստեղ խոսքը գնում է «գաղափարը գլխում ընդունելու», ոչ թե դրամական տուգանքների մասին) թողարկված կոդի և դրանում առկա սխալների համար մշակողի, ինչպես նաև որոշման մասին. ազատել/չթողարկել առաջադրանքը ավտոմատ տեղակայման միջոցով:
Վերացնելով որակի խնդիրները՝ մենք հանգեցինք երկու կարևոր որոշման. մենք սկսեցինք անցկացնել դեղձանիկների թեստավորում և ներմուծեցինք սխալի ֆոնի ավտոմատ մոնիտորինգ՝ դրա ավելցուկին ավտոմատ արձագանքով: Առաջին լուծումը հնարավորություն տվեց գտնել ակնհայտ սխալներ, նախքան ծածկագիրը ամբողջությամբ թողարկվեց արտադրության մեջ, երկրորդը նվազեցրեց արտադրության մեջ առկա խնդիրների արձագանքման ժամանակը: Սխալներ, իհարկե, լինում են, բայց մենք մեր ժամանակի և ջանքերի մեծ մասը ծախսում ենք ոչ թե դրանք ուղղելու, այլ նվազագույնի հասցնելու վրա։
Ավտոմատացման թիմ
Ներկայումս մենք ունենք 130 ծրագրավորողների աշխատակազմ, և շարունակում ենք . Շարունակական ինտեգրման և կոդերի առաքման թիմը (այսուհետ՝ Deploy and Integration կամ DI թիմ) բաղկացած է 7 հոգուց և աշխատում է 2 ուղղությամբ՝ Integro ավտոմատացման հարթակի մշակում և DevOps։
DevOps-ը պատասխանատու է CIAN կայքի Dev/Beta միջավայրի, Integro միջավայրի համար, օգնում է ծրագրավորողներին լուծել խնդիրները և մշակել նոր մոտեցումներ ընդլայնման միջավայրերի համար: Integro-ի մշակման ուղղությունը վերաբերում է ինչպես Ինտեգրոյին, այնպես էլ հարակից ծառայություններին, օրինակ՝ Jenkins-ի, Jira-ի, Confluence-ի հավելումների, ինչպես նաև մշակում է օժանդակ կոմունալ ծառայություններ և հավելվածներ զարգացման թիմերի համար:
DI թիմը համագործակցում է Պլատֆորմի թիմի հետ, որը մշակում է ներքին ճարտարապետությունը, գրադարանները և զարգացման մոտեցումները: Միևնույն ժամանակ, CIAN-ի ցանկացած ծրագրավորող կարող է նպաստել ավտոմատացմանը, օրինակ՝ միկրոավտոմատացում կատարել թիմի կարիքներին համապատասխան կամ կիսվել հիանալի գաղափարով, թե ինչպես կարելի է ավելի լավը դարձնել ավտոմատացումը:
Ավտոմատացման շերտավոր տորթ CIAN-ում
Ավտոմատացման մեջ ներգրավված բոլոր համակարգերը կարելի է բաժանել մի քանի շերտերի.
- Արտաքին համակարգեր (Jira, Bitbucket և այլն): Նրանց հետ աշխատում են զարգացման թիմերը:
- Ինտեգրո հարթակ. Ամենից հաճախ ծրագրավորողները ուղղակիորեն չեն աշխատում դրա հետ, բայց դա այն է, ինչը թույլ է տալիս գործարկել ամբողջ ավտոմատացումը:
- Առաքման, նվագախմբի և հայտնաբերման ծառայություններ (օրինակ՝ Jeknins, Consul, Nomad): Նրանց օգնությամբ մենք տեղադրում ենք կոդը սերվերների վրա և ապահովում, որ ծառայություններն աշխատում են միմյանց հետ:
- Ֆիզիկական շերտ (սերվերներ, ՕՀ, հարակից ծրագրեր): Մեր կոդը գործում է այս մակարդակում: Սա կարող է լինել կամ ֆիզիկական սերվեր, կամ վիրտուալ (LXC, KVM, Docker):
Այս հայեցակարգի հիման վրա մենք բաժանում ենք պատասխանատվության ոլորտները DI թիմի ներսում: Առաջին երկու մակարդակները գտնվում են Integro-ի զարգացման ուղղության պատասխանատվության ոլորտում, իսկ վերջին երկու մակարդակներն արդեն DevOps-ի պատասխանատվության ոլորտում են: Այս տարանջատումը թույլ է տալիս կենտրոնանալ առաջադրանքների վրա և չի խանգարում փոխգործակցությանը, քանի որ մենք մտերիմ ենք միմյանց հետ և անընդհատ փոխանակում ենք գիտելիքներն ու փորձը:
Ինտեգրո
Եկեք կենտրոնանանք Integro-ի վրա և սկսենք տեխնոլոգիական փաթեթից.
- CentOS 7
- Docker + Nomad + Consul + Vault
- Java 11 (հին Integro մոնոլիտը կմնա Java 8-ում)
- Spring Boot 2.X + Spring Cloud Config
- PostgreSql 11
- Rabbit MQ
- Apache Ignite
- Կամունդա (ներկառուցված)
- Գրաֆանա + Գրաֆիտ + Պրոմեթևս + Յագեր + ELK
- Վեբ միջերես՝ React (CSR) + MobX
- SSO: Keycloak
Մենք հավատարիմ ենք միկրոծառայությունների զարգացման սկզբունքին, թեև ունենք ժառանգություն Integro-ի վաղ տարբերակի մոնոլիտի տեսքով: Յուրաքանչյուր միկրոսերվիս աշխատում է իր Docker կոնտեյներով, և ծառայությունները միմյանց հետ շփվում են HTTP հարցումների և RabbitMQ հաղորդագրությունների միջոցով: Microservices-ը գտնում են միմյանց հյուպատոսի միջոցով և հարցում են անում նրան՝ փոխանցելով թույլտվությունը SSO-ի միջոցով (Keycloak, OAuth 2/OpenID Connect):
Որպես իրական կյանքի օրինակ, դիտարկեք Ջենկինսի հետ փոխգործակցությունը, որը բաղկացած է հետևյալ քայլերից.
- Աշխատանքային հոսքերի կառավարման միկրոսերվիսը (այսուհետ՝ «Flow microservice») ցանկանում է գործարկել Jenkins-ում: Դա անելու համար նա օգտագործում է հյուպատոսը՝ գտնելու համար միկրոծառայության IP:PORT՝ Ջենկինսի հետ ինտեգրվելու համար (այսուհետ՝ Ջենքինսի միկրոսերվիս) և նրան ուղարկում է ասինքրոն հարցում՝ Ջենկինսում կառուցումը սկսելու համար:
- Հարցում ստանալուց հետո Jenkins միկրոսերվիսը ստեղծում և պատասխանում է Job ID-ով, որն այնուհետև կարող է օգտագործվել աշխատանքի արդյունքը բացահայտելու համար: Միևնույն ժամանակ, այն գործարկում է կառուցումը Jenkins-ում REST API զանգի միջոցով:
- Jenkins-ը կատարում է կառուցումը և ավարտից հետո ուղարկում է վեբ-կապ՝ կատարման արդյունքներով Jenkins միկրոսերվիս:
- Ջենկինսի միկրոսերվիսը, ստանալով վեբ-կեռիկը, ստեղծում է հաղորդագրություն հարցումների մշակման ավարտի մասին և դրան կցում է կատարման արդյունքները: Ստեղծված հաղորդագրությունն ուղարկվում է RabbitMQ հերթին:
- RabbitMQ-ի միջոցով հրապարակված հաղորդագրությունը հասնում է Flow միկրոսերվիսին, որն իմանում է իր առաջադրանքի մշակման արդյունքի մասին՝ համապատասխանեցնելով Job ID-ն հարցումից և ստացված հաղորդագրությունից։
Այժմ մենք ունենք մոտ 30 միկրոծառայություններ, որոնք կարելի է բաժանել մի քանի խմբերի.
- Կազմաձևման կառավարում.
- Տեղեկատվություն և փոխազդեցություն օգտվողների հետ (մեսենջերներ, փոստ):
- Աշխատեք սկզբնական կոդի հետ:
- Ինտեգրում տեղակայման գործիքների հետ (ջենկիններ, քոչվոր, հյուպատոս և այլն):
- Մոնիտորինգ (թողարկումներ, սխալներ և այլն):
- Վեբ կոմունալ ծառայություններ (UI՝ թեստային միջավայրերը կառավարելու, վիճակագրություն հավաքելու և այլն):
- Ինտեգրում առաջադրանքների հետքերով և նմանատիպ համակարգերով:
- Աշխատանքային հոսքի կառավարում տարբեր խնդիրների համար:
Աշխատանքային հոսքի առաջադրանքներ
Integro-ն ավտոմատացնում է առաջադրանքի կյանքի ցիկլի հետ կապված գործողությունները: Պարզեցված բառերով, առաջադրանքի կյանքի ցիկլը կհասկանա որպես Jira-ում առաջադրանքի աշխատանքային ընթացք: Մեր զարգացման գործընթացները ունեն մի քանի աշխատանքային հոսքի տատանումներ՝ կախված նախագծից, առաջադրանքի տեսակից և որոշակի առաջադրանքում ընտրված տարբերակներից:
Եկեք նայենք աշխատանքի ընթացքին, որը մենք ամենից հաճախ օգտագործում ենք.
Դիագրամում հանդերձանքը ցույց է տալիս, որ անցումը կոչվում է ավտոմատ կերպով Integro-ի կողմից, մինչդեռ մարդու պատկերը ցույց է տալիս, որ անցումը կոչվում է ձեռքով անձի կողմից: Եկեք նայենք մի քանի ուղիների, որոնցով առաջադրանքը կարող է անցնել այս աշխատանքային հոսքում:
Ամբողջովին ձեռքով փորձարկում DEV+BETA-ի վրա՝ առանց դեղձանիկի թեստերի (սովորաբար այսպես ենք թողարկում մոնոլիտ).
Կարող են լինել այլ անցումային համակցություններ: Երբեմն այն ուղին, որով կբռնվի խնդիրը, կարելի է ընտրել Jira-ի տարբերակների միջոցով:
Առաջադրանքի շարժում
Դիտարկենք հիմնական քայլերը, որոնք կատարվում են, երբ առաջադրանքը անցնում է «DEV Testing + Canary Tests» աշխատանքային հոսքի միջոցով.
1. Մշակողը կամ վարչապետը ստեղծում են առաջադրանքը:
2. Մշակողը տանում է առաջադրանքը աշխատանքի: Ավարտից հետո այն անցնում է IN REVIEW կարգավիճակին:
3. Jira-ն Webhook է ուղարկում Jira microservice-ին (պատասխանատու է Jira-ի հետ ինտեգրվելու համար):
4. Jira միկրոսերվիսը հարցում է ուղարկում Flow ծառայությանը (պատասխանատու է ներքին աշխատանքային հոսքերի համար, որոնցում կատարվում է աշխատանքը)՝ աշխատանքի հոսքը սկսելու համար:
5. Flow ծառայության ներսում.
- Վերանայողներին հանձնարարվում է առաջադրանքը (Users microservice, որն ամեն ինչ գիտի օգտվողների մասին + Jira microservice):
- Source microservice-ի միջոցով (այն գիտի պահեստների և մասնաճյուղերի մասին, բայց չի աշխատում ինքնին կոդով), որոնվում է այն պահեստները, որոնք պարունակում են մեր թողարկման մասնաճյուղը (որոնումը պարզեցնելու համար մասնաճյուղի անվանումը համընկնում է խնդրի հետ. համարը Ժիրայում): Ամենից հաճախ, առաջադրանքն ունի միայն մեկ ճյուղ մեկ պահեստում, դա հեշտացնում է տեղակայման հերթի կառավարումը և նվազեցնում կապը պահեստների միջև:
- Յուրաքանչյուր հայտնաբերված ճյուղի համար կատարվում է գործողությունների հետևյալ հաջորդականությունը.
թ) Վարպետ մասնաճյուղի թարմացում (Git microservice՝ կոդի հետ աշխատելու համար):
ii) Մասնաճյուղն արգելափակված է ծրագրավորողի կողմից փոփոխություններից (Bitbucket microservice):
iii) Այս մասնաճյուղի համար ստեղծվում է Pull Request (Bitbucket microservice):
iv) Նոր Pull Request-ի մասին հաղորդագրություն է ուղարկվում ծրագրավորողների զրույցներին (Տեղեկացնել միկրոսերվիսին ծանուցումների հետ աշխատելու համար):
v) Ստեղծեք, փորձարկեք և տեղակայեք առաջադրանքները DEV-ի վրա (Jenkins միկրոսերվիս՝ Jenkins-ի հետ աշխատելու համար):
vi) Եթե բոլոր նախորդ քայլերը հաջողությամբ ավարտված են, ապա Integro-ն իր հաստատումը դնում է Pull Request-ում (Bitbucket microservice): - Integro-ն սպասում է Հաստատման հարցում նշանակված գրախոսներից:
- Հենց որ բոլոր անհրաժեշտ հաստատումները ստացվեն (ներառյալ ավտոմատացված թեստերը դրական են անցել), Integro-ն առաջադրանքը տեղափոխում է Test on Dev (Jira microservice) կարգավիճակ:
6. Փորձարկողները փորձարկում են առաջադրանքը: Եթե խնդիրներ չկան, ապա առաջադրանքը փոխանցվում է Ready For Build կարգավիճակին:
7. Ինտեգրոն «տեսնում է», որ առաջադրանքը պատրաստ է թողարկման և սկսում է իր տեղակայումը դեղձանիկ ռեժիմով (Ջենկինս միկրոսերվիս): Ազատման պատրաստակամությունը որոշվում է մի շարք կանոններով. Օրինակ, առաջադրանքը գտնվում է պահանջվող կարգավիճակում, այլ առաջադրանքների վրա կողպեքներ չկան, ներկայումս այս միկրոսերվիսի ակտիվ բեռնումներ չկան և այլն:
8. Առաջադրանքը տեղափոխվում է Կանարյան կարգավիճակ (Jira microservice):
9. Ջենկինսը գործարկում է տեղակայման առաջադրանքը Nomad-ի միջոցով Canary ռեժիմով (սովորաբար 1-3 դեպք) և տեղակայման մասին տեղեկացնում է թողարկման մոնիտորինգի ծառայությանը (DeployWatch microservice):
10. DeployWatch միկրոսերվիսը հավաքում է սխալի նախապատմությունը և անհրաժեշտության դեպքում արձագանքում դրան: Եթե սխալի ֆոնը գերազանցում է (ֆոնային նորմը հաշվարկվում է ավտոմատ կերպով), մշակողները ծանուցվում են Notify microservice-ի միջոցով: Եթե 5 րոպե անց ծրագրավորողը չի արձագանքել (սեղմել է Վերադարձել կամ մնալ), ապա գործարկվում է դեղձանիկների ատյանների ավտոմատ վերադարձը: Եթե ֆոնը գերազանցված չէ, ապա մշակողը պետք է ձեռքով գործարկի առաջադրանքի տեղակայումը Production-ում (սեղմելով կոճակը միջերեսում): Եթե 60 րոպեի ընթացքում ծրագրավորողը չի գործարկել տեղակայումը Արտադրության մեջ, ապա դեղձանիկները նույնպես հետ կհանվեն անվտանգության նկատառումներով:
11. Արտադրության տեղակայումը սկսելուց հետո.
- Առաջադրանքը փոխանցվում է Արտադրության կարգավիճակին (Jira microservice):
- Jenkins միկրոսերվիսը սկսում է տեղակայման գործընթացը և տեղակայման մասին տեղեկացնում է DeployWatch միկրոծառայությանը:
- DeployWatch միկրոսերվիսը ստուգում է, որ արտադրության բոլոր կոնտեյներները թարմացվել են (եղել են դեպքեր, երբ ոչ բոլորն են թարմացվել):
- Notify միկրոծառայության միջոցով տեղակայման արդյունքների մասին ծանուցում է ուղարկվում Արտադրություն:
12. Մշակողները կունենան 30 րոպե՝ սկսելու առաջադրանքը հետ վերադարձնել Production-ից, եթե հայտնաբերվի միկրոսպասարկման սխալ վարքագիծ: Այս ժամանակից հետո առաջադրանքը ավտոմատ կերպով կմիավորվի Master-ի (Git microservice):
13. Master-ին հաջող միաձուլումից հետո առաջադրանքի կարգավիճակը կփոխվի փակվածի (Jira microservice):
Դիագրամը չի հավակնում ամբողջությամբ մանրամասնված լինել (իրականում կան նույնիսկ ավելի շատ քայլեր), բայց թույլ է տալիս գնահատել գործընթացներին ինտեգրվելու աստիճանը։ Մենք այս սխեման իդեալական չենք համարում և բարելավում ենք ավտոմատ թողարկման և տեղակայման աջակցության գործընթացները:
Ինչ է հաջորդը
Մենք մեծ ծրագրեր ունենք ավտոմատացման զարգացման համար, օրինակ՝ վերացնել ձեռքով գործառնությունները մոնոլիտ թողարկումների ժամանակ, բարելավել մոնիտորինգը ավտոմատ տեղակայման ժամանակ և բարելավել փոխգործակցությունը ծրագրավորողների հետ:
Բայց առայժմ կանգ առնենք այստեղ։ Ավտոմատացման վերանայման մեջ շատ թեմաներ մենք մակերեսորեն լուսաբանեցինք, ոմանց ընդհանրապես չշոշափվեց, ուստի սիրով կպատասխանենք հարցերին։ Սպասում ենք առաջարկների, թե ինչին մանրամասն լուսաբանել, գրեք մեկնաբանություններում։
Source: www.habr.com