Та Git командуудыг сурсан боловч тасралтгүй интеграци (CI) бодит байдал дээр хэрхэн ажилладагийг ойлгохыг хүсч байна уу? Эсвэл та өдөр тутмынхаа үйл ажиллагааг оновчтой болгохыг хүсч байна уу? Энэхүү сургалт нь GitHub репозиторыг ашиглан тасралтгүй нэгтгэх практик ур чадварыг танд олгоно. Энэ сургалт нь зүгээр л дарж болох шидтэн биш, харин ч эсрэгээр та хүмүүсийн ажил дээрээ хийдэг зүйлсийг яг л тэд хийдэгтэй адил хийх болно. Холбогдох алхмуудыг хийх явцад би онолыг тайлбарлах болно.

Бид юу хийх вэ?

Цаашид бид аажмаар CI-ийн ердийн алхмуудын жагсаалтыг гаргах бөгөөд энэ жагсаалтыг санах сайхан арга юм. Өөрөөр хэлбэл, бид тасралтгүй интеграцийг хэрэгжүүлэх, тасралтгүй интеграцийг хэрэгжүүлэх үед хөгжүүлэгчид гүйцэтгэдэг үйл ажиллагааны жагсаалтыг гаргах болно. Мөн бид CI процессоо бодит байдалд ойртуулахын тулд энгийн тестийн багцыг ашиглах болно.

Энэхүү GIF нь таныг курсын явцад ахиц дэвшил гаргахад таны агуулах дахь амлалтыг бүдүүвчээр харуулж байна. Таны харж байгаагаар ямар ч төвөгтэй зүйл байхгүй бөгөөд зөвхөн хамгийн шаардлагатай зүйл юм.

Та дараах стандарт CI хувилбаруудыг давах болно.

• Онцлог шинж чанар дээр ажиллах;
• Чанарын баталгаажуулалтын автомат туршилтыг ашиглах;
• Тэргүүлэх зорилтын хэрэгжилт;
• Салбаруудыг нэгтгэх үед зөрчилдөөнийг шийдвэрлэх (мөргөлдөөнийг нэгтгэх);
• Үйлдвэрлэлийн орчинд алдаа гарах.

Та юу сурах вэ?

Та дараах асуултуудад хариулах боломжтой болно.

• Тасралтгүй интеграци (CI) гэж юу вэ?
• CI-д ямар төрлийн авто тестийг ашигладаг бөгөөд тэдгээр нь ямар үйлдлийн хариуд ажилладаг вэ?
• Татаж авах хүсэлт гэж юу вэ, тэд хэзээ хэрэгтэй вэ?
• Туршилтад суурилсан хөгжил (TDD) гэж юу вэ, энэ нь CI-тэй хэрхэн холбоотой вэ?
• Өөрчлөлтүүдийг дээд талд нь нэгтгэх эсвэл хэрэглэх (дахин тохируулах) уу?
• Дараагийн хувилбарт буцаах эсвэл засах уу?

Эхэндээ би "татах хүсэлт" гэх мэт зүйлийг хаа сайгүй орчуулдаг байсан ч үүний үр дүнд текст дэх галзуугийн зэргийг багасгахын тулд зарим газар англи хэл дээрх хэллэгүүдийг буцаахаар шийдсэн. Би хааяа нэг "програмчлалын суржик" -ийг хүмүүс ажил дээрээ ашигладаг "commit" гэсэн гоёмсог үйл үг шиг ашиглах болно.

Тасралтгүй интеграци гэж юу вэ?

Тасралтгүй интеграци, эсвэл 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 Үйлдлүүд идэвхжээгүй бол та миний зааврын дагуу курсээ дуусгах боломжгүй.

