Ենթակառուցվածքը որպես կոդ. ինչպես հաղթահարել խնդիրները XP-ի միջոցով

Բարև, Հաբր։ Նախկինում ես բողոքում էի ենթակառուցվածքներում կյանքից՝ որպես կոդի մոդելի, և ոչինչ չէի առաջարկում ստեղծված իրավիճակը լուծելու համար։ Այսօր ես վերադարձել եմ ձեզ պատմելու, թե ինչ մոտեցումներ և գործելակերպեր կօգնեն ձեզ դուրս գալ հուսահատության անդունդից և իրավիճակը ճիշտ ուղղությամբ տանել։

Մի նախորդ հոդվածում «Ենթակառուցվածքը որպես ծածկագիր. առաջին ծանոթություն» Ես կիսվեցի այս ոլորտի վերաբերյալ իմ տպավորություններով, փորձեցի խորհրդածել այս ոլորտում առկա իրավիճակի մասին և նույնիսկ առաջարկեցի, որ բոլոր մշակողներին հայտնի ստանդարտ գործելակերպը կարող է օգնել։ Կարող է թվալ, թե կյանքի վերաբերյալ շատ բողոքներ կային, բայց ստեղծված իրավիճակից դուրս գալու որևէ առաջարկ չկար։

Ովքե՞ր ենք մենք, որտեղ ենք և ինչ խնդիրներ ունենք

Ներկայումս մենք գտնվում ենք Sre Onboarding Team-ում, որը բաղկացած է վեց ծրագրավորողներից և երեք ենթակառուցվածքի ինժեներից: Մենք բոլորս փորձում ենք Ենթակառուցվածքը գրել որպես կոդ (IaC): Մենք դա անում ենք, քանի որ գիտենք ինչպես գրել կոդ և ունենք «միջինից բարձր» մակարդակի ծրագրավորողների պատմություն:

• Մենք ունենք մի շարք առավելություններ՝ որոշակի նախապատմություն, պրակտիկաների իմացություն, կոդ գրելու կարողություն և նոր բաներ սովորելու ցանկություն:
• Եվ կա մի մաս, որը նույնպես մինուս է՝ ենթակառուցվածքային նյութի մասին իմացության պակասը։

Տեխնոլոգիական փաթեթը, որը մենք օգտագործում ենք մեր IaC-ում:

• Terraform ռեսուրսներ ստեղծելու համար:
• Փաքեր՝ պատկերներ հավաքելու համար։ Սա է Windows, CentOS 7 պատկեր։
• Jsonnet-ը՝ drone.io-ում հզոր կառուցվածքներ ստեղծելու, ինչպես նաև packer json և մեր terraform մոդուլները ստեղծելու համար։
• Լազուր
• Հասանելի է պատկերներ պատրաստելիս:
• Python օգնական ծառայությունների և սկրիպտների տրամադրման համար:
• Եվ այս ամենը VSCode-ում՝ թիմի անդամների միջև համատեղ օգտագործվող պլագիններով։

Եզրակացություն իմ վերջին հոդվածը Ես փորձեցի (առաջին հերթին իմ մեջ) լավատեսություն սերմանել, ուզում էի ասել, որ փորձելու ենք մեզ հայտնի մոտեցումներն ու գործելակերպը, որպեսզի պայքարենք այս ոլորտում առկա դժվարությունների և բարդությունների դեմ։

Մենք ներկայումս պայքարում ենք IaC-ի հետևյալ խնդիրների հետ.

• Կոդի մշակման գործիքների և միջոցների անկատարություն.
• Դանդաղ տեղակայում։ Ենթակառուցվածքները իրական աշխարհի մի մասն են, և իրական աշխարհը կարող է դանդաղ լինել։
• Մոտեցումների և պրակտիկայի բացակայություն.
• Մենք նորեկ ենք և շատ բան չգիտենք։

Ծայրահեղ ծրագրավորում (XP) փրկելու համար

Բոլոր մշակողները ծանոթ են էքստրեմալ ծրագրավորմանը (XP) և դրա հիմքում ընկած գործելակերպին: Մեզանից շատերն աշխատել են այս մոտեցմամբ, և այն հաջողվել է: Այսպիսով, ինչո՞ւ չօգտագործել այնտեղ դրված սկզբունքներն ու գործելակերպը՝ ենթակառուցվածքային մարտահրավերները հաղթահարելու համար: Մենք որոշեցինք այս մոտեցումն ընդունել և տեսնել, թե ինչ կլինի:

XP-ի մոտեցման կիրառելիության փորձարկում ձեր արդյունաբերության համարԱհա այն միջավայրի նկարագրությունը, որին հարմար է XP-ն և ինչպես է այն կապված մեզ հետ.

1. Դինամիկորեն փոփոխվող ծրագրային պահանջներ։ Մենք հստակ էինք վերջնական նպատակի հարցում։ Բայց մանրամասները կարող են տարբեր լինել։ Մենք ինքներս ենք որոշում, թե որտեղ պետք է գնանք, ուստի պահանջները պարբերաբար փոխվում են (հիմնականում մենք ենք դա անում): Եթե ​​վերցնենք SRE թիմ, որն ինքն է զբաղվում ավտոմատացմամբ և սահմանափակում է աշխատանքի պահանջներն ու շրջանակը, ապա այս կետը լավ է համապատասխանում։

2. Նոր տեխնոլոգիաների կիրառմամբ ֆիքսված ժամանակի նախագծերի հետևանքով առաջացած ռիսկերը: Մենք կարող ենք վտանգների առաջ կանգնել, երբ օգտագործում ենք մեզ անծանոթ բաներ: Եվ սա 100%-ով մեր դեպքն է։ Մեր ամբողջ նախագիծը վերաբերում է տեխնոլոգիաների օգտագործմանը, որոնց մենք լիովին ծանոթ չէինք: Ընդհանրապես, սա մշտական ​​խնդիր է, քանի որ ենթակառուցվածքի ոլորտում մշտապես ի հայտ են գալիս բազմաթիվ նոր տեխնոլոգիաներ։

3,4. Փոքր, համատեղ տեղակայված ընդլայնված զարգացման թիմ: Ձեր օգտագործած ավտոմատացված տեխնոլոգիան թույլ է տալիս միավորի և ֆունկցիոնալ թեստեր: Այս երկու կետերը մեզ այնքան էլ չեն համապատասխանում։ Նախ՝ մենք համախմբված թիմ չենք, երկրորդ՝ ինը հոգի ենք, որոնց կարելի է մեծ թիմ համարել։ Թեև, ըստ «մեծ» թիմի մի շարք սահմանումների, շատ բան 14+ մարդ է:

Դիտարկենք XP-ի որոշ պրակտիկաներ և ինչպես են դրանք ազդում հետադարձ կապի արագության և որակի վրա:

Հետադարձ կապի սկզբունքը XP-ում

Իմ ընկալմամբ՝ հետադարձ կապը հարցի պատասխանն է՝ ճի՞շտ եմ անում, ճի՞շտ ուղղությամբ ենք գնում։ XP-ն դրա համար ունի աստվածային սխեման՝ ժամանակի հետադարձ կապի օղակ: Հետաքրքիրն այն է, որ ինչքան ցածր լինենք, այնքան արագ հնարավորություն կունենանք ստանալ OS անհրաժեշտ հարցերին պատասխանելու համար։

Բավականին հետաքրքիր քննարկման թեմա է, որ մեր ՏՏ ոլորտում հնարավոր է արագ ՕՀ ձեռք բերել։ Պատկերացրեք, թե որքան ցավալի է վեց ամիս նախագիծ անելը և միայն դրանից հետո պարզել, որ հենց սկզբում սխալ է եղել։ Դա տեղի է ունենում նախագծման և բարդ համակարգերի ցանկացած կառուցման մեջ:

Մեր դեպքում IaC-ն օգնում է մեզ հետադարձ կապի հարցում։ Ես անմիջապես մի փոքր ճշգրտում կանեմ վերևում նշված դիագրամում. թողարկման պլանը ամսական ցիկլ չունի, բայց տեղի է ունենում օրական մի քանի անգամ։ Այս OS ցիկլի հետ կապված կան որոշ գործելակերպեր, որոնք մենք ավելի մանրամասն կքննարկենք։

Կարևոր է. Հետադարձ կապը կարող է լուծում լինել վերը նշված բոլոր խնդիրների համար։ XP պրակտիկաների հետ համատեղ, այն կարող է ձեզ դուրս բերել հուսահատության անդունդից։

Ինչպես դուրս գալ հուսահատության անդունդից. երեք պրակտիկա

Թեստեր

