Շարունակական ինտեգրումը որպես պրակտիկա, ոչ թե Ջենքինս: Անդրեյ Ալեքսանդրով

Եկեք քննարկենք, թե ինչու են CI գործիքները և CI-ն բոլորովին տարբեր բաներ:

Ի՞նչ ցավ է նախատեսվում լուծել CI-ն, որտեղի՞ց է ծագել գաղափարը, որո՞նք են վերջին հաստատումները, որ այն աշխատում է, ինչպես հասկանալ, որ դուք ունեք պրակտիկա և ոչ միայն տեղադրել Jenkins:

Շարունակական ինտեգրման մասին զեկույց պատրաստելու գաղափարը ի հայտ եկավ մեկ տարի առաջ, երբ ես գնում էի հարցազրույցների և աշխատանք փնտրում։ Ես խոսեցի 10-15 ընկերությունների հետ, նրանցից միայն մեկը կարողացավ հստակ պատասխանել, թե ինչ է CI-ն և բացատրել, թե ինչպես են հասկացել, որ չունեն: Մնացածն անհասկանալի հիմարություններ էին խոսում Ջենքինսի մասին :) Դե, մենք ունենք Ջենքինս, այն կառուցում է, CI! Զեկույցի ընթացքում ես կփորձեմ բացատրել, թե իրականում ինչ է Continuous Integration-ը և ինչու Jenkins-ը և նմանատիպ գործիքները շատ թույլ հարաբերություններ ունեն դրա հետ:

Այսպիսով, ի՞նչ է սովորաբար գալիս ձեր մտքին, երբ լսում եք CI բառը: Մարդկանց մեծամասնությունը կմտածի Ջենկինսի, Gitlab CI-ի, Travis-ի և այլնի մասին:

Եթե ​​նույնիսկ Google-ում փնտրենք, դա մեզ կտա այս գործիքները:

Եթե ​​դուք ծանոթ եք հարցմանը, ապա գործիքները ցուցակագրելուց անմիջապես հետո նրանք ձեզ կասեն, որ CI-ն այն է, երբ դուք կառուցում և կատարում եք թեստեր Pull Request-ում կատարման համար:

Շարունակական ինտեգրումը գործիքների մասին չէ, ոչ թե մասնաճյուղում թեստերով հավաքների: Շարունակական ինտեգրումը նոր կոդի շատ հաճախակի ինտեգրման պրակտիկա է, և այն օգտագործելու համար ամենևին էլ անհրաժեշտ չէ ցանկապատել Jenkins-ը, GitLab-ը և այլն:

Նախքան պարզենք, թե ինչ տեսք ունի լիարժեք CI-ն, եկեք նախ խորանանք այն մարդկանց համատեքստի մեջ, ովքեր եկել են այն և զգալ այն ցավը, որը նրանք փորձում էին լուծել:

Եվ նրանք լուծեցին միասին որպես թիմ աշխատելու ցավը:

Դիտարկենք այն դժվարությունների օրինակները, որոնց բախվում են ծրագրավորողները թիմերում զարգանալիս: Այստեղ մենք ունենք նախագիծ, գլխավոր մասնաճյուղ git-ում և երկու մշակող:

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

Մեկն ավելի արագ ավարտեց գործառույթը և միացրեց այն հիմնականին:

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

Որքան դժվար է համատեղել ձեր հատկանիշը ընդհանուր վարպետի հետ, այնքան ավելի շատ ժամանակ ենք ծախսում դրա վրա: Եվ ես սա ցույց տվեցի բավականին պարզ օրինակով. Սա մի օրինակ է, որտեղ կա ընդամենը 2 մշակող: Պատկերացրեք, եթե ընկերությունում 10 կամ 15 կամ 100 հոգի գրեն մեկ պահեստ: Դուք կխելագարվեք այս բոլոր կոնֆլիկտները լուծելու համար։

Մի փոքր այլ դեպք կա. Մենք ունենք վարպետ և որոշ մշակողներ, ովքեր ինչ-որ բան են անում:

Նրանք ստեղծել են մի ճյուղ։

Մեկը մահացավ, ամեն ինչ լավ էր, առաջադրանքը կատարեց։

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

Այս ընթացքում երկրորդ մշակողը այլ բան արեց.

Առաջինը կատարեց երրորդ առաջադրանքը.

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

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

Ստացվում է, որ եթե մենք աշխատում ենք որպես թիմ, այսինքն, ոչ թե մեկ հոգի է պտտվում պահեստում, այլ 5-10 հոգի, ապա որքան երկար չավելացնենք մեր կոդը վարպետին, այնքան ավելի շատ ենք տուժում, քանի որ ի վերջո մեզ պետք է. ինչ-որ բան, ապա միաձուլեք այն: Եվ որքան շատ կոնֆլիկտներ ունենանք, և որքան հին տարբերակով աշխատենք, այնքան շատ խնդիրներ ունենք։

Միասին ինչ-որ բան անելը ցավոտ է: Մենք միշտ խանգարում ենք միմյանց:

Այս խնդիրը նկատվել է ավելի քան 20 տարի առաջ։ Ես գտա առաջին հիշատակումը Extreme Programming-ում Continuous Integration-ի պրակտիկայի մասին:

Extreme Programming-ը առաջին արագաշարժ շրջանակն է: Էջը հայտնվել է 96թ. Եվ գաղափարն այն էր, որ օգտագործենք ինչ-որ ծրագրավորման պրակտիկա, պլանավորում և այլ բաներ, որպեսզի զարգացումը լինի հնարավորինս ճկուն, որպեսզի մենք կարողանանք արագ արձագանքել մեր հաճախորդների ցանկացած փոփոխության կամ պահանջի: Եվ նրանք սկսեցին դիմակայել դրան 24 տարի առաջ, որ եթե ինչ-որ բան անում ես շատ երկար և կողքից, ապա ավելի շատ ժամանակ ես ծախսում դրա վրա, քանի որ կոնֆլիկտներ ունես:

Այժմ մենք անհատապես կվերլուծենք «Շարունակական ինտեգրում» արտահայտությունը: Եթե ​​ուղղակիորեն թարգմանենք, կստանանք շարունակական ինտեգրում։ Բայց թե որքանով է այն շարունակական, այնքան էլ պարզ չէ, այն շատ ընդհատված է: Բայց թե որքանով է այն ինտեգրված, նույնպես այնքան էլ ակնհայտ չէ։

Եվ դրա համար ես հիմա ձեզ մեջբերումներ եմ տալիս Extreme Programming-ից: Եվ երկու բառն էլ կվերլուծենք առանձին։

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

Ինտեգրումն այն է, երբ մենք վերցնում ենք մեր ճյուղը և այն ինտեգրում վարպետի հետ, միաձուլում ենք այն: Գոյություն ունի վերջնական տարբերակ, երբ մենք տրանսբազային ծրագրավորող ենք, որտեղ մենք ձգտում ենք ապահովել, որ մենք անմիջապես գրենք վարպետին առանց լրացուցիչ ճյուղերի:

Ընդհանրապես, ինտեգրումը նշանակում է վերցնել ձեր կոդը և քաշել այն վարպետի մեջ:

Ի՞նչ է նշանակում այստեղ «շարունակական» բառը, ի՞նչ է կոչվում շարունակականություն։ Պրակտիկան ենթադրում է, որ մշակողը ձգտում է հնարավորինս արագ ինտեգրել իր կոդը: Սա է նրա նպատակը ցանկացած առաջադրանք կատարելիս՝ հասնել նրան, որ իր կոդը հնարավորինս արագ հայտնվի վարպետում: Իդեալական աշխարհում ծրագրավորողները դա կանեն ամեն մի քանի ժամը մեկ: Այսինքն, դուք վերցնում եք մի փոքր խնդիր և միացնում այն ​​վարպետին: Ամեն ինչ հիանալի է։ Սա այն է, ինչին դու ձգտում ես: Եվ դա պետք է արվի շարունակաբար։ Հենց ինչ-որ բան ես անում, անմիջապես դնում ես վարպետի մեջ։

Իսկ մշակողը, ով ինչ-որ բան է պատրաստում, պատասխանատու է այն ամենի համար, ինչ արել է, որպեսզի այն աշխատի և ոչինչ չխախտի: Այստեղ սովորաբար հայտնվում է թեստային պատմությունը: Մենք ցանկանում ենք որոշ թեստեր անցկացնել մեր կատարման, մեր միաձուլման վրա՝ համոզվելու, որ այն աշխատում է: Եվ ահա, որտեղ Ջենքինսը կարող է օգնել ձեզ:

Բայց պատմություններով. եկեք փոփոխությունները փոքրացնենք, թույլ տանք, որ առաջադրանքները փոքր լինեն, եկեք խնդիր ստեղծենք և անմիջապես փորձենք ինչ-որ կերպ այն ներդնել վարպետի մեջ. ոչ մի Ջենքինս այստեղ չի օգնի: Քանի որ Ջենքինսը կօգնի ձեզ միայն թեստեր անցկացնել:

Դուք կարող եք անել առանց նրանց: Սա ձեզ բոլորովին չի վնասի: Որովհետև պրակտիկայի նպատակն է հնարավորինս հաճախ չափել, որպեսզի ապագայում հսկայական ժամանակ չկորցնենք որևէ կոնֆլիկտների վրա:

Պատկերացնենք, որ ինչ-ինչ պատճառներով մենք 2020 թվականին ենք առանց ինտերնետի։ Եվ մենք աշխատում ենք տեղում: Մենք Ջենքինս չունենք։ Սա լավ է: Դուք դեռ կարող եք առաջ գնալ և տեղական մասնաճյուղ ստեղծել: Դուք դրա մեջ ինչ-որ կոդ եք գրել։ Առաջադրանքը կատարեցինք 3-4 ժամում։ Մենք անցանք վարպետի, արեցինք git pull և միացրինք մեր մասնաճյուղը այնտեղ: Պատրաստ. Եթե ​​դա հաճախ եք անում, շնորհավորում եմ, դուք ունեք շարունակական ինտեգրում:

Ի՞նչ ապացույց կա ժամանակակից աշխարհում, որ արժե էներգիա ծախսել: Քանի որ ընդհանուր առմամբ դժվար է։ Եթե ​​փորձեք այսպես աշխատել, կհասկանաք, որ որոշ պլանավորում այժմ կազդի, դուք ստիպված կլինեք ավելի շատ ժամանակ հատկացնել քայքայվող առաջադրանքներին: Որովհետև եթե դու տղամարդու..., ապա դու չես կարողանա արագ հաշտվել և, համապատասխանաբար, փորձանքի մեջ կհայտնվես։ Դուք այլևս պրակտիկա չեք ունենա։

Եվ դա թանկ կլինի: Վաղվանից հնարավոր չի լինի անմիջապես աշխատել՝ օգտագործելով Continuous Integration։ Ձեզանից բոլորից շատ երկար ժամանակ կպահանջվի դրան ընտելանալու համար, շատ երկար ժամանակ կպահանջվի՝ վարժվելու առաջադրանքների քայքայմանը, շատ երկար ժամանակ կպահանջվի վերանայման պրակտիկան վարժվելու համար, եթե ունեք այդպիսին։ . Որովհետև մեր նպատակն է, որ այն այսօր հալվի։ Եվ եթե դուք վերանայեք երեք օրվա ընթացքում, ապա դուք խնդիրներ ունեք, և Continuous Integration-ը ձեզ համար չի աշխատում:

Բայց մենք ունե՞նք որևէ համապատասխան ապացույց հենց հիմա, որը մեզ հուշում է, որ այս պրակտիկայում ներդրումներ կատարելն իմաստ ունի:

Առաջին բանը, որ մտքովս անցավ, դա DevOps-ի վիճակը էր: Սա ուսումնասիրություն է, որը տղաները անում են արդեն 7 տարի։ Հիմա դա անում են որպես անկախ կազմակերպություն, բայց Google-ի ներքո։

Եվ նրանց 2018-ի ուսումնասիրությունը ցույց տվեց փոխկապակցվածություն ընկերությունների միջև, որոնք փորձում են օգտագործել կարճատև մասնաճյուղեր, որոնք արագ ինտեգրվում են, հաճախ ինտեգրվում և ունեն ՏՏ արդյունավետության ավելի լավ ցուցանիշներ:

Որո՞նք են այդ ցուցանիշները: Սրանք 4 չափումներ են, որոնք նրանք վերցնում են բոլոր ընկերություններից իրենց հարցաթերթերում՝ տեղակայման հաճախականությունը, փոփոխությունների իրականացման ժամկետը, ծառայության վերականգնման ժամանակը, ձախողման փոփոխության մակարդակը:

Եվ, նախ, կա այս հարաբերակցությունը, մենք գիտենք, որ հաճախակի չափումներ կատարող ընկերությունները շատ ավելի լավ չափումներ ունեն: Եվ նրանք ունեն ընկերությունների բաժանում մի քանի կատեգորիաների. սրանք դանդաղ ընկերություններ են, որոնք ինչ-որ բան են արտադրում դանդաղ, միջին կատարողական, բարձր կատարողական և էլիտար: Էլիտան են Netflix-ը, Amazon-ը, որոնք գերարագ են, ամեն ինչ անում են արագ, գեղեցիկ և արդյունավետ։

Երկրորդ պատմությունը, որը տեղի է ունեցել ընդամենը մեկ ամիս առաջ. Technology Radar-ը հիանալի հոդված ունի Gitflow-ի մասին: Gitflow-ը տարբերվում է մյուսներից նրանով, որ նրա ճյուղերը երկարակյաց են: Կան ազատման ճյուղեր, որոնք ապրում են երկար ժամանակ, և առանձնանում են ճյուղեր, որոնք նույնպես երկար են ապրում: Technology Radar-ի այս պրակտիկան տեղափոխվել է HOLD: Ինչո՞ւ։ Որովհետև մարդիկ բախվում են ինտեգրման ցավին:

Եթե ​​ձեր ճյուղը շատ երկար է ապրում, այն խրվում է, փտում, և մենք սկսում ենք ավելի շատ ժամանակ ծախսել՝ փորձելով ինչ-որ փոփոխություն կատարել դրանում:

Եվ վերջերս Gitflow-ի հեղինակն ասաց, որ եթե ձեր նպատակը Continuous Integration-ն է, եթե ձեր նպատակն է, որ ցանկանում եք հնարավորինս հաճախ գլորվել, ապա Gitflow-ը վատ գաղափար է: Նա առանձին-առանձին ավելացրեց հոդվածին, որ եթե ունես backend, որտեղ կարող ես ձգտել դրան, ապա Gitflow-ը քեզ համար ավելորդ է, քանի որ Gitflow-ը կդանդաղեցնի քեզ, Gitflow-ը քեզ համար խնդիրներ կստեղծի ինտեգրման հետ կապված։

Սա չի նշանակում, որ Gitflow-ը վատն է և չպետք է օգտագործվի: Դա այլ առիթների համար է: Օրինակ, երբ դուք պետք է աջակցեք ծառայության կամ հավելվածի մի քանի տարբերակների, այսինքն, որտեղ ձեզ երկար ժամանակ անհրաժեշտ է աջակցություն:

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

Ինչպես ճիշտ նշել է Ալեքսանդր Կովալևը զրուցարանում, հարաբերակցությունը նույնը չէ, ինչ պատճառականությունը: Սա ճիշտ է։ Այսինքն՝ ուղղակի կապ չկա, որ եթե ունես Continuous Integration, ուրեմն բոլոր ցուցանիշները հիանալի կլինեն։ Բայց կա մի դրական հարաբերակցություն, որ եթե մեկը մեկն է, ապա ամենայն հավանականությամբ մյուսն էլ է։ Փաստ չէ, բայց ամենայն հավանականությամբ։ Դա ուղղակի հարաբերակցություն է:

Թվում է, թե մենք արդեն ինչ-որ բան անում ենք, թվում է, թե մենք արդեն միաձուլվում ենք, բայց ինչպե՞ս հասկանանք, որ մենք դեռ ունենք Continuous Integration, որ մենք բավականին հաճախ ենք միաձուլվում։

Jez Humble-ը Handbook, Accelerate, Continuous Delivery կայքի և Continuous Delivery գրքի հեղինակն է: Նա առաջարկում է այս թեստը.

• Ինժեների կոդը ամեն օր հասնում է վարպետին:
• Յուրաքանչյուր պարտավորության համար դուք կատարում եք միավորի թեստեր:
• Վարպետի շինությունն ընկավ, մոտ 10 րոպեում ֆիքսվեց։

Նա առաջարկում է օգտագործել նման թեստ՝ համոզվելու համար, որ բավականաչափ պրակտիկա ունեք:

Վերջինս մի փոքր վիճելի եմ համարում: Այսինքն, եթե կարող ես 10 րոպեում շտկել, ուրեմն ունես Continuous Integration, մի քիչ տարօրինակ է հնչում, իմ կարծիքով, բայց իմաստ ունի։ Ինչո՞ւ։ Որովհետև եթե հաճախ սառչում ես, նշանակում է քո փոփոխությունները փոքր են։ Եթե ​​փոքր փոփոխությունը նշանակում է, որ ձեր հիմնական կառուցվածքը կոտրված է, ապա դուք կարող եք արագ գտնել օրինակ, քանի որ փոփոխությունը փոքր է: Այստեղ դուք մի փոքր միաձուլում ունեցաք, դրա մեջ 20-30 տող փոխվեց: Եվ, համապատասխանաբար, դուք կարող եք արագ հասկանալ, թե որն է եղել պատճառը, քանի որ փոփոխությունները չնչին են, դուք ունեք շատ փոքր տարածք խնդիրը փնտրելու համար:

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

Միավոր թեստերը պարզապես օգնական են, որն օգնում է ձեզ հասկանալ, թե արդյոք ձեր ինտեգրումը հաջող է եղել, և արդյոք ոչինչ չի կոտրվել: Սա, իմ կարծիքով, նույնպես ամբողջությամբ պարտադիր չէ, քանի որ գործնականում դա չէ։

Սա շարունակական ինտեգրման համառոտ ներածություն է: Սա այն ամենն է, ինչ կա այս պրակտիկայի մեջ: Ես պատրաստ եմ հարցերի։