Та 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. Үүний дараа тестүүдээ commit дээр ажиллуулахын тулд git hook нэмье. Нэг анхаарах зүйл бий: 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 дээрх нээлттэй эхийн төслүүдэд ихэвчлэн ашигладаг. Энэ нь бас миний ахисан түвшний сургалтанд хэрэглэгддэг [Багийн ажил болон Git-тэй CI] (http://devops.redpill.solutions/).
• Өөр нэг арга бол зөвхөн нэг алсын хадгалах газрыг ашиглах бөгөөд зөвхөн салбарыг тоолох явдал юм master хуваалцсан репозитор нь "хамгаалагдсан". Энэ тохиолдолд хувь хүн хөгжүүлэгчид өөрсдийн кодыг алсын хадгалах сангийн салбаруудад нийтэлдэг бөгөөд ингэснээр бусад хүмүүс энэ кодыг харах боломжтой бөгөөд хэрэв бүх зүйл эмх цэгцтэй байвал нэгдээрэй. master хуваалцсан агуулах.

Энэ тусгай сургалтанд бид салбаруудыг ашигладаг ажлын урсгалыг ашиглах болно.

Кодоо нийтэлье.

️ Даалгавар

• Өөрийнхөө ажлын салбартай ижил нэртэй алслагдсан салбар руу өөрчлөлт оруулна уу

Багууд

git push --set-upstream origin feature

Татаж авах хүсэлтийг үүсгэ

Гарчигтай татах хүсэлтийг үүсгэ Алхам алхмуудыг хянан үзэх... Суулгах feature "толгой салбар" болон master "суурь салбар" гэж.

Та суулгасан эсэхээ шалгаарай master түүний дотор хадгалах сэрээ "үндсэн салбар"-ын хувьд би хичээлийн агуулгын репозиторыг өөрчлөх хүсэлтэд хариу өгөхгүй.

GitHub хэл дээр "суурь салбар" нь таны ажилд тулгуурласан салбар бөгөөд "толгой салбар" нь санал болгож буй өөрчлөлтүүдийг агуулсан салбар юм.

Өөрчлөлтүүдийн талаар ярилцаж, хэлэлцүүлэг үргэлжилж байгаа тул шинэ үүрэг даалгавруудыг нэмнэ үү

Татах хүсэлт(PR)

Татах хүсэлт(PR) Энэ нь кодыг хэлэлцэх, баримтжуулах, мөн кодыг хянах арга юм. Татаж авах хүсэлтүүд нь хувь хүний ​​өөрчлөлтийг ерөнхий кодонд нэгтгэх ерөнхий арга замаар нэрлэгдсэн байдаг. Ихэвчлэн хүн алсын албан ёсны төслийн репозиторыг хувилдаг бөгөөд код дээр орон нутагт ажилладаг. Үүний дараа тэрээр кодыг өөрийн хувийн алсын хадгалах газарт байрлуулж, албан ёсны репозиторыг хариуцсан хүмүүсээс үүнийг авахыг хүсдэг (Татах) кодыг нь хянаж үзээд нэгтгэх боломжтой орон нутгийн хадгалах газартаа оруулна.нийлүүлэх) түүний. Энэ ойлголтыг өөр нэрээр ч нэрлэдэг, жишээлбэл, хүсэлтийг нэгтгэх.

Үнэн хэрэгтээ та GitHub эсвэл ижил төстэй платформуудын татах хүсэлтийн функцийг ашиглах шаардлагагүй. Хөгжлийн багууд нүүр тулан харилцах, дуут дуудлага эсвэл имэйл гэх мэт бусад харилцааны хэрэгслийг ашиглаж болох ч форум маягийн татах хүсэлтийг ашиглах хэд хэдэн шалтгаан байсаар байна. Тэдгээрийн заримыг энд харуулав.

• кодын тодорхой өөрчлөлттэй холбоотой хэлэлцүүлэг зохион байгуулсан;
• автомат туршилт болон үе тэнгийнхний аль алиных нь хийж буй ажлын талаархи санал хүсэлтийг харах газар болгон;
• кодын шалгалтыг албажуулах;
• Ингэснээр та энэ эсвэл тэр кодын цаана байгаа шалтгаан, санааг хожим олж мэдэх боломжтой.

Та ямар нэг зүйлийг хэлэлцэх эсвэл санал хүсэлт авах шаардлагатай үед ихэвчлэн татах хүсэлт гаргадаг. Жишээлбэл, хэрэв та олон янзаар хэрэгжүүлэх боломжтой функц дээр ажиллаж байгаа бол эхний мөрийг кодын бичихээс өмнө татах хүсэлт үүсгэж, санаа бодлоо хуваалцаж, хамтран ажиллагсадтайгаа төлөвлөгөөгөө ярилцаж болно. Хэрэв ажил нь илүү энгийн бол ямар нэг зүйл аль хэдийн хийгдсэн, хийгдсэн, хэлэлцэх боломжтой үед татах хүсэлт нээгддэг. Зарим тохиолдолд та чанарын хяналтын шалтгааны улмаас PR нээхийг хүсч болно: автоматжуулсан тест хийх эсвэл кодын шалгалтыг эхлүүлэх. Та юу ч шийдсэн бай, татах хүсэлтдээ зөвшөөрөл авахыг хүссэн хүмүүсээ @mention хийхээ бүү мартаарай.

