Մենք մեկ անգամ մեկ հաստատությունում հաճախորդին տրամադրել ենք էլեկտրոնային փաստաթղթերի կառավարման համակարգ: Եվ հետո մեկ այլ օբյեկտ: Եվ ևս մեկ. Եվ չորրորդ և հինգերորդ: Այնքան տարանք, որ հասանք 10 բաժանված օբյեկտի։ Հզոր ստացվեց... հատկապես, երբ հասանք փոփոխությունները մատուցելուն: Որպես արտադրական միացում առաքման մաս, թեստավորման համակարգի 5 սցենար, ի վերջո, պահանջում էր 10 ժամ և 6-7 աշխատող: Նման ծախսերը մեզ ստիպեցին հնարավորինս հազվադեպ առաքումներ կատարել: Երեք տարի աշխատելուց հետո մենք չդիմացանք դրան և որոշեցինք նախագիծը համեմել մի պտղունց DevOps-ով:
Այժմ բոլոր թեստավորումները տեղի են ունենում 3 ժամում, և դրան մասնակցում է 3 մարդ՝ ինժեներ և երկու թեստավորող։ Բարելավումները հստակ արտահայտված են թվերով և հանգեցնում են շատ սիրված TTM-ի կրճատմանը: Ըստ մեր փորձի՝ կան շատ ավելի շատ հաճախորդներ, ովքեր կարող են օգտվել DevOps-ից, քան նրանք, ովքեր նույնիսկ գիտեն դրա մասին: Ուստի DevOps-ը մարդկանց հետ մոտեցնելու համար մենք մշակել ենք պարզ կոնստրուկտոր, որի մասին ավելի մանրամասն կխոսենք այս գրառման մեջ։
Հիմա եկեք ձեզ ավելի մանրամասն պատմենք: Մեկ էներգետիկ ընկերություն 10 խոշոր օբյեկտներում տեղադրում է տեխնիկական փաստաթղթերի կառավարման համակարգ: Այս մասշտաբի նախագծերում առանց DevOps-ի նավարկելը հեշտ չէ, քանի որ ձեռքի աշխատանքի մեծ մասը մեծապես հետաձգում է աշխատանքը և նաև նվազեցնում որակը. բոլոր ձեռքով աշխատանքները հղի են սխալներով: Մյուս կողմից, կան նախագծեր, որտեղ կա միայն մեկ տեղադրում, բայց ամեն ինչ պետք է աշխատի ավտոմատ կերպով, անընդհատ և առանց ձախողման, օրինակ, նույն փաստաթղթերի հոսքի համակարգերը խոշոր մոնոլիտ կազմակերպություններում: Հակառակ դեպքում, ինչ-որ մեկը ձեռքով կկատարի կարգավորումները, կմոռանա տեղակայման հրահանգների մասին, և արդյունքում արտադրության մեջ պարամետրերը կկորչեն, և ամեն ինչ կփլուզվի:
Սովորաբար մենք հաճախորդի հետ աշխատում ենք պայմանագրով, և այս դեպքում մեր շահերը փոքր-ինչ տարբերվում են: Հաճախորդը նախագծին նայում է խիստ բյուջեի և տեխնիկական բնութագրերի շրջանակներում: Կարող է դժվար լինել նրան բացատրել տարբեր DevOps պրակտիկայի առավելությունները, որոնք ներառված չեն տեխնիկական բնութագրերում: Իսկ եթե նա հետաքրքրված է բիզնեսի ավելացված արժեքով արագ թողարկումներով կամ ավտոմատացման խողովակաշար կառուցելով:
Ավաղ, նախապես հաստատված արժեքով աշխատելիս այս հետաքրքրությունը միշտ չէ, որ հայտնաբերվում է: Մեր պրակտիկայում եղել է դեպք, երբ մենք ստիպված ենք եղել ձեռնամուխ լինել անբարեխիղճ և անփույթ կապալառուի զարգացմանը: Սարսափելի էր. չկային արդի սկզբնաղբյուրներ, նույն համակարգի կոդերի բազան տարբեր ինստալացիաներում էր, փաստաթղթերը մասամբ բացակայում էին, մասամբ էլ՝ սարսափելի որակի: Իհարկե, հաճախորդը վերահսկողություն չուներ սկզբնաղբյուրի, հավաքման, թողարկումների և այլնի վրա:
Առայժմ ոչ բոլորը գիտեն DevOps-ի մասին, բայց հենց որ խոսում ենք դրա առավելությունների, ռեսուրսների իրական խնայողության մասին, բոլոր հաճախորդների աչքերը վառվում են։ Այսպիսով, DevOps ներառող հարցումների թիվը ժամանակի ընթացքում ավելանում է: Այստեղ, հաճախորդների հետ նույն լեզվով հեշտությամբ խոսելու համար, մենք պետք է արագ կապենք բիզնեսի խնդիրները և DevOps-ի պրակտիկաները, որոնք կօգնեն կառուցել զարգացման համապատասխան խողովակաշար:
Այսպիսով, մենք մի կողմից ունենք խնդիրների մի շարք, մյուս կողմից՝ DevOps-ի գիտելիքներ, պրակտիկա և գործիքներ: Ինչու՞ չկիսել փորձը բոլորի հետ:
DevOps կոնստրուկտորի ստեղծում
Agile-ն ունի իր սեփական մանիֆեստը: ITIL-ն ունի իր մեթոդաբանությունը. DevOps-ն ավելի քիչ բախտավոր է. այն դեռ չի ձեռք բերել կաղապարներ և ստանդարտներ: Չնայած նրան որոշել ընկերությունների հասունությունը՝ հիմնվելով դրանց զարգացման և գործառնական պրակտիկայի գնահատման վրա:
Բարեբախտաբար, Gartner հայտնի ընկերությունը 2014թ և վերլուծեց DevOps-ի հիմնական պրակտիկան և նրանց միջև փոխհարաբերությունները: Դրա հիման վրա ես հրապարակեցի ինֆոգրաֆիկա.
Մենք դա հիմք ենք ընդունել մեր համար . Չորս ոլորտներից յուրաքանչյուրն ունի մի շարք գործիքներ. մենք դրանք հավաքեցինք տվյալների շտեմարանում, բացահայտեցինք ամենահայտնիները, բացահայտեցինք ինտեգրման կետերը և օպտիմալացման հարմար մեխանիզմները: Ընդհանուր առմամբ պարզվեց 36 պրակտիկա և 115 գործիք, որոնց մեկ քառորդը բաց կոդով կամ անվճար ծրագրեր են։ Հաջորդիվ, մենք կխոսենք այն մասին, թե ինչի ենք հասել յուրաքանչյուր ոլորտում և, որպես օրինակ, այն մասին, թե ինչպես է դա իրականացվել տեխնիկական փաստաթղթերի կառավարում ստեղծելու նախագծում, որով մենք սկսել ենք գրառումը:
Գործընթացները
Տխրահռչակ EDMS նախագծում տեխնիկական փաստաթղթերի կառավարման համակարգը տեղակայվել է նույն սխեմայով 10 օբյեկտներից յուրաքանչյուրում: Տեղադրումը ներառում է 4 սերվեր՝ տվյալների բազայի սերվեր, հավելվածի սերվեր, ամբողջական տեքստի ինդեքսավորում և բովանդակության կառավարում։ Տեղադրման ժամանակ նրանք գործում են մեկ հանգույցի մեջ և տեղակայված են օբյեկտների տվյալների կենտրոնում: Բոլոր օբյեկտները մի փոքր տարբերվում են ենթակառուցվածքով, բայց դա չի խանգարում գլոբալ փոխազդեցությանը:
Նախ, DevOps-ի պրակտիկայի համաձայն, մենք ավտոմատացրինք ենթակառուցվածքը տեղական մակարդակում, այնուհետև առաքումը բերեցինք փորձարկման միացում, այնուհետև հաճախորդի արտադրանք: Յուրաքանչյուր գործընթաց մշակվել է քայլ առ քայլ: Շրջակա միջավայրի կարգավորումները ամրագրված են սկզբնական կոդի համակարգում՝ հաշվի առնելով, թե որ բաշխման փաթեթը կազմված է ավտոմատ թարմացման համար: Կազմաձևման փոփոխությունների դեպքում ինժեներները պարզապես պետք է համապատասխան փոփոխություններ կատարեն տարբերակների կառավարման համակարգում, և այնուհետև ավտոմատ թարմացումը տեղի կունենա առանց խնդիրների:
Այս մոտեցման շնորհիվ թեստավորման գործընթացը զգալիորեն պարզեցվել է։ Նախկինում նախագիծն ուներ փորձարկողներ, որոնք ոչինչ չէին անում, բացի ձեռքով թարմացնելու ստենդները: Հիմա ուղղակի գալիս են, տեսնում են, որ ամեն ինչ աշխատում է ու ավելի օգտակար բաներ են անում։ Յուրաքանչյուր թարմացում փորձարկվում է ավտոմատ կերպով՝ մակերեսային մակարդակից մինչև բիզնես սցենարի ավտոմատացում: Արդյունքները տեղադրվում են որպես առանձին հաշվետվություններ TestRail-ում:
Культура
Շարունակական փորձարկումը լավագույնս բացատրվում է թեստի դիզայնի օրինակով: Դեռևս գոյություն չունեցող համակարգի փորձարկումը ստեղծագործ աշխատանք է: Թեստի պլան գրելիս պետք է հասկանալ, թե ինչպես ճիշտ փորձարկել և որ ճյուղերին հետևել: Եվ նաև գտեք հավասարակշռություն ժամանակի և բյուջեի միջև՝ ստուգումների օպտիմալ քանակը որոշելու համար: Կարևոր է ընտրել հենց անհրաժեշտ թեստերը, մտածել, թե ինչպես է օգտատերը համագործակցելու համակարգի հետ, հաշվի առնել շրջակա միջավայրը և հնարավոր արտաքին գործոնները։ Անհնար է անել առանց շարունակական փորձերի։
Հիմա փոխազդեցության մշակույթի մասին։ Նախկինում կային երկու հակադիր կողմեր՝ ինժեներներ և մշակողներ: Մշակողները ասացին. «Մեզ չի հետաքրքրում, թե ինչպես է այն գործարկվելու։ Դուք ինժեներ եք, դուք խելացի եք, համոզվեք, որ այն աշխատի առանց ձախողումների». Ինժեներները պատասխանեցին. «Դուք մշակողներ չափազանց անփույթ եք։ Եկեք ավելի զգույշ լինենք, և մենք ավելի քիչ կխաղարկենք ձեր թողարկումները: Որովհետև ամեն անգամ, երբ դուք մեզ արտահոսող ծածկագիր եք տալիս, մեզ համար պարզ չէ, թե ինչպես փոխազդել»:. Սա մշակութային փոխգործակցության խնդիր է, որը տարբեր կերպ է կառուցված DevOps-ի տեսանկյունից: Այստեղ և՛ ինժեներները, և՛ մշակողները մեկ թիմի մասն են կազմում, որը կենտրոնացած է անընդհատ փոփոխվող, բայց միևնույն ժամանակ հուսալի ծրագրաշարի վրա:
Նույն թիմի շրջանակներում մասնագետները վճռական են միմյանց օգնելու հարցում: Ինչպես նախկինում էր? Օրինակ՝ պատրաստվում էին տեղակայման մի քանի հաստ հրահանգներ՝ մոտ 50 էջ: Ինժեները կարդաց այն, ինչ-որ բան չհասկացավ, հայհոյեց և խնդրեց մշակողին առավոտյան ժամը երեքին մեկնաբանել: Մշակողը մեկնաբանեց և նաև հայհոյեց՝ ի վերջո ոչ ոք ուրախացավ։ Բացի այդ, բնականաբար, եղել են որոշ սխալներ, քանի որ դուք չեք կարող հիշել ամեն ինչ հրահանգների մեջ: Եվ հիմա ինժեները, մշակողի հետ միասին, գրում է կիրառական ծրագրային ենթակառուցվածքի ավտոմատացված տեղակայման սցենար: Եվ նրանք միմյանց հետ խոսում են գործնականում նույն լեզվով։
Մարդիկ
Թիմի չափը որոշվում է թարմացման շրջանակով: Թիմը հավաքագրվում է առաքման ձևավորման ընթացքում, այն ներառում է ծրագրի ընդհանուր թիմից հետաքրքրված անձինք: Այնուհետև յուրաքանչյուր փուլի համար պատասխանատուների հետ գրվում է թարմացման պլան, և թիմը զեկուցում է այն առաջընթացի ընթացքում: Թիմի բոլոր անդամները փոխարինելի են: Որպես թիմի մաս՝ մենք ունենք նաև պահեստային ծրագրավորող, բայց նա գրեթե երբեք ստիպված չի լինում միանալ:
Տեխնոլոգիա
Տեխնոլոգիական գծապատկերում ընդգծված են մի քանի կետեր, բայց դրանց տակ կան մի շարք տեխնոլոգիաներ. դուք կարող եք տպագրել մի ամբողջ գիրք իրենց նկարագրություններով: Այսպիսով, մենք կառանձնացնենք ամենահետաքրքիրը:
Ենթակառուցվածքները `որպես ծածկագիր
Հիմա, հավանաբար, այս հայեցակարգը ոչ ոքի չի զարմացնի, բայց նախկինում ենթակառուցվածքների նկարագրությունները շատ բան էին թողնում: , փորձարկման միջավայրերը եզակի էին, դրանք փայփայված ու փայփայված էին, փոշու մասնիկները փչում էին դրանցից։
Մեր օրերում ոչ ոք չի վախենում փորձարկումներից։ Կան վիրտուալ մեքենաների հիմնական պատկերներ, կան պատրաստի սցենարներ միջավայրերի տեղակայման համար: Բոլոր ձևանմուշները և սցենարները պահվում են տարբերակների կառավարման համակարգում և անմիջապես թարմացվում են: Նախկինում, երբ անհրաժեշտ էր փաթեթը հանձնել ստենդին, առաջացավ կոնֆիգուրացիայի բացը: Այժմ դուք պարզապես պետք է տող ավելացնեք աղբյուրի կոդը:
Ի լրումն ենթակառուցվածքի սկրիպտների և խողովակաշարերի, Փաստաթղթավորումը որպես օրենսգրքի մոտեցումը նույնպես օգտագործվում է փաստաթղթավորման համար: Դրա շնորհիվ հեշտ է նոր մարդկանց միացնել նախագծին, ծանոթացնել համակարգին՝ հիմնվելով նկարագրված գործառույթների վրա, օրինակ՝ թեստային պլանում, ինչպես նաև վերօգտագործել թեստային դեպքերը:
Շարունակական առաքում և մոնիտորինգ
DevOps-ի մասին մենք խոսեցինք այն մասին, թե ինչպես ենք ընտրել գործիքներ շարունակական առաքման և մոնիտորինգի իրականացման համար: Հաճախ որևէ բան վերաշարադրելու կարիք չկա. բավական է օգտագործել նախկինում գրված սցենարներ, ճիշտ կառուցել բաղադրիչների միջև ինտեգրումը և ստեղծել ընդհանուր կառավարման վահանակ: Եվ բոլոր գործընթացները կարող են գործարկվել մեկ կոճակի կամ ժամանակացույցի միջոցով:
Անգլերենում կան տարբեր հասկացություններ՝ Continuous Delivery և Continuous Deployment: Երկուսն էլ կարող են թարգմանվել որպես «շարունակական առաքում», բայց իրականում նրանց միջև մի փոքր տարբերություն կա: Բաշխված էներգետիկ ընկերության տեխնիկական փաստաթղթերի հոսքի մեր նախագծում, ավելի շուտ, օգտագործվում է Առաքում, երբ արտադրության համար տեղադրումը տեղի է ունենում հրամանով: Deployment-ում տեղադրումը տեղի է ունենում ավտոմատ կերպով: Այս նախագծում շարունակական առաքումը հիմնականում դարձել է DevOps-ի կենտրոնական մասը.
Ընդհանուր առմամբ, որոշակի պարամետրեր հավաքելով, դուք կարող եք հստակ հասկանալ, թե ինչու են DevOps պրակտիկաները օգտակար: Եվ սա փոխանցեք ղեկավարությանը, ով իսկապես թվեր է սիրում։ Գործարկումների ընդհանուր թիվը, սցենարի փուլերի կատարման ժամանակը, հաջող մեկնարկների մասնաբաժինը. այս ամենն ուղղակիորեն ազդում է շուկայ դուրս գալու բոլորի սիրած ժամանակի վրա, այսինքն՝ commit-ից մինչև տարբերակի կառավարման համակարգից մինչև տարբերակի թողարկումը: արտադրական միջավայր. Անհրաժեշտ գործիքների ներդրմամբ ինժեներները փոստով ստանում են արժեքավոր ցուցանիշներ, և ծրագրի ղեկավարը դրանք տեսնում է վահանակի վրա: Այս կերպ Դուք կարող եք անմիջապես գնահատել նոր գործիքների առավելությունները: Եվ դուք կարող եք դրանք փորձել ձեր ենթակառուցվածքում՝ օգտագործելով DevOps դիզայները:
Ո՞ւմ պետք կգա մեր ?
Եկեք չձևացնենք. սկզբի համար նա մեզ օգտակար դարձավ։ Ինչպես արդեն ասել ենք, դուք պետք է խոսեք նույն լեզվով հաճախորդի հետ, և DevOps դիզայների օգնությամբ մենք կարող ենք արագ ուրվագծել նման խոսակցության հիմքը: Բիզնեսի մասնագետները կկարողանան ինքնուրույն գնահատել, թե ինչ է իրենց անհրաժեշտ և այդպիսով ավելի արագ զարգանալ։ Մենք փորձել ենք դիզայներին դարձնել հնարավորինս մանրամասն՝ ավելացնելով մի շարք նկարագրություններ, որպեսզի ցանկացած օգտատեր հասկանա, թե ինչ է ընտրում։
Դիզայների ձևաչափը թույլ է տալիս հաշվի առնել ընկերության առկա զարգացումները շինարարական գործընթացների և ավտոմատացման ոլորտում: Կարիք չկա ամեն ինչ քանդել և վերակառուցել այն, եթե դուք կարող եք ընտրել միայն լուծումներ, որոնք լավ ինտեգրվում են առկա գործընթացներին և կարող են պարզապես լրացնել բացերը:
Միգուցե ձեր զարգացումն արդեն տեղափոխվել է ավելի բարձր մակարդակ, և մեր գործիքը չափազանց «կապիտանական» կթվա: Բայց մենք գտնում ենք, որ այն օգտակար է մեզ համար և հուսով ենք, որ այն օգտակար կլինի ընթերցողներից ոմանց: Հիշեցնում ենք դիզայներին. եթե որևէ բան կա, դուք ստանում եք դիագրամը նախնական տվյալները մուտքագրելուց անմիջապես հետո: Մենք երախտապարտ կլինենք ձեր արձագանքների և լրացումների համար:
Source: www.habr.com