Պարզապես նորից հակիրճ ամփոփեմ.

• Շարունակական ինտեգրումը Ջենքինսը չէ, այն Գիթլաբը չէ:
• Սա գործիք չէ, դա պրակտիկա է, որ մենք հնարավորինս հաճախ միացնում ենք մեր կոդը վարպետի մեջ:
• Մենք դա անում ենք, որպեսզի խուսափենք այն ահռելի ցավից, որն առաջանում է միաձուլումների ժամանակ ապագայում, այսինքն՝ մենք հիմա մի փոքր ցավ ենք ապրում, որպեսզի հետագայում ավելին չզգանք: Ամբողջ իմաստը դա է:
• Կողքի վրա կա հաղորդակցություն կոդի միջոցով, բայց ես շատ հազվադեպ եմ դա տեսնում, բայց սա նաև այն է, ինչի համար այն նախատեսված է:

Հարցեր

Ի՞նչ անել չքայքայված առաջադրանքների հետ:

Քայքայվել։ Ինչումն է խնդիրը? Կարո՞ղ եք օրինակ բերել, որ կա առաջադրանք և այն քայքայված չէ։

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

Եթե ​​ճիշտ եմ հասկանում, ուրեմն կա ինչ-որ մեծ ու բարդ խնդիր, որի արդյունքը տեսանելի կլինի միայն մեկ ամսից։

Այո դա ճիշտ է. Այո, արդյունքը հնարավոր կլինի գնահատել ոչ շուտ, քան մեկ ամսից։

Լավ: Ընդհանուր առմամբ, դա խնդիր չէ։ Ինչո՞ւ։ Որովհետեւ այս դեպքում, երբ խոսում ենք ոստերի մասին, խոսքը հատկանիշ ունեցող ոստի մասին չէ։ Հատկանիշները կարող են լինել մեծ և բարդ: Նրանք կարող են ազդել մեծ թվով բաղադրիչների վրա: Եվ գուցե մենք չենք կարող դրանք ամբողջությամբ կատարել մեկ ճյուղում: Սա լավ է: Մենք պարզապես պետք է քանդենք այս պատմությունը: Եթե ​​գործառույթն ամբողջությամբ պատրաստ չէ, դա չի նշանակում, որ դրա կոդի որոշ մասեր չեն կարող միավորվել: Դուք ավելացրել եք, ասենք, միգրացիա, և գործառույթի ներսում կան որոշ փուլեր: Ենթադրենք, դուք ունեք մի փուլ՝ միգրացիա կատարեք, նոր մեթոդ ավելացրեք։ Եվ դուք արդեն կարող եք ամեն օր չափել այս բաները:

Լավ: Ի՞նչ իմաստ ունի այդ դեպքում:

Ի՞նչ իմաստ ունի ամեն օր մանր բաներ սպանել։

Այո:

Եթե ​​ինչ-որ բան կոտրում են, անմիջապես տեսնում ես: Դուք ունեք մի փոքր կտոր, որը կոտրել է ինչ-որ բան, ձեզ համար ավելի հեշտ է այն ուղղել: Բանն այն է, որ հիմա փոքր կտորի միաձուլումը շատ ավելի հեշտ է, քան մի քանի շաբաթվա ընթացքում մի մեծ բանի միաձուլումը: Եվ երրորդ կետն այն է, որ այլ ինժեներներ կաշխատեն կոդի ներկայիս տարբերակով։ Նրանք կտեսնեն, որ այստեղ ավելացվել են որոշ միգրացիաներ, այնուհետև հայտնվել է ինչ-որ մեթոդ, որը նրանք նույնպես կարող են ցանկանալ օգտագործել: Բոլորը կտեսնեն, թե ինչ է կատարվում ձեր ծածկագրում: Հենց այս երեք բաների համար է արվում պրակտիկան:

Շնորհակալություն, հարցը փակված է։

(Օլեգ Սորոկա) Կարո՞ղ եմ ավելացնել: Ամեն ինչ ճիշտ ասացիր, միայն մեկ արտահայտություն եմ ուզում ավելացնել.

Այսպիսով

Continuous Integration-ի միջոցով կոդը միաձուլվում է ընդհանուր ճյուղի մեջ ոչ թե այն ժամանակ, երբ ֆունկցիան ամբողջությամբ պատրաստ է, այլ երբ build-ը դադարում է կոտրվել: Եվ դուք կարող եք ապահով կերպով պարտավորվել տիրապետել օրական այնքան անգամ, որքան ցանկանում եք: Երկրորդ ասպեկտն այն է, որ եթե ինչ-ինչ պատճառներով չեք կարողանում ամսական առաջադրանքները բաժանել առաջադրանքների առնվազն երեք օր, ես լռում եմ մոտ երեք ժամ, ապա դուք ունեք հսկայական խնդիր: Եվ այն, որ դուք չունեք Continuous Integration, այս խնդիրներից ամենաքիչն է: Սա նշանակում է, որ դուք խնդիրներ ունեք ճարտարապետության և զրոյական ինժեներական պրակտիկայի հետ: Որովհետև եթե նույնիսկ սա հետազոտություն է, ապա ամեն դեպքում այն ​​պետք է ձևակերպվի վարկածների կամ ցիկլի տեսքով։

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

Ես ճի՞շտ հասկացա ձեզ, որ կարծում եք, որ ընդհանուր առմամբ իմաստ չունի ներդրումներ կատարել ինժեներական պրակտիկայում, եթե որևէ առաջադրանքի ավարտը մեկ ամիս է տևում:

Դուք ունեք շարունակական ինտեգրում: Ու նենց թեմա կա, որ 10 րոպեում կամ ֆիքսում ես, կամ հետ գլորում։ Պատկերացրեք, որ դուք այն դուրս եք հանել: Ավելին, դուք նույնիսկ անընդհատ տեղակայում եք, դուք գլորում եք այն, որպեսզի այն խրախուսվի և միայն այն ժամանակ նկատեցիք, որ ինչ-որ բան սխալ է տեղի ունեցել: Եվ դուք պետք է հետ գլորեք այն, բայց դուք արդեն տեղափոխել եք ձեր տվյալների բազան: Դուք արդեն ունեք հաջորդ տարբերակի տվյալների բազայի սխեման, ավելին, ինչ-որ պահուստային տարբերակ էլ ունեիք, և տվյալները նույնպես գրված էին այնտեղ։