Ерөнхийдөө PR үүсгэхдээ та дараах зүйлийг хийдэг.

• Юу, хаана өөрчлөхийг санал болгож байгаагаа тодорхойл.
• Өөрчлөлтийн зорилгыг тайлбарласан тайлбар бичнэ үү. Та хүсэж магадгүй:
  • кодоос тодорхой бус чухал зүйл, эсвэл холбогдох #алдаа болон үйлдлийн тоо зэрэг контекстийг ойлгоход хэрэгтэй зүйл нэмэх;
  • Хамтран ажиллахыг хүссэн хүнээ @mention эсвэл дараа нь сэтгэгдэл дээр @mention хийх боломжтой;
  • хамт ажиллагсдаасаа ямар нэгэн зүйлд туслахыг хүс эсвэл тодорхой зүйлийг шалгах.

Таныг PR-г нээсний дараа ийм тохиолдолд ажиллуулахаар тохируулсан тестүүд хийгдэнэ. Манай тохиолдолд энэ нь бидний орон нутагт явуулсан туршилтын багц байх боловч бодит төсөлд нэмэлт шалгалт, шалгалт байж болно.

Туршилтууд дуусах хүртэл хүлээнэ үү. Та GitHub интерфэйс дэх PR хэлхээний доод хэсэгт тестийн статусыг харж болно. Туршилтууд дууссаны дараа үргэлжлүүлнэ үү.

️ 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 ашиг багатай - энэ нь зөвхөн нэгтгэх үүргийг олох болно.

Буцах

• Суурийн дээд талд байгаа одоогийн салбараас нэг нэгээр нь дахин тоглуулна.
  • Шинэ амлалтууд нь шинэ SHA-уудаар үүсгэгддэг бөгөөд GitHub нь анхны татах хүсэлттэй таарч тохирох боловч харгалзах тайлбаруудтай тохирохгүй байна.
  • Амлалтуудыг процессын явцад дахин нэгтгэж, өөрчлөх эсвэл бүр нэг болгон нэгтгэж болно.
• Та олон зөрчилдөөнийг шийдвэрлэх шаардлагатай байж магадгүй юм.
• Шугаман түүхийг хадгалах боломжийг танд олгоно.
  • Өгүүллэг нь ямар ч шалтгаангүйгээр хэтэрхий урт биш бол уншихад хялбар байж магадгүй юм.
  • Автомат дибаг хийх, алдааг олж засварлах нь арай хялбар бөгөөд үүнийг боломжтой болгодог 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 алдаатай, үүнээс хөгжүүлэгчид шинэ ажил эхлүүлэх боломжтой.

Буцах эсвэл дараагийн хувилбарт засах уу?

"Буцах" гэдэг нь сайн мэддэг өмнөх хувилбарыг үйлдвэрлэлийн орчинд байршуулж, алдаа агуулсан үйлдлийг буцаах үйлдэл юм. "Урагшаа засах" нь засах нэмэлт юм 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 нэгтгэх үйлдлийг буцаасны дараа "sneaky bug" гэсэн текстийг агуулахаа больсон.

CI алхамын жагсаалтыг засаад мастер руу буцна уу

Бид салбар нэгтгэх үүргийг бүрэн буцаасан feature. Сайн мэдээ гэвэл одоо бидэнд алдаа байхгүй master. Муу мэдээ гэвэл бидний тасралтгүй интеграцийн алхмуудын нандин жагсаалт алга болсон байна. Тиймээс, хамгийн тохиромжтой нь, бид энэ засварыг амлалтуудад ашиглахыг хүсч байна feature мөн тэдгээрийг буцаана master засварын хамт.

Бид асуудалд янз бүрийн аргаар хандаж болно:

• нийлэлтийг буцаах үүрэг хариуцлагыг буцаах 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. "Sneaky bug" гэсэн текстийг устгана уу 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 сургалтын лабораторийг платформ болгон ашиглах.

Эх сурвалж: www.habr.com