Թեստերը XP-ի հետադարձ կապի ցիկլում երկու անգամ են հիշատակվում։ Դա պարզապես այդպես չէ։ Դրանք չափազանց կարևոր են ամբողջ էքստրեմալ ծրագրավորման տեխնիկայի համար։

Ենթադրվում է, որ դուք ունեք Unit և Acceptance թեստեր: Ոմանք ձեզ հետադարձ կապ են տալիս որոշակի րոպեների ընթացքում, մյուսները՝ որոշակի թվով օրերի ընթացքում, այնպես որ դրանք գրելու համար ավելի երկար է տևում և ավելի քիչ են գործարկվում:

Կա դասական փորձարկման բուրգ, որը ցույց է տալիս, որ որոշ թեստեր պետք է ավելի շատ լինեն:

Ինչպե՞ս է այս սխեման կիրառվում մեզ վրա IaC նախագծում: Փաստորեն... ոչինչ։

• Միավոր թեստերը, թեև դրանք պետք է շատ լինեն, չեն կարող շատ լինել: Կամ շատ անուղղակի ինչ-որ բան են փորձարկում։ Փաստորեն, կարելի է ասել, որ դրանք ընդհանրապես չենք գրում։ Բայց ահա այսպիսի թեստերի մի քանի հավելվածներ, որոնք մենք կարողացանք անել.
  1. Թեստավորման կոդը jsonnet-ում: Սա, օրինակ, մեր անօդաչու սարքի խողովակաշարն է, որը բավականին բարդ է։ jsonnet-ի կոդը լավ ծածկված է թեստերով:
     Մենք օգտագործում ենք սա Միավորի փորձարկման շրջանակ Jsonnet-ի համար.
  2. Ստուգումներ սկրիպտների համար, որոնք կատարվում են ռեսուրսի մեկնարկի ժամանակ: Սկրիպտները Python-ում են, ինչը նշանակում է, որ դուք կարող եք թեստեր գրել դրանց վրա:
• Հնարավոր է ստուգել կոնֆիգուրացիան թեստերում, բայց մենք դա չենք անում: Հնարավորություն կա նաև ռեսուրսների կազմաձևման կանոնների ստուգման միջոցով կայծքար. Այնուամենայնիվ, Terraform-ի համար չափազանց տարրական ստուգումներ կան, բայց շատ թեստային սցենարներ գրված են AWS-ի համար: Եվ մենք Azure-ի վրա ենք, այնպես որ դա նորից չի աշխատում:
• Բաղադրիչների ինտեգրման թեստեր. դա կախված է նրանից, թե ինչպես եք դրանք դասակարգում և որտեղ եք դրանք տեղադրում: Բայց սկզբունքորեն նրանք աշխատում են։

  Ահա թե ինչ տեսք ունեն ինտեգրացիոն թեստերը.

  
  
  Սա օրինակ է Drone CI-ում պատկերներ կառուցելիս։ Դրանց հասնելու համար պետք է սպասել 30 րոպե, մինչև Փաքերի պատկերը հավաքվի, ապա ևս 15 րոպե սպասել, մինչև դրանք անցնեն։ Բայց նրանք գոյություն ունեն!

  Պատկերի ստուգման ալգորիթմ

  1. Նախ, Փաքերը պետք է ամբողջությամբ պատրաստի պատկերը:
  2. Փորձարկման կողքին կա տերրաֆորմ՝ տեղական վիճակով, որը մենք օգտագործում ենք այս պատկերը տեղակայելու համար:
  3. Երբ բացվում է, մոտակայքում ընկած փոքրիկ մոդուլն օգտագործվում է պատկերի հետ աշխատելը հեշտացնելու համար:
  4. Հենց որ պատկերից VM-ը տեղադրվի, կարող եք սկսել փորձարկումը: Հիմնականում ստուգումները կատարվում են ավտոմեքենայով։ Այն ստուգում է, թե ինչպես են սցենարներն աշխատել գործարկման ժամանակ և ինչպես են աշխատում դևերը: Դա անելու համար մենք մուտք ենք գործում նոր գործարկված մեքենա ssh-ի կամ winrm-ի միջոցով և ստուգում ենք կազմաձևման կարգավիճակը, թե արդյոք ծառայությունները գործարկվել են:

• Իրավիճակը նման է ինտեգրման թեստերի և տերրաֆորմի մոդուլների հետ: Ահա մի կարճ աղյուսակ, որը բացատրում է նման թեստերի առանձնահատկությունները:

  
  
  Խողովակաշարի վերաբերյալ կարծիքը տևում է մոտ 40 րոպե: Ամեն ինչ տեղի է ունենում շատ երկար ժամանակ: Այն կարող է օգտագործվել ռեգրեսիայի համար, բայց նոր զարգացման համար դա լիովին անիրատեսական է։ Եթե ​​դուք պատրաստվում եք դրան շատ, շատ լավ, պատրաստում եք վազքը, սցենարները, ապա կարող եք կրճատել այն մինչև 10 րոպե: Բայց սրանք դեռ Unit թեստեր չեն, որոնք 5 են 100 վայրկյանում:

Terraform պատկերներ կամ մոդուլներ հավաքելիս Unit-ի թեստերի բացակայությունը խրախուսում է աշխատանքը տեղափոխել առանձին ծառայություններ, որոնք կարելի է հեշտությամբ տեղափոխել REST-ի միջոցով կամ Python սկրիպտներին:

Օրինակ, մեզ պետք էր այնպես անել, որ երբ վիրտուալ մեքենան գործարկվի, ինքն իրեն գրանցի ծառայությունում ScaleFT, և երբ վիրտուալ մեքենան ոչնչացվեց, այն ինքն իրեն ջնջեց։

Քանի որ ScaleFT-ը մեզ համար ծառայություն է, մենք պետք է աշխատենք դրա հետ API-ի միջոցով: Այնտեղ գրված էր մի փաթաթան, որը կարող ես քաշել ու ասել. Այն պահպանում է բոլոր անհրաժեշտ կարգավորումները և մուտքերը:

Մենք արդեն կարող ենք նորմալ թեստեր գրել դրա համար, քանի որ այն ոչնչով չի տարբերվում սովորական ծրագրաշարից. որոշ API փորձարկվում է, դուք քաշեք այն, և մենք տեսնում ենք, թե ինչ է տեղի ունենում:

Փորձարկման արդյունքներ. միավորի թեստավորումը, որը պետք է տա ​​OS-ն մեկ րոպեի ընթացքում, չի անում: Իսկ բուրգից բարձր փորձարկման տեսակներն արդյունավետ են, բայց միայն ծածկում են խնդիրների մի մասը։

Զույգերի ծրագրավորում

Թեստերը, իհարկե, լավն են: Դրանցից կարելի է շատ գրել, դրանք կարող են լինել տարբեր տեսակի: Նրանք կաշխատեն իրենց մակարդակներում և մեզ հետադարձ կապ կտան: Սակայն Unit-ի վատ թեստերի հետ կապված խնդիրը, որը տալիս է ամենաարագ ՕՀ-ն, մնում է: Միևնույն ժամանակ, ես դեռ ցանկանում եմ արագ OS, որի հետ հեշտ և հաճելի է աշխատել: Էլ չենք խոսում ստացված լուծույթի որակի մասին։ Բարեբախտաբար, կան տեխնիկա, որոնք թույլ են տալիս նույնիսկ ավելի արագ արձագանքել, քան միավորի թեստերը: Սա զույգ ծրագրավորում է:

Կոդ գրելիս ցանկանում եք հնարավորինս արագ արձագանք ստանալ դրա որակի վերաբերյալ: Այո, դուք կարող եք գրել ամեն ինչ ֆունկցիոնալ ճյուղում (որպեսզի որևէ մեկի համար որևէ բան չկոտրվի), GitHub-ում pull-ի հարցում անել, վերագրել այն մեկին, ում կարծիքը կշիռ ունի և սպասել պատասխանի։

Բայց դուք կարող եք երկար սպասել: Մարդիկ բոլորն էլ զբաղված են, և եթե նույնիսկ պատասխան լինի, այն կարող է ամենաբարձր որակի չլինել։ Ենթադրենք, պատասխանն անմիջապես եկավ, գրախոսն անմիջապես հասկացավ ամբողջ միտքը, բայց պատասխանը դեռ ուշ է գալիս՝ փաստից հետո։ Բայց ես ավելի վաղ եմ ուզում: Ահա թե ինչին է ուղղված զույգ ծրագրավորումը՝ դա անել անմիջապես, գրելու պահին:

Ստորև բերված են մի քանի զույգ ծրագրավորման ոճեր և ինչպես են դրանք կիրառվում IaC աշխատանքի համար.