Իսկ դու ի՞նչ այլընտրանք ունես։ Եթե ​​հետ գլորեք կոդը, ապա այն այլևս չի կարող աշխատել այս թարմացված տվյալների բազայի հետ:

Հիմքը միայն առաջ է շարժվում, այո։

Մարդիկ, ովքեր ունեն վատ ինժեներական պրակտիկա, ամենայն հավանականությամբ, չեն կարդացել նաև հաստ գիրքը… Ի՞նչ անել կրկնօրինակի հետ: Եթե ​​դուք վերականգնում եք կրկնօրինակից, դա նշանակում է, որ դուք կորցնում եք այն տվյալները, որոնք կուտակել եք այդ պահին։ Օրինակ, մենք երեք ժամ աշխատեցինք տվյալների բազայի նոր տարբերակով, այնտեղ գրանցված օգտատերեր։ Դուք հրաժարվում եք հին կրկնօրինակումից, քանի որ սխեման չի աշխատում նոր տարբերակի հետ, ուստի կորցրել եք այս օգտվողներին: Իսկ իրենք դժգոհ են, հայհոյում են։

Շարունակական ինտեգրմանը և շարունակական առաքմանը աջակցող պրակտիկաների ամբողջ շարքին տիրապետելու համար բավական չէ պարզապես գրել սովորել... Նախ, դրանք կարող են շատ լինել, դա անիրագործելի կլինի: Բացի այդ, կան մի շարք այլ պրակտիկաներ, ինչպիսիք են Գիտականը: Նման պրակտիկա կա, GitHub-ը ժամանակին մասսայականացրել է։ Սա այն դեպքում, երբ դուք միաժամանակ աշխատում եք ինչպես հին, այնպես էլ նոր կոդով: Սա այն դեպքում, երբ դուք ստեղծում եք անավարտ գործառույթ, բայց այն կարող է վերադարձնել որոշակի արժեք՝ կա՛մ որպես ֆունկցիա, կա՛մ որպես Rest API: Դուք կատարում եք և՛ նոր ծածկագիրը, և՛ հին ծածկագիրը և համեմատում դրանց միջև եղած տարբերությունը: Եվ եթե կա տարբերություն, ապա դուք գրանցում եք այս իրադարձությունը: Այսպիսով, դուք գիտեք, որ դուք ունեք նոր գործառույթ, որը պատրաստ է ներդնել հնի վերևում, եթե այդ երկուսի միջև որոշակի ժամանակ անհամապատասխանություն չեք ունեցել:

Նման հարյուրավոր պրակտիկաներ կան։ Ես կառաջարկեի սկսել տրանսբազային զարգացումից։ Նա 100%-ով չի կողմնորոշվում շարունակական ինտեգրման վրա, բայց գործելակերպը նույնն է, մեկը չի կարող լավ ապրել առանց մյուսի:

Դուք տրանսբազայի մշակումը որպես օրինակ բերե՞լ եք, որտեղ դուք կարող եք տեսնել պրակտիկաներ, թե՞ առաջարկում եք մարդկանց սկսել օգտագործել տրանսբազային հեռացում:

Նայեք, քանի որ նրանք չեն կարողանա օգտագործել այն: Դրանք օգտագործելու համար պետք է շատ կարդալ։ Եվ երբ մարդը հարցնում է. «Ի՞նչ անել մի հատկանիշի հետ, որը տևում է մեկ ամիս, դա նշանակում է, որ նա չի կարդացել տրանսբազային զարգացման մասին»: Ես դա դեռ խորհուրդ չէի տա: Ես խորհուրդ կտայի կենտրոնանալ բացառապես այն թեմայի վրա, թե ինչպես ճիշտ ճարտարապետականորեն բաժանել մեծ առաջադրանքները փոքրերի: Սա է տարրալուծման էությունը:

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

Դուք պետք է նկարեք մի շարք սլաքներ և քառակուսիներ որոշ գծապատկերների վրա: Չի կարելի ասել, որ հիմա ես ցույց կտամ նոր հավելվածի ճարտարապետական ​​դիագրամը և ցույց կտամ մեկ քառակուսի, որի ներսում կա հավելվածի կանաչ կոճակը։ Ամեն դեպքում քառակուսիներն ու սլաքներն ավելի շատ կլինեն։ Յուրաքանչյուր դիագրամ, որը ես տեսա, ուներ մեկից ավելի: Իսկ տարրալուծում, նույնիսկ գրաֆիկական ներկայացման մակարդակով, արդեն տեղի է ունենում։ Հետեւաբար, հրապարակները կարող են անկախ լինել: Եթե ​​ոչ, ապա ես մեծ հարցեր ունեմ ճարտարապետին.

Չաթից հարց կա. «Եթե վերանայումը պարտադիր է և երկար ժամանակ է պահանջում, միգուցե մեկ օր կամ ավելի»:

Պրակտիկայի հետ կապված խնդիրներ ունեք։ Վերանայումը չպետք է տևի մեկ օր կամ ավելի: Սա նախորդ հարցի նույն պատմությունն է, միայն մի փոքր ավելի մեղմ: Եթե ​​վերանայումը շարունակվում է մեկ օր, ապա, ամենայն հավանականությամբ, այս վերանայումը տեղի է ունենում շատ մեծ փոփոխության: Սա նշանակում է, որ այն պետք է փոքրացնել: Տրանսբազային մշակման մեջ, որը խորհուրդ տվեց Օլեգը, կա մի պատմություն, որը կոչվում է շարունակական վերանայում: Նրա գաղափարն այն է, որ մենք միտումնավոր ենք նման փոքր ձգողականության խնդրանքով դիմում, քանի որ մենք ձգտում ենք անընդհատ և մի փոքր միաձուլվել: Եվ այսպես, ձգման հարցումը փոխում է մեկ աբստրակցիա կամ 10 տող: Այս վերանայման շնորհիվ մեզ մի քանի րոպե է տևում:

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

