Սովորե՞լ եք Git հրամանները, բայց ուզում եք պատկերացնել, թե ինչպես է իրականում աշխատում շարունակական ինտեգրումը (CI): Կամ գուցե դուք ցանկանում եք օպտիմալացնել ձեր ամենօրյա գործունեությունը: Այս դասընթացը ձեզ գործնական հմտություններ կտա շարունակական ինտեգրման համար՝ օգտագործելով GitHub պահեստը: Այս դասընթացը նախատեսված չէ որպես կախարդ, որի վրա դուք կարող եք պարզապես սեղմել, ընդհակառակը, դուք կկատարեք նույն գործողությունները, որոնք մարդիկ իրականում անում են աշխատավայրում, ինչպես դա անում են: Ես կբացատրեմ տեսությունը, երբ դուք անցնեք ներգրավված քայլերը:

Ի՞նչ ենք մենք անում։

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

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

Դուք կանցնեք հետևյալ ստանդարտ CI սցենարների միջով.

• Աշխատել հատկանիշի վրա;
• Որակի ապահովման համար ավտոմատացված թեստերի կիրառում;
• Առաջնահերթ առաջադրանքի իրականացում;
• Կոնֆլիկտների լուծում մասնաճյուղերի միաձուլման ժամանակ (միաձուլման հակամարտություն);
• Արտադրական միջավայրում տեղի է ունենում սխալ:

Ի՞նչ եք սովորելու։

Դուք կկարողանաք պատասխանել հետևյալ հարցերին.

• Ի՞նչ է շարունակական ինտեգրումը (CI):
• Ավտոմատացված թեստերի ի՞նչ տեսակներ են օգտագործվում CI-ում և ի պատասխան ի՞նչ գործողությունների են դրանք գործարկվում:
• Որո՞նք են ձգման հարցումները և երբ են դրանք անհրաժեշտ:
• Ի՞նչ է թեստի վրա հիմնված զարգացումը (TDD) և ինչպե՞ս է այն կապված CI-ի հետ:
• Պե՞տք է միաձուլվե՞մ, թե՞ վերահիմնավորեմ փոփոխությունները:
• Հետ գլորե՞լ, թե՞ ուղղել հաջորդ տարբերակում:

Սկզբում ես ամենուր թարգմանում էի «pull requests» բառերը, բայց արդյունքում որոշեցի որոշ տեղերում վերադարձնել անգլերեն արտահայտություններ՝ տեքստի խելագարության աստիճանը նվազեցնելու համար: Ես երբեմն կօգտագործեմ «ծրագրավորող սուրժիկ»-ը, ինչպես հրաշալի «կատարել» բայը, որտեղ մարդիկ իրականում այն ​​օգտագործում են աշխատանքի ժամանակ:

Ի՞նչ է շարունակական ինտեգրումը:

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

Այս եզրույթի շուրջ տարաձայնություններ կան

Վիճելի կետը ինտեգրման հաճախականությունն է: Ոմանք պնդում են, որ կոդերի միաձուլումը միայն օրական մեկ անգամ բավարար չէ անընդհատ ինտեգրվելու համար: Տրված է թիմի օրինակ, որտեղ բոլորն առավոտյան վերցնում են թարմ ծածկագիրը և ինտեգրում այն ​​երեկոյան մեկ անգամ: Թեև սա ողջամիտ առարկություն է, ընդհանուր առմամբ ենթադրվում է, որ օրական մեկ անգամ սահմանումը ողջամտորեն գործնական է, հատուկ և հարմար է տարբեր չափերի թիմերի համար:

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

Շարունակական ինտեգրում տարբերվում է շարունակական առաքում (Շարունակական առաքում, CD), քանի որ այն չի պահանջում թողարկման թեկնածու յուրաքանչյուր ինտեգրման ցիկլից հետո:

Քայլերի ցանկը, որոնք մենք կօգտագործենք դասընթացի ընթացքում

1. Քաշեք վերջին կոդը: Ստեղծեք մասնաճյուղ master. Սկսեք աշխատել:
2. Ստեղծեք պարտավորություններ ձեր նոր մասնաճյուղում: Կառուցեք և փորձարկեք տեղում: Անձնագիր? Անցեք հաջորդ քայլին: Ձախողվել? Ուղղեք սխալները կամ թեստերը և նորից փորձեք:
3. Հրել դեպի ձեր հեռավոր պահեստ կամ հեռավոր մասնաճյուղ:
4. Ստեղծեք ձգման հարցում: Քննարկեք փոփոխությունները, ավելացրեք ավելի շատ պարտավորություններ, քանի դեռ քննարկումը շարունակվում է: Թող թեստերն անցնեն հատկանիշի ճյուղում:
5. Միաձուլման/վերաբացման պարտավորությունները վարպետից: Թող թեստերն անցնեն միաձուլման արդյունքի վրա:
6. Տեղակայել խաղարկային ճյուղից մինչև արտադրություն:
7. Եթե ​​ամեն ինչ լավ է արտադրության մեջ որոշակի ժամանակահատվածում, միաձուլեք փոփոխությունները վարպետության համար:

️ Պատրաստում

Համոզվեք, որ ունեք ճիշտ ծրագրակազմ

Այս դասընթացն անցնելու համար ձեզ հարկավոր է Node.js и Git հաճախորդ.

Դուք կարող եք օգտագործել ցանկացած Git հաճախորդ, բայց ես միայն հրամաններ կտամ հրամանի տողի համար:

Համոզվեք, որ ունեք տեղադրված Git հաճախորդ, որն աջակցում է հրամանի տողը

Եթե ​​դուք դեռ չունեք Git հաճախորդ, որն աջակցում է հրամանի տողին, կարող եք գտնել տեղադրման հրահանգներ այստեղ.

Պատրաստեք պահեստը

Ձեզ անհրաժեշտ է ստեղծել անձնական պատճեն (պատառաքաղ) կաղապարի պահեստ՝ դասընթացի կոդով GitHub-ում: Եկեք համաձայնվենք անվանել այս անձնական պատճենը դասընթացի պահոց.

Կատարած? Եթե ​​դուք չեք փոխել լռելյայն կարգավորումները, ձեր դասընթացի պահոցը, ամենայն հավանականությամբ, կոչվում է continuous-integration-team-scenarios-students, այն գտնվում է ձեր GitHub հաշվում և URL-ն այսպիսի տեսք ունի

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

Ես ուղղակի կզանգեմ այս հասցեով <URL репозитория>.

Անկյունային փակագծերը նման են <тут> կնշանակի, որ դուք պետք է փոխարինեք նման արտահայտությունը համապատասխան արժեքով։

Համոզվեք, որ դա GitHub գործողություններ ներառված է այս դասընթացի պահեստի համար: Եթե ​​դրանք միացված չեն, խնդրում ենք միացնել դրանք՝ սեղմելով էջի մեջտեղում գտնվող մեծ կոճակը, որին կարող եք հասնել՝ սեղմելով «Գործողություններ» GitHub ինտերֆեյսում:

Դուք չեք կարողանա ավարտել դասընթացը՝ հետևելով իմ հրահանգներին, եթե GitHub Actions-ը միացված չէ:

Դուք միշտ կարող եք օգտագործել GitHub-ի հնարավորությունը՝ ցուցադրելու Markdown-ը, որպեսզի տեսնեք ցուցակի ներկա վիճակը, որը մենք կազմում ենք այստեղ:

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

Պատասխանների մասին

Թեև այս դասընթացն ավարտելու լավագույն միջոցը դա ինքներդ անելն է, դուք կարող եք որոշակի դժվարություններ ունենալ:

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

Օգտագործեք սա միայն այն դեպքում, եթե իսկապես դրա կարիքն ունեք

Ընդունեք ձեր կոդը

git add .
git commit -m "Backing up my work"

Այս հրամանները

• վերանվանել master в master-backup;
• վերանվանել solution в master;
• վճարել նոր մասնաճյուղ master և վերաշարադրել աշխատանքային գրացուցակի բովանդակությունը.
• Ստեղծեք «լուծում» ճյուղ «վարպետից» (որը նախկինում «լուծում» էր) այն դեպքում, եթե ապագայում «լուծման» ճյուղի կարիք ունեք:

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

Այս քայլերից հետո կարող եք օգտագործել git log master պարզելու համար, թե որ պարտավորությունն է ձեզ անհրաժեշտ:
Դուք կարող եք վերականգնել ձեր աշխատանքային գրացուցակը այս կոմիտին այսպես.

git reset --hard <the SHA you need>

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

git push --force origin master

Խնդրում ենք նկատի ունենալ, որ մենք օգտագործում ենք git push --force. Քիչ հավանական է, որ դուք ցանկանաք դա անել շատ հաճախ, բայց մենք այստեղ ունենք շատ կոնկրետ սցենար մեկ պահեստի օգտագործողի հետ, ով բացի այդ, հասկանում է, թե ինչ է անում:

Սկսելով աշխատել

Եկեք սկսենք կազմել CI քայլերի մեր ցուցակը: Սովորաբար դուք այս քայլը կսկսեք՝ ստուգելով կոդի վերջին տարբերակը հեռավոր պահոցից, բայց մենք դեռ չունենք տեղական պահոց, դրա փոխարեն մենք այն կլոնավորում ենք հեռավոր պահոցից:

️ Առաջադրանք՝ թարմացնել տեղական պահոցը, ստեղծել մասնաճյուղ master, սկսեք աշխատել

1. Կլոնավորեք դասընթացի պահոցը <URL репозитория>.
2. Վազել npm install դասընթացի պահեստի գրացուցակում; Մեզ այն պետք է Jest-ը տեղադրելու համար, որն օգտագործում ենք թեստերն իրականացնելու համար:
3. Ստեղծեք մասնաճյուղ և անվանեք այն feature. Անցեք այս թեմային:

4. Ավելացնել թեստի կոդը ci.test.js մեկնաբանությունների միջև, որոնք ինձ խնդրում են դա անել:

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. Ֆայլին ավելացրեք տեքստ առաջին 4 քայլերով ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   Հրամաններ

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

Ստեղծեք պարտավորություններ նոր մասնաճյուղում, կառուցեք և փորձարկեք տեղում

Մենք պատրաստվում ենք կարգավորել թեստերը, որպեսզի գործարկվեն նախքան կատարելը, այնուհետև մուտքագրենք կոդը:

Տիպիկ սցենարներ, երբ թեստերն աշխատում են ավտոմատ կերպով

• Տեղական:
  • Անընդհատ կամ ի պատասխան կոդի համապատասխան փոփոխությունների.
  • Խնայողության մասին (մեկնաբանված կամ JIT-կազմված լեզուների համար);
  • Հավաքման ժամանակ (երբ անհրաժեշտ է կազմում);
  • Պարտավորության վրա;
  • Համօգտագործվող պահեստում հրապարակելիս:

• Կառուցման սերվերի կամ կառուցման միջավայրում.
  • Երբ կոդը հրապարակվում է անձնական մասնաճյուղում/պահեստում:
  • Այս թեմայի կոդը փորձարկվում է:
  • Միաձուլման հնարավոր արդյունքը փորձարկվում է (սովորաբար հետ master).
  • Որպես շարունակական ինտեգրման փուլ/շարունակական առաքում

Սովորաբար, որքան արագ է աշխատում թեստային փաթեթը, այնքան ավելի հաճախ կարող եք թույլ տալ այն գործարկել: Տիպիկ փուլային բաշխումը կարող է այսպիսի տեսք ունենալ.

• Արագ միավորի փորձարկումներ - կառուցման ընթացքում, CI խողովակաշարում
• Դանդաղ միավորի փորձարկումներ, արագ բաղադրիչի և ինտեգրման թեստեր - կատարման ժամանակ, CI խողովակաշարում
• Դանդաղ բաղադրիչի և ինտեգրման թեստեր - CI խողովակաշարում
• Անվտանգության փորձարկում, բեռնվածության փորձարկում և այլ ժամանակատար կամ թանկ փորձարկումներ՝ CI/CD խողովակաշարերում, բայց միայն կառուցման որոշակի ռեժիմներում/փուլերում/խողովակաշարերում, օրինակ՝ թողարկման թեկնածու պատրաստելիս կամ ձեռքով աշխատելիս:

️Առաջադրանք

Առաջարկում եմ թեստերը նախ ձեռքով գործարկել՝ օգտագործելով հրամանը npm test. Դրանից հետո, եկեք ավելացնենք git hook, որպեսզի կատարենք մեր թեստերը commit-ի վրա: Մի բան կա. Git կեռիկները չեն համարվում պահեստի մաս և, հետևաբար, չեն կարող կլոնավորվել GitHub-ից դասընթացի մնացած նյութերի հետ միասին: Կեռիկ տեղադրելու համար անհրաժեշտ է վազել install_hook.sh կամ պատճենեք ֆայլը repo/hooks/pre-commit դեպի տեղական գրացուցակ .git/hooks/.
Երբ դուք պարտավորվում եք, կտեսնեք, որ թեստերն անցկացվում են, և նրանք ստուգում են՝ արդյոք որոշակի հիմնաբառեր առկա են ցանկում:

1. Գործարկեք թեստերը ձեռքով` գործարկելով հրամանը npm test ձեր դասընթացի պահոցում: Ստուգեք, որ թեստերն ավարտված են:
2. Սահմանեք commit hook (pre-commit hook)՝ վազելով install_hook.sh.
3. Կատարեք ձեր փոփոխությունները ձեր տեղական պահեստում:
4. Համոզվեք, որ թեստերն իրականացվել են նախքան կատարելը:

Այս քայլերը կատարելուց հետո ձեր պահեստը պետք է այսպիսի տեսք ունենա:

Հրամաններ

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

Հրապարակեք կոդը հեռավոր պահեստում կամ հեռավոր մասնաճյուղում

Տեղական աշխատանքի ավարտից հետո մշակողները սովորաբար իրենց ծածկագիրը հանրությանը հասանելի են դարձնում, որպեսզի այն ի վերջո կարողանա ինտեգրվել հանրության հետ: GitHub-ի հետ դա սովորաբար ձեռք է բերվում՝ աշխատանքը հրապարակելով կա՛մ պահոցի (անձնական պատառաքաղ) անձնական օրինակում, կա՛մ անձնական մասնաճյուղում:

• Պատառաքաղների միջոցով ծրագրավորողը կլոնավորում է հեռավոր ընդհանուր պահոցը՝ ստեղծելով դրա անձնական հեռատիպ պատճենը, որը նաև հայտնի է որպես պատառաքաղ: Այնուհետև այն կլոնավորում է այս անձնական շտեմարանը՝ տեղում աշխատելու համար: Երբ աշխատանքն ավարտվում է, և պարտավորությունները կատարվում են, նա դրանք մղում է իր պատառաքաղի մեջ, որտեղ դրանք հասանելի են ուրիշների համար և կարող են ինտեգրվել ընդհանուր պահոցում: Այս մոտեցումը սովորաբար օգտագործվում է GitHub-ի բաց կոդով նախագծերում: Այն նաև օգտագործվում է իմ առաջադեմ դասընթացում [Team Work and CI with Git] (http://devops.redpill.solutions/).
• Մեկ այլ մոտեցում է օգտագործել միայն մեկ հեռավոր պահոց և հաշվել միայն մասնաճյուղը master համօգտագործվող պահեստը «պաշտպանված է»: Այս սցենարում առանձին մշակողները հրապարակում են իրենց կոդը հեռավոր պահեստի մասնաճյուղերում, որպեսզի մյուսները կարողանան նայել այս կոդը, եթե ամեն ինչ կարգին է, միաձուլեք այն։ master ընդհանուր պահոց:

Այս կոնկրետ դասընթացում մենք կօգտագործենք աշխատանքային հոսք, որն օգտագործում է ճյուղեր:

Եկեք հրապարակենք մեր կոդը։

️Առաջադրանք

• Հրապարակեք փոփոխությունները հեռավոր մասնաճյուղում, որը նույն անունով է, ինչ ձեր աշխատանքային մասնաճյուղը

Հրամաններ

git push --set-upstream origin feature

Ստեղծեք ձգման հարցում

Ստեղծեք ձգման հարցում վերնագրով Քայլերի վերանայում... Տեղադրեք feature ինչպես «գլուխ ճյուղ» և master ինչպես «բազային ճյուղը»:

Համոզվեք, որ դուք տեղադրել եք master իր մեջ պատառաքաղել պահեստը Որպես «բազային մասնաճյուղ», ես չեմ պատասխանի դասընթացի նյութերի պահոցում փոփոխություններ կատարելու հարցումներին:

GitHub lingo-ում «բազային ճյուղը» այն ճյուղն է, որի վրա հիմնում եք ձեր աշխատանքը, իսկ «գլխավոր ճյուղը» այն ճյուղն է, որը պարունակում է առաջարկվող փոփոխությունները:

Քննարկեք փոփոխությունները, ավելացրեք նոր պարտավորություններ, քանի դեռ քննարկումը շարունակվում է

Ձգման հարցում (PR)

Ձգման հարցում (PR) Կոդեքսը քննարկելու և փաստաթղթավորելու, ինչպես նաև օրենսգրքի վերանայում իրականացնելու միջոց է: Ձգվող հարցումները կոչվում են անհատական ​​փոփոխություններն ընդհանուր կոդի մեջ ինտեգրելու ընդհանուր եղանակով: Սովորաբար, մարդը կլոնավորում է ծրագրի հեռավոր պաշտոնական պահոցը և աշխատում է կոդի վրա տեղական մակարդակում: Դրանից հետո նա տեղադրում է կոդը իր անձնական հեռավոր պահոցում և խնդրում է պաշտոնական պահեստի պատասխանատուներին վերցնել (քաշել) դրա կոդը իրենց տեղական պահոցներում, որտեղ նրանք վերանայում և, հնարավոր է, ինտեգրում են (ընկղմել) իր. Այս հասկացությունը հայտնի է նաև այլ անուններով, օրինակ. միաձուլման հարցում.

Դուք իրականում պարտադիր չէ, որ օգտագործեք GitHub-ի կամ նմանատիպ հարթակների ձգման խնդրանքը: Զարգացման թիմերը կարող են օգտագործել հաղորդակցության այլ մեթոդներ, ներառյալ դեմ առ դեմ հաղորդակցությունը, ձայնային զանգերը կամ էլ. Ահա դրանցից մի քանիսը.

• կազմակերպել քննարկումներ՝ կապված կոնկրետ օրենսգրքի փոփոխությունների հետ.
• որպես կատարվող աշխատանքների վերաբերյալ կարծիքներ դիտելու վայր ինչպես ինքնափորձարկողների, այնպես էլ հասակակիցների կողմից.
• կոդերի վերանայման պաշտոնականացում;
• որպեսզի հետո կարողանաս պարզել այս կամ այն ​​կոդի հիմքում ընկած պատճառներն ու նկատառումները։

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

Որպես կանոն, PR ստեղծելիս դուք անում եք հետևյալը.

• Նշեք, թե ինչ եք առաջարկում փոխել և որտեղ:
• Գրեք նկարագրություն՝ բացատրելով փոփոխությունների նպատակը: Դուք կարող եք ցանկանալ.
  • ավելացրեք որևէ կարևոր բան, որը ակնհայտ չէ կոդից, կամ ինչ-որ օգտակար բան կոնտեքստը հասկանալու համար, օրինակ՝ համապատասխան #bugs և commit համարներ.
  • @նշեք նրանց, ում հետ ցանկանում եք սկսել աշխատել, կամ կարող եք @նշել նրանց մեկնաբանություններում ավելի ուշ;
  • խնդրեք գործընկերներին օգնել ինչ-որ բանով կամ ստուգել որևէ կոնկրետ բան:

PR-ը բացելուց հետո նման դեպքերում գործարկելու համար կազմաձևված թեստերը կատարվում են: Մեր դեպքում սա կլինի նույն թեստերի փաթեթը, որը մենք անցկացրինք տեղական մակարդակում, բայց իրական նախագծում կարող են լինել լրացուցիչ թեստեր և ստուգումներ:

Խնդրում ենք սպասել, մինչև թեստերն ավարտվեն: Դուք կարող եք տեսնել թեստերի կարգավիճակը PR քննարկման ներքևում՝ GitHub ինտերֆեյսում: Շարունակեք, երբ թեստերն ավարտվեն:

️ Նշում ավելացրեք CI քայլերի ցանկի պատահականության մասին

Այս դասընթացում օգտագործված ցանկը կամայական է և սուբյեկտիվ, այս մասին պետք է ավելացնել նշում։

️ Առաջադրանք՝ այս մեկնաբանության համար ստեղծեք ձգման հարցում

1. Անցում մասնաճյուղի master.
2. Ստեղծեք մասնաճյուղ անունով bugfix.
3. Նշման տեքստ ավելացրեք ֆայլի վերջում ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. Կատարեք փոփոխությունները:
5. Հրապարակեք շարանը bugfix դեպի հեռավոր պահեստ:
6. Ստեղծեք ձգման հարցում անունով Դիտողություն ավելացնելով գլխի ճյուղով bugfix և բազային ճյուղըmaster.

Համոզվեք, որ դուք տեղադրել եք master իր մեջ պատառաքաղել պահեստը Որպես «բազային մասնաճյուղ», ես չեմ պատասխանի դասընթացի նյութերի պահոցում փոփոխություններ կատարելու հարցումներին:

Ահա թե ինչպիսին պետք է լինի ձեր պահոցը:

Հրամաններ

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

Հաստատել «Դիտողություն ավելացնելու» պահանջը

️Առաջադրանք

1. Ստեղծեք ձգման հարցում:
2. Սեղմեք «Միաձուլման ձգման հարցումը»:
3. Սեղմեք «Հաստատեք միաձուլումը»:
4. Սեղմեք «Ջնջել մասնաճյուղը», մենք այլևս դրա կարիքը չունենք:

Սա միաձուլումից հետո կատարվող պարտավորությունների դիագրամ է:

️ Շարունակեք աշխատել և ավելացնել թեստեր

Քաշի խնդրանքով համագործակցելը հաճախ հանգեցնում է լրացուցիչ աշխատանքի: Սա սովորաբար կոդի վերանայման կամ քննարկման արդյունք է, բայց մեր դասընթացում մենք պատրաստվում ենք դա մոդելավորել՝ ավելացնելով նոր տարրեր մեր CI քայլերի ցանկում:

Շարունակական ինտեգրումը սովորաբար ներառում է որոշակի թեստային ծածկույթ: Թեստի ծածկույթի պահանջները տարբեր են և սովորաբար հանդիպում են մի փաստաթղթում, որը կոչվում է «ներդրումների ուղեցույցներ»: Մենք պարզ կպահենք և մեր ստուգաթերթում կավելացնենք թեստ յուրաքանչյուր տողի համար:

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

Փորձարկման վրա հիմնված զարգացում (TDD)

TDD-ն խորհուրդ է տալիս գրել թեստեր կոդից առաջ: TDD-ի օգտագործմամբ տիպիկ աշխատանքային հոսքն այսպիսի տեսք ունի.

1. Ավելացնել թեստ:
2. Կատարեք բոլոր թեստերը և համոզվեք, որ նոր թեստը ձախողվի:
3. Գրեք կոդը։
4. Անցեք թեստերը, համոզվեք, որ բոլոր թեստերն անցնեն:
5. Վերափոխեք ձեր կոդը:
6. Կրկնել.

Քանի որ անհաջող թեստերի արդյունքները սովորաբար ցուցադրվում են կարմիրով, իսկ անցածները՝ սովորաբար կանաչ, ցիկլը նաև հայտնի է որպես կարմիր-կանաչ-ռեֆակտոր:

️Առաջադրանք

Նախ փորձեք կատարել թեստերը և թույլ տալ, որ դրանք ձախողվեն, ապա ավելացրեք և կատարեք CI քայլերի ցուցակի տեքստը: Դուք կտեսնեք, որ թեստերը անցնում են («կանաչ»):
Այնուհետև հրապարակեք նոր կոդը հեռավոր պահոցում և դիտեք թեստերը GitHub ինտերֆեյսում, որը գտնվում է ձգման հարցման քննարկման և PR կարգավիճակի թարմացման ներքևում:

1. Անցում մասնաճյուղի feature.

2. Ավելացնել այս թեստերը ci.test.js վերջին զանգից հետո it (...);.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. Փորձեք կատարել թեստերը: Եթե pre-commit կեռիկը տեղադրված է, կատարման փորձը չի հաջողվի:
4. Այնուհետև ավելացրեք այս տեքստը ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. Տեղական փոփոխություններ կատարեք և կատարեք:
6. Փոփոխություններ տեղադրեք մասնաճյուղում feature.

Այժմ դուք պետք է ունենաք նման բան

Հրամաններ

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

Միավորել հակամարտությունը

Գնացեք Փոփոխության հարցում Քայլերի վերանայում.

Թեև մենք սխալ բան չենք արել, և մեր կոդի թեստերն անցել են, մենք դեռ չենք կարող միավորել մասնաճյուղը feature и master. Դա այն պատճառով, որ մյուս թեմա bugfix միաձուլվել է master մինչ մենք աշխատում էինք այս PR-ի վրա:
Սա ստեղծում է մի իրավիճակ, երբ հեռավոր մասնաճյուղը master ունի ավելի նոր տարբերակ, քան այն տարբերակը, որի վրա հիմնվել ենք մասնաճյուղը feature. Սրա պատճառով մենք չենք կարող պարզապես ետ շրջել HEAD-ը master մինչև թելի վերջ feature. Այս իրավիճակում մենք պետք է կամ միաձուլենք, կամ կիրառենք պարտավորություններ feature վերահիմնավորում master. GitHub-ը կարող է իրականում իրականացնել ավտոմատ միաձուլումներ, եթե հակասություններ չլինեն: Ավաղ, մեր իրավիճակում երկու մասնաճյուղերն էլ ունեն մրցակցային փոփոխություններ ֆայլում ci.md. Այս իրավիճակը հայտնի է որպես միաձուլման հակամարտություն, և մենք պետք է այն լուծենք ձեռքով:

Միաձուլել կամ վերաբաժանել

Ընկղմել

• Ստեղծում է հավելյալ միաձուլման պարտավորություն և պահպանում է աշխատանքային պատմությունը:
  • Պահպանում է ճյուղի բնօրինակ պարտավորությունները իրենց սկզբնական ժամանակացույցերով և հեղինակներով:
  • Պահպանում է պարտավորությունների SHA-ն և կապում դրանց հետ փոփոխության հարցումների քննարկումներում:
• Պահանջում է կոնֆլիկտի միանգամյա լուծում:
• Պատմությունը դարձնում է ոչ գծային:
  • Պատմությունը կարող է դժվար կարդալ ճյուղերի մեծ քանակի պատճառով (հիշեցնում է IDE մալուխը):
  • Դժվարացնում է ավտոմատ կարգաբերումը, օրինակ. git bisect ավելի քիչ օգտակար - այն կգտնի միայն միաձուլման կատարումը:

Հիմնազուրկ

• Replays-ը կատարում է ընթացիկ ճյուղից մեկը մյուսի հետևից բազային ճյուղի վերևում:
  • Ստեղծվում են նոր պարտավորություններ նոր SHA-ներով, ինչը հանգեցնում է նրան, որ GitHub-ի պարտավորությունները համընկնում են սկզբնական pull հարցումների հետ, բայց ոչ համապատասխան մեկնաբանություններին:
  • Պարտավորությունները կարող են վերահամակցվել և փոփոխվել գործընթացում կամ նույնիսկ միավորվել մեկի մեջ:
• Հնարավոր է, որ անհրաժեշտ լինի լուծել բազմաթիվ հակամարտություններ:
• Թույլ է տալիս պահպանել գծային պատմություն:
  • Պատմությունը կարող է ավելի հեշտ կարդալ, քանի դեռ այն չափազանց երկար չէ առանց ողջամիտ պատճառի:
  • Ավտոմատ կարգաբերումը և անսարքությունների վերացումը մի փոքր ավելի հեշտ է. դա հնարավոր է դարձնում git bisect, կարող է ավելի պարզ և կանխատեսելի դարձնել ավտոմատ հետադարձումները:
• Պահանջում է հրապարակել մասնաճյուղ՝ արտագաղթած պարտավորություններով դրոշով --force երբ օգտագործվում է ձգման հարցումների հետ:

Սովորաբար, թիմերը համաձայնում են միշտ օգտագործել նույն ռազմավարությունը, երբ անհրաժեշտ է փոփոխություններ միավորել: Սա կարող է լինել «մաքուր» միաձուլում կամ «մաքուր» հանձնում վերևում, կամ ինչ-որ բան միջև, օրինակ՝ վերևում կատարվող ինտերակտիվ կերպով (git rebase -i) տեղական մասնաճյուղերի համար, որոնք հրապարակված չեն հանրային շտեմարանում, բայց միաձուլվում են «հանրային» մասնաճյուղերի համար:

Այստեղ մենք կօգտագործենք միաձուլումը:

️Առաջադրանք

1. Համոզվեք, որ կոդը գտնվում է տեղական մասնաճյուղում master թարմացվել է հեռավոր պահոցից:
2. Անցում մասնաճյուղի feature.
3. Նախաձեռնեք միաձուլում մասնաճյուղի հետ master. Միաձուլման հակամարտություն՝ կապված մրցակցային փոփոխությունների հետ ci.md.
4. Լուծեք հակամարտությունը, որպեսզի և՛ մեր CI քայլերի ցանկը, և՛ դրա մասին նշումը մնան տեքստում:
5. Հրապարակեք միաձուլման պարտավորություն հեռավոր մասնաճյուղում feature.
6. Ստուգեք ձգման հարցումի կարգավիճակը GitHub UI-ում և սպասեք մինչև միաձուլումը լուծվի:

Հրամաններ

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

Հիանալի աշխատանք:

Դուք ավարտել եք ցուցակը, և այժմ դուք պետք է հաստատեք ներքաշման հարցումը master.

️ Առաջադրանք. Հաստատել «Քայլերի վերանայում» պահանջը

1. Բացեք ձգման հարցումը:
2. Սեղմեք «Միաձուլման ձգման հարցումը»:
3. Սեղմեք «Հաստատեք միաձուլումը»:
4. Կտտացրեք «Ջնջել մասնաճյուղը», քանի որ այն մեզ այլևս պետք չէ:

Սա ձեր պահոցն է այս պահին

Ապրանքի սխալ

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

Նման սցենարի դեպքում մենք պետք է հոգ տանենք.

• ինչ է տեղակայվում արտադրության մեջ;
• ծածկագիրը թեմայում master սխալով, որից մշակողները կարող են սկսել նոր աշխատանք։

Պե՞տք է հետ գլորեմ, թե՞ ուղղեմ այն ​​հաջորդ տարբերակում:

Հետ վերադարձը նախկինում հայտնի լավ տարբերակի արտադրության մեջ տեղակայելու և սխալ պարունակող պարտավորությունները վերադարձնելու գործընթաց է: «Fixing forward»-ը ֆիքսման հավելումն է master և որքան հնարավոր է շուտ տեղադրել նոր տարբերակը: Քանի որ API-ները և տվյալների բազայի սխեմաները փոխվում են, երբ կոդը տեղադրվում է արտադրության մեջ, շարունակական առաքմամբ և լավ թեստային ծածկույթով, հետ վերադարձը սովորաբար շատ ավելի դժվար և ռիսկային է, քան այն ամրագրելը հաջորդ տարբերակում:

Քանի որ հետ գլորվելը մեր դեպքում որևէ ռիսկ չի պարունակում, մենք գնալու ենք այս ճանապարհով, քանի որ դա մեզ թույլ է տալիս

• որքան հնարավոր է շուտ շտկել արտադրանքի սխալը.
• մուտքագրել կոդը master անմիջապես հարմար է նոր աշխատանք սկսելու համար։

️Առաջադրանք

1. Անցում մասնաճյուղի master տեղայնորեն:
2. Թարմացրեք տեղական պահոցը հեռավոր պահոցից:
3. Վերադարձեք PR-ի միաձուլման պարտավորությունը Քայլերի վերանայում в master.
4. Հրապարակեք փոփոխությունները հեռավոր պահոցում:

Սա պահեստի պատմությունն է, որի հետ միաձուլման պարտավորությունը հետ է վերադարձվել

Հրամաններ

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ Ինքնաթեստ

Համոզվեք, որ ci.md Միաձուլման կատարումը վերադարձնելուց հետո այլևս չի պարունակում «նենգ սխալ» տեքստը:

Ուղղեք CI քայլերի ցանկը և վերադարձրեք այն հիմնականին

Մենք ամբողջությամբ վերադարձրել ենք մասնաճյուղի միաձուլման պարտավորությունը: feature. Լավ նորությունն այն է, որ մենք այժմ սխալներ չունենք master. Վատ նորությունն այն է, որ շարունակական ինտեգրացիոն քայլերի մեր թանկարժեք ցուցակը նույնպես անհետացել է: Այսպիսով, իդեալական տարբերակում, մենք պետք է կիրառենք ամրագրումը կատարվող պարտավորությունների վրա feature և վերադարձրեք դրանք master ամրացման հետ միասին:

Մենք կարող ենք խնդրին մոտենալ տարբեր ձևերով.

• հետ վերադարձնել միաձուլումը չեղարկող commit-ը feature с master;
• տեղափոխել պարտավորություններ նախկինից feature.

Զարգացման տարբեր թիմեր այս դեպքում օգտագործում են տարբեր մոտեցումներ, բայց մենք օգտակար պարտավորությունները կտեղափոխենք առանձին մասնաճյուղ և կստեղծենք այս նոր մասնաճյուղի համար առանձին ձգողական հարցում:

️Առաջադրանք

1. Ստեղծեք թեմա, որը կոչվում է feature-fix և անցնել դրան:

2. Տեղափոխել բոլոր պարտավորությունները նախկին մասնաճյուղից feature դեպի նոր թեմա. Լուծել միաձուլման կոնֆլիկտները, որոնք առաջացել են միգրացիայի ժամանակ:

   

3. Ավելացնել ռեգրեսիայի թեստ ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. Կատարեք թեստերը տեղական մակարդակով, որպեսզի համոզվեք, որ դրանք չեն ձախողվում:
5. Հեռացրեք «մի նենգ սխալով» տեքստը ci.md.
6. Ավելացրեք թեստի փոփոխությունները և քայլերի ցուցակի փոփոխությունները ինդեքսում և կատարեք դրանք:
7. Հրապարակեք մասնաճյուղը հեռավոր պահեստում:

Դուք պետք է ավարտեք նման բան.

Հրամաններ

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

Ստեղծեք ձգման հարցում:

Ստեղծեք ձգման հարցում վերնագրով Հատկանիշի շտկում... Տեղադրեք feature-fix ինչպես «գլուխ ճյուղ» և master ինչպես «բազային ճյուղը»:
Խնդրում ենք սպասել, մինչև թեստերն ավարտվեն: Թեստերի կարգավիճակը կարող եք տեսնել PR քննարկման ներքևում:

Համոզվեք, որ դուք տեղադրել եք master իր մեջ պատառաքաղել պահեստը Որպես «բազային մասնաճյուղ», ես չեմ պատասխանի դասընթացի նյութերի պահոցում փոփոխություններ կատարելու հարցումներին:

Հաստատել ձգման հարցումը «Ֆիքսել հատկությունը»

Շնորհակալություն ուղղման համար: Խնդրում ենք հաստատել փոփոխությունները master քաշելու խնդրանքից:

️Առաջադրանք

1. Սեղմեք «Միաձուլման ձգման հարցումը»:
2. Սեղմեք «Հաստատեք միաձուլումը»:
3. Կտտացրեք «Ջնջել մասնաճյուղը», քանի որ այն մեզ այլևս պետք չէ:

Սա այն է, ինչ դուք պետք է ունենաք այս պահին։

Շնորհավորում եմ:

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

Եթե ​​դասընթացի հետ կապված խնդիրներ եք նկատում կամ գիտեք, թե ինչպես բարելավել այն, խնդրում ենք ստեղծել խնդիր պահեստարաններ դասընթացի նյութերով. Այս դասընթացը նույնպես ունի ինտերակտիվ տարբերակ օգտագործելով GitHub Learning Lab-ը որպես հարթակ:

Source: www.habr.com