1. Դասական, Փորձառու+փորձառու, ժմչփի հերթափոխ։ Երկու դեր՝ վարորդ և նավիգատոր: Երկու հոգի. Նրանք աշխատում են նույն կոդի վրա և որոշակի նախապես որոշված ​​ժամանակահատվածից հետո փոխում են դերերը:

Դիտարկենք մեր խնդիրների համատեղելիությունը ոճի հետ.

• Խնդիր. կոդի մշակման գործիքների և միջոցների անկատարություն:
  Բացասական ազդեցություն՝ զարգանալու համար ավելի երկար ժամանակ է պահանջվում, մենք դանդաղում ենք, աշխատանքի տեմպը/ռիթմը խաթարվում է։
  Ինչպես ենք մենք պայքարում. մենք օգտագործում ենք այլ գործիքակազմ, ընդհանուր IDE, ինչպես նաև սովորում ենք դյուրանցումներ:
• Խնդիր. Դանդաղ տեղակայում:
  Բացասական ազդեցություն. մեծացնում է աշխատանքային կոդ ստեղծելու համար անհրաժեշտ ժամանակը: Մենք ձանձրանում ենք, մինչ սպասում ենք, մեր ձեռքերը մեկնում են այլ բան անելու, մինչ սպասում ենք:
  Ինչպես ենք մենք պայքարում. մենք դա չենք հաղթահարել.
• Խնդիր՝ մոտեցումների և պրակտիկայի բացակայություն:
  Բացասական ազդեցություն. չկա իմացություն, թե ինչ անել լավ, ինչը վատ: Երկարացնում է արձագանք ստանալու համար անհրաժեշտ ժամանակը:
  Ինչպես ենք մենք պայքարում. զույգ աշխատանքի ընթացքում կարծիքների և փորձի փոխանակումը գրեթե լուծում է խնդիրը:

IaC-ում այս ոճի օգտագործման հիմնական խնդիրը աշխատանքի անհավասար տեմպն է: Ավանդական ծրագրային ապահովման մշակման մեջ դուք շատ կայուն հոսք ունեք: Դուք կարող եք հինգ րոպե հատկացնել և գրել N: Ծախսել 10 րոպե և գրել 2N, 15 րոպե՝ 3N: Այստեղ կարող ես հինգ րոպե ծախսել և գրել N, իսկ հետո ծախսել ևս 30 րոպե և գրել N-ի տասներորդը: Այստեղ դու ոչինչ չգիտես, դու խրված ես, դու հիմար ես: Վրիպազերծումը ժամանակ է պահանջում և շեղում է բուն ծրագրավորումից:

Եզրակացություն՝ իր մաքուր տեսքով այն մեզ հարմար չէ։

2. Պինգ-պոնգ. Այս մոտեցումը ներառում է մի մասնակից գրում է թեստ, իսկ մյուսն իրականացնում է այն: Հաշվի առնելով, որ Unit-ի թեստերը բարդ են, և դուք պետք է գրեք ժամանակատար ինտեգրման թեստ, պինգ-պոնգի բոլոր հեշտությունը վերանում է:

Կարող եմ ասել, որ փորձեցինք տարանջատել թեստային սցենարի նախագծման և դրա ծածկագրի ներդրման պարտականությունները։ Մի մասնակից հանդես եկավ սցենարով, նա էր պատասխանատու աշխատանքի այս հատվածի համար, վերջին խոսքն ինքն էր ասում։ Իսկ մյուսը պատասխանատու էր իրականացման համար։ Լավ ստացվեց։ Այս մոտեցմամբ սցենարի որակը բարձրանում է։

Եզրակացություն. ցավոք սրտի, աշխատանքի տեմպը թույլ չի տալիս օգտագործել պինգ-պոնգը որպես IaC-ում զույգ ծրագրավորման պրակտիկա:

3. Ուժեղ ոճ. Բարդ պրակտիկա. Գաղափարն այն է, որ մասնակիցներից մեկը դառնում է դիրեկտիվների նավիգատոր, իսկ մյուսը ստանձնում է կատարող վարորդի դերը: Այս դեպքում որոշումներ կայացնելու իրավունքը պատկանում է բացառապես նավիգատորին: Վարորդը միայն տպում է և կարող է ազդել այն ամենի վրա, ինչ կատարվում է բառով: Դերերը երկար ժամանակ չեն փոխվում։