Ինչ վերաբերում է 4 չափորոշիչներին, ես դեռ խորհուրդ կտայի հեռացնել դրանք՝ հասկանալու համար, թե դա ինչի է հանգեցնում: Նայեք թվերին, նայեք նկարին, ինչ վատ է ամեն ինչ։

(Դմիտրի) Ես պատրաստ եմ այս մասին քննարկման մեջ մտնել ձեզ հետ։ Թվերն ու չափորոշիչները բոլորն էլ հիանալի են, պրակտիկան հիանալի է: Բայց դուք պետք է հասկանաք, արդյոք բիզնեսին դա պետք է: Կան բիզնեսներ, որոնք փոփոխության նման արագության կարիք չունեն: Ես գիտեմ ընկերություններ, որտեղ փոփոխություններ չեն կարող կատարվել 15 րոպեն մեկ: Եվ ոչ այն պատճառով, որ նրանք այդքան վատն են: Սա նման կյանքի ցիկլ է: Իսկ ճյուղերը հատկանշական դարձնելու համար անհրաժեշտ է խորը գիտելիքներ:

Դա բարդ է. Եթե ​​ցանկանում եք ավելի մանրամասն կարդալ միացման գործառույթի մասին պատմությունը, ես խորհուրդ եմ տալիս այն https://trunkbaseddevelopment.com/. Եվ կա մի հրաշալի հոդված Մարտին Ֆաուլերի կողմից՝ փոխարկման առանձնահատկությունների մասին. ինչ տեսակներ կան, կյանքի ցիկլեր և այլն։ Փոխարկելու ֆունկցիան բարդ է։

Իսկ դուք դեռ չեք պատասխանել հարցին՝ «Ջենկինսը պե՞տք է, թե՞ ոչ»:

Ջենկինսը ոչ մի դեպքում իսկապես պետք չէ։ Այնուամենայնիվ, լուրջ, գործիքները. Ջենկինսը, Gitlab-ը ձեզ հարմարավետություն կբերեն: Դուք կտեսնեք, որ ժողովը հավաքված է կամ չի հավաքվել: Նրանք կարող են օգնել ձեզ, բայց նրանք չեն տա ձեզ պրակտիկա: Նրանք կարող են ձեզ միայն շրջան տալ - Ok, ոչ Ok: Եվ հետո, եթե դուք նույնպես գրում եք թեստեր, քանի որ եթե չկան թեստեր, ապա դա գրեթե անիմաստ է։ Հետևաբար, դա անհրաժեշտ է, քանի որ ավելի հարմար է, բայց ընդհանուր առմամբ առանց դրա կարող ես ապրել, շատ բան չես կորցնի։

Այսինքն, եթե դուք ունեք պրակտիկա, դա նշանակում է, որ դուք դրա կարիքը չունե՞ք:

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

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

Նույնիսկ այնպես չէ, որ դա պետք է լինի, դա հիանալի կլիներ, քանի որ դա նույն կերպ կհեշտացներ կյանքը: Հենց կոդով ենք աշխատում, ոչ թե bash սկրիպտներով, այլ նորմալ կոդ ունենք։

Stop, stop, bash script-ը նույնպես կոդ է։ Մի դիպչիր իմ հին սիրուն:

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

Հենց որ մենք աշխատում ենք ենթակառուցվածքի հետ որպես կոդ, մենք ստանում ենք նույն խնդիրները, ինչ մշակողները: Մի քանի ամիս առաջ ես հանդիպեցի մի իրավիճակի, երբ գործընկերս ինձ ուղարկեց 1 տող բաշի խնդրանք: Եվ դուք 000 ժամ հանգստանում եք ստուգատեսում: Նույն խնդիրներն են առաջանում. Դեռ կոդ է: Եվ դա դեռ համագործակցություն է: Մենք խրվում ենք ձգման խնդրանքով և խրվում ենք այն փաստով, որ մենք, օրինակ, նույն բաշում լուծում ենք միաձուլման նույն հակամարտությունները:

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

Եթե ​​որևէ մեկը հարցեր ունի:

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

(Օլեգ) Այո, այդպես է: Այս պրակտիկան համեմատելի է մշակույթը փոխող ցանկացած այլ լուրջ պրակտիկայի հետ: Ամենադժվարը հաղթահարելը սովորություններն են, հատկապես վատ սովորությունները: Իսկ եթե այս պրակտիկան կյանքի կոչելու համար անհրաժեշտ է շրջապատողների՝ ծրագրավորողների, ղեկավարության, արտադրության մենեջերի բարքերի լուրջ փոփոխություն, ապա ձեզ անակնկալներ են սպասվում։

Ի՞նչ անակնկալներ կարող են լինել: Ասենք որոշել եք, որ ավելի հաճախ եք ինտեգրվելու։ Եվ դուք ունեք մի քանի այլ բաներ, որոնք կապված են ինտեգրման հետ, օրինակ՝ արտեֆակտներ: Եվ ձեր ընկերությունում, օրինակ, կա մի քաղաքականություն, ըստ որի յուրաքանչյուր արտեֆակտ պետք է ինչ-որ կերպ հաշվառվի արտեֆակտի պահպանման որևէ համակարգում: Եվ դա որոշակի ժամանակ է պահանջում: Մարդը պետք է ստուգի այն վանդակը, որ նա՝ որպես թողարկման մենեջեր, փորձարկել է այս արտեֆակտը՝ համոզվելու համար, որ այն պատրաստ է թողարկման համար: Եթե ​​տեւում է 5-10-15 րոպե, բայց դասավորությունն անում ես շաբաթը մեկ, ապա շաբաթը մեկ անգամ կես ժամ ծախսելը փոքր հարկ է։

Եթե ​​դուք անում եք Continuous Integration օրական 10 անգամ, ապա 10 անգամ պետք է բազմապատկել 30 րոպեով: Եվ սա գերազանցում է այս թողարկման մենեջերի աշխատաժամանակը: Նա պարզապես հոգնում է դա անելուց: Որոշ պրակտիկաների համար կան հաստատուն ծախսեր: Այսքանը:

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

Եվ եթե որևէ մեկից ապացույցի կարիք ունեք, որպեսզի ղեկավարը ստորագրի այն, և դուք չմտնեք արտադրություն առանց Վասյան ասելու, որ նա թույլ է տալիս և այլն, այս բոլոր անհեթեթությունները խանգարում են պրակտիկանտին: Որովհետև եթե հարկի հետ կապված ինչ-որ գործունեություն կա, ապա ամեն ինչ 100 անգամ ավելանում է։ Ուստի հերթափոխը հաճախ ոչ բոլորի կողմից կդիմավորվի ուրախությամբ։ Քանի որ մարդկանց սովորությունները դժվար է փոխել:

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

Հետևաբար, ամենապարզը, թեև ոչ բոլորը կարող են իրենց թույլ տալ այս շքեղությունը, բայց սա այն է, ինչ ես միշտ անում եմ, սա հետևյալն է. Եթե ​​սկսվում է նոր նախագիծ, ապա սովորաբար բոլոր չստուգված պրակտիկաները անմիջապես խցկվում են այս նախագծի մեջ: Քանի դեռ նախագիծը երիտասարդ է, մենք իրականում ոչինչ չենք վտանգում: Պրոդ դեռ չկա, ոչնչացնելու բան չկա։ Հետեւաբար, այն կարող է օգտագործվել որպես մարզում: Այս մոտեցումն աշխատում է: Բայց ոչ բոլոր ընկերություններն ունեն նման նախագծեր հաճախ սկսելու հնարավորություն։ Թեև սա նույնպես մի փոքր տարօրինակ է, քանի որ այժմ տեղի է ունենում ամբողջական թվային վերափոխում, բոլորը պետք է փորձեր սկսեն մրցակիցներից հետ չմնալու համար։

Այստեղ դուք գալիս եք այն եզրակացության, որ նախ պետք է հասկանալ, թե ինչ պետք է անեք: Աշխարհն իդեալական չէ, իսկ պրոդը նույնպես իդեալական չէ։

Այո, այս բաները փոխկապակցված են։

Բիզնեսները նույնպես միշտ չէ, որ հասկանում են, որ պետք է գնան այս ճանապարհով:

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

(Դմիտրի) Ես կկարդամ պարզաբանում զրույցից. «Բայց մեզ անհրաժեշտ է շատ թեստային լուսաբանում տարբեր մակարդակներում: Որքա՞ն ժամանակ է հատկացվում թեստերին: Դա մի փոքր թանկ է և շատ ժամանակ է պահանջում»:

(Օլեգ) Սա դասական սխալ պատկերացում է: Պետք է լինեն բավականաչափ թեստեր, որպեսզի վստահ լինեք: Շարունակական ինտեգրումն այն չէ, երբ նախ թեստերի 100%-ը կատարվում է, և միայն դրանից հետո դուք սկսում եք կիրառել այս պրակտիկան: Շարունակական ինտեգրումը նվազեցնում է ձեր ճանաչողական ծանրաբեռնվածությունը, քանի որ յուրաքանչյուր փոփոխություն, որը տեսնում եք ձեր աչքերով, այնքան ակնհայտ է, որ դուք հասկանում եք, թե դա ինչ-որ բան կոտրելու է, թե ոչ, նույնիսկ առանց թեստերի: Դուք կարող եք արագ փորձարկել դա ձեր գլխում, քանի որ փոփոխությունները փոքր են: Նույնիսկ եթե դուք ունեք միայն ձեռքով փորձարկողներ, նրանց համար նույնպես ավելի հեշտ է: Դուրս եկար ու ասացիր. Ստուգել են, ասել են՝ ոչ, ոչինչ չի կոտրվել։ Քանի որ փորձարկողը գիտի, թե որտեղ պետք է փնտրել: Դուք ունեք մեկ պարտավորություն՝ կապված մեկ կոդի հետ: Եվ դա շահարկվում է կոնկրետ պահվածքով։

Այստեղ դուք, իհարկե, զարդարեցիք:

(Դմիտրի) Ես այստեղ համաձայն չեմ: Կա մի պրակտիկա՝ թեստի վրա հիմնված զարգացում, որը ձեզ կփրկի դրանից։

(Օլեգ) Դե, ես դեռ չեմ հասել այդ կետին: Առաջին պատրանքն այն է, որ դուք պետք է գրեք թեստերի 100%-ը, կամ ընդհանրապես կարիք չկա անելու շարունակական ինտեգրում: Դա ճիշտ չէ։ Սրանք երկու զուգահեռ պրակտիկա են: Եվ նրանք ուղղակիորեն կախված չեն: Ձեր թեստի ծածկույթը պետք է լինի օպտիմալ: Օպտիմալ - սա նշանակում է, որ դուք ինքներդ վստահ եք, որ վարպետի որակը, որում ձեր վարպետը մնաց պարտավորությունից հետո, թույլ է տալիս վստահորեն սեղմել «Տեղակայել» կոճակը հարբած ուրբաթ երեկոյան: Ինչպե՞ս եք դրան հասնում: Վերանայման, լուսաբանման, լավ մոնիտորինգի միջոցով:

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

Եվ հետևաբար, թե կոնկրետ ինչպես կհասնեք այս վիճակին, երբ պատրաստվեք ուրբաթ երեկոյան և գնաք տուն, այլ հարց է։ Գուցե դուք պարզապես համարձակ տականք եք:

Եկեք մի փոքր հետ գնանք Continuous Integration-ին: Մենք փախանք մի փոքր այլ բարդ պրակտիկայի մեջ:

Իսկ երկրորդ պատրանքն այն է, որ MVP-ն, ասում են, պետք է արագ անել, ուստի թեստեր այնտեղ ընդհանրապես պետք չեն։ Ոչ, իհարկե, այդ կերպ: Փաստն այն է, որ երբ դուք գրում եք օգտատիրոջ պատմությունը MVP-ում, կարող եք կամ զարգացնել այն գնդակի վրա, այսինքն՝ լսել եք, որ ինչ-որ օգտվողի պատմություն կա և անմիջապես վազել եք այն կոդավորելու, կամ կարող եք աշխատել TDD-ի միջոցով: Եվ ըստ TDD-ի, ինչպես ցույց է տալիս պրակտիկան, դա ավելի երկար չի տևում, այսինքն՝ թեստերը կողմնակի ազդեցություն են: TDD-ի պրակտիկան կապված չէ թեստավորման հետ: Չնայած այն, ինչ կոչվում է Test Driven Development, դա ամենևին էլ թեստերի մասին չէ: Սա նույնպես ավելի շուտ ճարտարապետական ​​մոտեցում է։ Սա մոտեցում է գրելու հենց այն, ինչ պետք է, և չգրելու այն, ինչ պետք չէ: Սա կիրառական ճարտարապետություն ստեղծելու առումով ձեր մտածողության հաջորդ կրկնության վրա կենտրոնանալու պրակտիկա է:

Ուստի այս պատրանքներից ազատվելն այնքան էլ հեշտ չէ։ MVP-ն և թեստերը չեն հակասում միմյանց. Նույնիսկ, ավելի շուտ, ընդհակառակը, եթե դուք MVP եք անում TDD պրակտիկայի միջոցով, ապա դա կանեք ավելի լավ և արագ, քան եթե դա անեք ընդհանրապես առանց վարժությունների, բայց գնդակի վրա:

Սա շատ ոչ ակնհայտ և բարդ գաղափար է։ Երբ լսում ես, որ հիմա ես ավելի շատ թեստեր կգրեմ և միևնույն ժամանակ ավելի արագ ինչ-որ բան կանեմ, դա բացարձակապես ոչ ադեկվատ է հնչում։

(Դմիտրի) Այստեղ շատերը, երբ MVP են կանչում, մարդիկ չափազանց ծույլ են նորմալ բան գրել: Եվ սրանք դեռ տարբեր բաներ են։ Կարիք չկա MVP-ին վերածել ինչ-որ վատ բանի, որը չի աշխատում:

Այո, այո, դու ճիշտ ես։

Եվ հետո հանկարծ MVP արդ.

Ընդմիշտ.

Եվ TDD-ն շատ անսովոր է հնչում, երբ լսում ես, որ թեստեր ես գրում և թվում է, թե ավելի շատ աշխատանք ես կատարում: Շատ տարօրինակ է հնչում, բայց իրականում այսպես ավելի արագ ու գեղեցիկ է ստացվում։ Երբ դուք գրում եք թեստ, արդեն ձեր գլխում շատ եք մտածում, թե ինչ կոդ և ինչպես է կոչվելու, ինչպես նաև ինչ վարքագիծ ենք ակնկալում դրանից։ Դուք միայն չեք ասում, որ ես ինչ-որ ֆունկցիա եմ գրել, և դա ինչ-որ բան է անում: Սկզբում մտածում էիր, որ նա այսինչ պայմաններ ունի, նրան այսինչ ձևով կկանչեն։ Դուք սա ծածկում եք թեստերով և դրանից հասկանում եք, թե ինչպես են ձեր ինտերֆեյսները ձեր կոդի ներսում: Սա հսկայական ազդեցություն ունի ճարտարապետության վրա: Ձեր կոդը ավտոմատ կերպով դառնում է ավելի մոդուլային, քանի որ նախ փորձում եք հասկանալ, թե ինչպես եք այն փորձարկելու, և միայն դրանից հետո գրել այն։

Այն, ինչ պատահեց ինձ հետ TDD-ի հետ, այն էր, որ ինչ-որ պահի ես վարձեցի Ruby մենթոր, երբ դեռ Ruby ծրագրավորող էի: Եվ նա ասում է. «Եկեք դա անենք TDD-ի համաձայն»: Ես մտածեցի. «Անիծյալ, հիմա ես պետք է ավելորդ բան գրեմ»: Եվ մենք պայմանավորվեցինք, որ երկու շաբաթվա ընթացքում ես կգրեմ բոլոր աշխատանքային ծածկագիրը Python-ում՝ օգտագործելով TDD: Երկու շաբաթ անց ես հասկացա, որ չեմ ուզում վերադառնալ։ Երկու շաբաթ փորձելով սա կիրառել ամենուր, դուք հասկանում եք, թե որքան հեշտ է ձեզ համար նույնիսկ պարզապես մտածելը: Բայց սա ակնհայտ չէ, ուստի ես խորհուրդ եմ տալիս բոլորին, որ եթե զգում եք, որ TDD-ն դժվար է, ժամանակատար և ավելորդ, փորձեք հավատարիմ մնալ դրան ընդամենը երկու շաբաթ: Երկուսն ինձ բավական էին։

(Դմիտրի) Մենք կարող ենք ընդլայնել այս գաղափարը ենթակառուցվածքների շահագործման տեսանկյունից: Նախքան որևէ նոր բան գործարկելը, մենք մոնիտորինգ ենք անում, այնուհետև մեկնարկում: Այս դեպքում մոնիտորինգը մեզ համար դառնում է սովորական թեստավորում։ Իսկ մոնիտորինգի միջոցով զարգացում կա։ Բայց գրեթե բոլորն ասում են, որ երկար է, ես ծույլ եմ, ժամանակավոր նախագիծ եմ արել: Եթե ​​նորմալ մոնիտորինգ ենք արել, հասկանում ենք ԿԻ համակարգի վիճակը։ Իսկ CI համակարգը շատ մոնիտորինգ ունի։ Մենք հասկանում ենք համակարգի վիճակը, հասկանում ենք, թե ինչ կա դրա ներսում։ Իսկ զարգացման ընթացքում մենք պարզապես համակարգը դարձնում ենք այնպես, որ այն հասնի ցանկալի վիճակին։

Այս պրակտիկաները հայտնի են վաղուց: Մենք դա քննարկել ենք մոտ 4 տարի առաջ։ Բայց 4 տարվա ընթացքում գործնականում ոչինչ չի փոխվել։

Բայց այս նոտայում առաջարկում եմ ավարտել պաշտոնական քննարկումը։

Տեսանյութ (տեղադրված է որպես մեդիա տարր, բայց ինչ-ինչ պատճառներով չի աշխատում).

https://youtu.be/zZ3qXVN3Oic

Source: www.habr.com