Հարմար է սովորելու համար, բայց պահանջում է ուժեղ փափուկ հմտություններ: Ահա թե որտեղ ենք խրվել։ Տեխնոլոգիան դժվար էր. Եվ դա նույնիսկ ենթակառուցվածքի մասին չէ:

Եզրակացություն. այն հնարավոր է օգտագործել, մենք չենք հրաժարվում փորձերից:

4. Mobbing, swarming և բոլոր հայտնի, բայց այստեղ նշված ոճերը մենք դա չենք համարում, քանի որ չենք փորձել և չենք կարող դրա մասին որևէ բան ասել մեր աշխատանքի համատեքստում։

Ընդհանուր եզրակացություններ զույգ ծրագրավորման օգտագործման վերաբերյալ.

• Մենք ունենք աշխատանքի անհավասար տեմպ, որը ապակողմնորոշիչ է։
• Մենք խրված ենք անբավարար փափուկ հմտություններով: Իսկ առարկայական ոլորտը չի օգնում հաղթահարել մեր այս թերությունները։
• Երկար փորձարկումները և գործիքների հետ կապված խնդիրները կպչուն են դարձնում զույգերի զարգացումը:

5. Չնայած դրան, եղել են նաև հաջողություններ. Մենք ստեղծեցինք մեր սեփական մեթոդը՝ «Կոնվերգենցիա – շեղում»: Ես հակիրճ նկարագրեմ, թե ինչպես է այն աշխատում:

Մենք ունենք մշտական ​​գործընկերներ մի քանի օրով (մեկ շաբաթից պակաս): Մենք միասին կատարում ենք մեկ առաջադրանք. Մենք մի քիչ նստում ենք միասին՝ մեկը գրում է, մյուսը նստում և հետևում է աջակցող թիմին։ Հետո մենք մի պահ առանձնանում ենք՝ յուրաքանչյուրը ինքնուրույն ինչ-որ բաներ անելով, հետո նորից հավաքվում ենք, շատ արագ սինխրոնիզացվում, միասին ինչ-որ բան անում ու նորից բաժանվում։

Պլանավորում և հաղորդակցություն

Պրակտիկայի վերջին բլոկը, որի միջոցով լուծվում են ՕՀ-ի խնդիրները, հենց առաջադրանքների հետ աշխատանքի կազմակերպումն է: Սա ներառում է նաև փորձի փոխանակում, որը դուրս է զույգ աշխատանքից: Դիտարկենք երեք պրակտիկա.

1. Առաջադրանքներ նպատակի ծառի միջոցով: Մենք կազմակերպեցինք ծրագրի ընդհանուր կառավարումը մի ծառի միջոցով, որն անսահմանորեն տարածվում է դեպի ապագա: Տեխնիկապես կառավարումը կատարվում է Միրոյում։ Կա մեկ խնդիր՝ դա միջանկյալ նպատակ է։ Դրանից բխում են կամ ավելի փոքր նպատակներ կամ առաջադրանքների խմբեր: Առաջադրանքներն իրենք իրենց վրա են: Բոլոր առաջադրանքները ստեղծվում և կառավարվում են այս տախտակում:

Այս սխեման տրամադրում է նաև հետադարձ կապ, որը տեղի է ունենում օրը մեկ անգամ, երբ մենք համաժամանակացնում ենք հանդիպումներին: Բոլորի առջև ընդհանուր պլան ունենալը, սակայն կառուցվածքային և ամբողջովին բաց, թույլ է տալիս բոլորին տեղյակ լինել, թե ինչ է կատարվում և որքան հեռու ենք մենք առաջընթացի առումով:

Առաջադրանքների տեսողական տեսողության առավելությունները.

• Պատճառականություն. Յուրաքանչյուր առաջադրանք տանում է դեպի ինչ-որ գլոբալ նպատակ: Առաջադրանքները խմբավորված են ավելի փոքր նպատակներով: Ենթակառուցվածքի տիրույթն ինքնին բավականին տեխնիկական է: Միշտ չէ, որ անմիջապես պարզ է, թե կոնկրետ ինչ ազդեցություն է ունենում բիզնեսի վրա, օրինակ, մեկ այլ nginx միգրացիայի վերաբերյալ գրքույկ գրելը: Թիրախային քարտը մոտակայքում ունենալը դա ավելի պարզ է դարձնում:
  
  Պատճառականությունը խնդիրների կարևոր հատկությունն է: Այն ուղղակիորեն պատասխանում է հարցին. «Արդյո՞ք ես ճի՞շտ բան եմ անում»:
• Զուգահեռություն. Մենք ինը հոգի ենք, և ֆիզիկապես անհնար է, որ բոլորը հարձակվեն մեկ առաջադրանքի վրա: Մի ոլորտի առաջադրանքները կարող են ոչ միշտ լինել բավարար: Մենք ստիպված ենք զուգահեռաբար զուգահեռել փոքր աշխատանքային խմբերի աշխատանքը։ Միևնույն ժամանակ խմբերը որոշ ժամանակ նստում են իրենց գործին. դրանք կարող են ամրապնդվել մեկ ուրիշի կողմից: Երբեմն մարդիկ դուրս են մնում այս աշխատանքային խմբից: Ինչ-որ մեկը գնում է արձակուրդ, ինչ-որ մեկը զեկույց է տալիս DevOps conf կոնֆերանսի համար, ինչ-որ մեկը հոդված է գրում Habr-ի վրա: Իմանալը, թե ինչ նպատակներ և առաջադրանքներ կարելի է կատարել զուգահեռ, շատ կարևոր է դառնում։

2. Առավոտյան հանրահավաքների հերթափոխով հյուրընկալողներ։ Ստենդափներում մենք բախվեցինք մի խնդրի, երբ մարդիկ զուգահեռաբար բազմաթիվ առաջադրանքներ էին կատարում։ Երբեմն առաջադրանքները անփույթ կերպով կապված են միմյանց հետ, և չկա հասկացողություն, թե ով ինչ է անում: Իսկ թիմի մեկ այլ անդամի կարծիքը շատ կարեւոր է։ Սա լրացուցիչ տեղեկատվություն է, որը կարող է փոխել խնդրի լուծման ընթացքը։ Իհարկե, սովորաբար ձեր զույգում ինչ-որ մեկը ձեզ հետ է, բայց խորհրդատվությունն ու խորհուրդները միշտ օգտակար են:

Այս իրավիճակը բարելավելու համար մենք օգտագործեցինք «Change of Lead Standup» տեխնիկան: Հիմա դրանք պտտվում են ըստ որոշակի ցուցակի, և դա իր ազդեցությունն ունի։ Երբ ձեր հերթն է, դուք ստիպված եք սուզվել և հասկանալ, թե ինչ է տեղի ունենում, որպեսզի անցկացնեք լավ scrum հանդիպում:

3. Ներքին ցուցադրություն: Զույգ ծրագրավորումից խնդրի լուծման հարցում օգնությունը, առաջադրանքների ծառի վրա պատկերացումը և առավոտյան scrum հանդիպումներին օգնությունը լավ են, բայց ոչ իդեալական: Որպես զույգ՝ դուք սահմանափակված եք միայն ձեր գիտելիքներով։ Առաջադրանքների ծառը օգնում է գլոբալ կերպով հասկանալ, թե ով ինչ է անում: Իսկ առավոտյան հանդիպման հաղորդավարն ու գործընկերները ձեր խնդիրների մեջ չեն խորանա։ Նրանք հաստատ կարող էին ինչ-որ բան բաց թողնել:

Լուծումը գտնվել է ավարտված աշխատանքները միմյանց ցույց տալու, ապա քննարկելու մեջ։ Հանդիպում ենք շաբաթը մեկ անգամ մեկ ժամ տեւողությամբ և ցույց ենք տալիս վերջին շաբաթվա ընթացքում մեր արած խնդիրների լուծման մանրամասները:

Ցուցադրության ժամանակ անհրաժեշտ է բացահայտել առաջադրանքի մանրամասները և անպայման ցուցադրել դրա գործողությունը։

Զեկույցը կարող է իրականացվել ստուգաթերթի միջոցով:1. Ներդրեք համատեքստում: Որտեղի՞ց առաջացավ առաջադրանքը, ինչի՞ համար էր դա ընդհանրապես անհրաժեշտ։

2. Ինչպե՞ս էր խնդիրը լուծվում նախկինում: Օրինակ՝ պահանջվում էր մկնիկի զանգվածային սեղմում, կամ ընդհանրապես անհնար էր որևէ բան անել։

3. Ինչպես ենք մենք այն կատարելագործում: Օրինակ՝ «Տեսեք, հիմա կա սցենար, ահա «readme»-ը։

4. Ցույց տվեք, թե ինչպես է այն աշխատում: Ցանկալի է ուղղակիորեն իրագործել օգտատերերի ինչ-որ սցենար։ Ես ուզում եմ X, ես անում եմ Y, տեսնում եմ Y (կամ Z): Օրինակ, ես տեղակայում եմ NGINX-ը, ուղարկում եմ url և ստանում եմ 200 OK: Եթե ​​գործողությունը երկար է, նախօրոք պատրաստեք այն, որպեսզի հետո կարողանաք ցուցադրել: Ցանկալի է, որ այն շատ չկոտրվի ցուցադրումից մեկ ժամ առաջ, եթե այն փխրուն է:

5. Բացատրեք, թե որքանով է հաջողությամբ լուծվել խնդիրը, ինչ դժվարություններ են մնացել, ինչը չի ավարտվել, ինչ բարելավումներ են հնարավոր ապագայում: Օրինակ, հիմա cli-ն է, ապա CI-ում լիարժեք ավտոմատացում կլինի:

Ցանկալի է, որ յուրաքանչյուր բանախոս ելույթը պահի 5-10 րոպե: Եթե ​​ձեր ներկայացումն ակնհայտորեն կարևոր է և ավելի շատ ժամանակ կխլի, խնդրում ենք նախապես համաձայնեցնել դրա մասին sre-takeover ալիքում:

Անձնական մասից հետո թեմայում միշտ քննարկում է լինում։ Այստեղ է հայտնվում մեր առաջադրանքների վերաբերյալ մեզ անհրաժեշտ արձագանքները:

Արդյունքում անցկացվում է հարցում՝ պարզելու տեղի ունեցողի օգտակարությունը։ Սա արդեն հետադարձ կապ է խոսքի էության և առաջադրանքի կարևորության մասին։

Երկար եզրակացություններ և ինչ հաջորդ

Հոդվածի տոնայնությունը կարող է որոշ չափով հոռետեսական թվալ։ Սա սխալ է։ Հետադարձ կապի երկու ցածր մակարդակները՝ թեստերը և զույգերի ծրագրավորումը, աշխատում են: Ոչ այնքան կատարյալ, որքան ավանդական զարգացումը, բայց դա դրական ազդեցություն ունի:

Թեստերն իրենց ներկայիս տեսքով ապահովում են միայն մասնակի ծածկույթ: Կազմաձևման շատ գործառույթներ մնացել են չփորձարկված: Նրանց ազդեցությունը կոդ գրելու իրական աշխատանքի վրա ցածր է: Այնուամենայնիվ, ինտեգրացիոն թեստերն իսկապես ունեն ազդեցություն, և դրանք թույլ են տալիս առանց վախի իրականացնել վերամշակումներ: Սա մեծ ձեռքբերում է։ Բացի այդ, բարձր մակարդակի լեզուների զարգացման վրա կենտրոնացվածության անցումով (մենք ունենք python, գնացեք), խնդիրը վերանում է: Իսկ «սոսինձի» համար շատ ստուգումներ պետք չեն, բավական է ընդհանուր ինտեգրացիոն ստուգումը։

Զույգերով աշխատելն ավելի շատ կախված է կոնկրետ մարդկանցից: Կա առաջադրանքի գործոն և մեր փափուկ հմտությունները: Ոմանց մոտ դա շատ լավ է ստացվում, մյուսների մոտ՝ ավելի վատ։ Սա միանշանակ որոշակի օգուտ կա: Հասկանալի է, որ նույնիսկ զույգերով աշխատանքի կանոնների անբավարար պահպանման դեպքում առաջադրանքների համատեղ կատարման փաստը դրականորեն է ազդում արդյունքի որակի վրա: Անձամբ ինձ համար ավելի հեշտ և հաճելի է զույգերով աշխատելը:

ՕՀ-ի վրա ազդելու ավելի բարձր մակարդակի մեթոդները՝ պլանավորումը և առաջադրանքների հետ աշխատելը, միանշանակ արդյունք են տալիս՝ բարձրորակ գիտելիքների փոխանակում և զարգացման որակի բարելավում:

Կարճ եզրակացություններ մեկ տողում

• XP-ի մասնագետներն աշխատում են IaC-ում, բայց ավելի քիչ արդյունավետությամբ:
• Ընդլայնել այն, ինչ աշխատում է:
• Ստեղծեք ձեր սեփական փոխհատուցման մեխանիզմները և գործելակերպը:

Source: www.habr.com