Git komutlarını öğrendiniz ama sürekli entegrasyonun (CI) gerçekte nasıl çalıştığını hayal etmek mi istiyorsunuz? Ya da belki günlük aktivitelerinizi optimize etmek istiyorsunuz? Bu kurs size GitHub deposunu kullanarak sürekli entegrasyon konusunda pratik beceriler kazandıracaktır. Bu kursun, basitçe tıklayabileceğiniz bir sihirbaz olması amaçlanmamıştır; tam tersine, insanların işte gerçekte yaptığı eylemlerin aynısını, onların yaptığı gibi gerçekleştireceksiniz. Siz ilgili adımları izlerken teoriyi açıklayacağım.

Biz ne yapacağız?

İlerledikçe, yavaş yavaş tipik CI adımlarının bir listesini oluşturacağız; bu, bu listeyi hatırlamanın harika bir yoludur. Yani geliştiricilerin sürekli entegrasyon yaparken, sürekli entegrasyon yaparken yaptıkları eylemlerin bir listesini oluşturacağız. Ayrıca CI sürecimizi gerçeğe yaklaştırmak için basit bir dizi test kullanacağız.

Bu GIF, kursta ilerledikçe deponuzdaki taahhütleri şematik olarak gösterir. Gördüğünüz gibi burada karmaşık hiçbir şey yok ve yalnızca en gerekli olanı var.

Aşağıdaki standart CI senaryolarını izleyeceksiniz:

• Bir özellik üzerinde çalışın;
• Kaliteyi sağlamak için otomatik testlerin uygulanması;
• Öncelikli görevin uygulanması;
• Şubeleri birleştirirken çatışma çözümü (birleştirme çatışması);
• Üretim ortamında bir hata oluşur.

Ne öğreneceksin?

Aşağıdaki soruları cevaplayabileceksiniz:

• Sürekli entegrasyon (CI) nedir?
• CI'da ne tür otomatik testler kullanılıyor ve hangi eylemlere yanıt olarak tetikleniyorlar?
• Çekme istekleri nedir ve ne zaman ihtiyaç duyulur?
• Test Odaklı Geliştirme (TDD) nedir ve CI ile ilişkisi nedir?
• Değişiklikleri birleştirmeli miyim yoksa yeniden temellendirmeli miyim?
• Bir sonraki sürümde geri alınsın mı yoksa düzeltilsin mi?

İlk başta “pull request” gibi şeyleri her yere tercüme ettim ama sonuç olarak metindeki çılgınlık derecesini azaltmak için bazı yerlerde İngilizce ifadeleri döndürmeye karar verdim. Bazen "programcı surzhik"i, insanların iş yerinde kullandığı harika "taahhüt etme" fiili gibi kullanacağım.

Sürekli entegrasyon nedir?

Sürekli EntegrasyonCI veya CI, her ekip üyesinin kodunu günde en az bir kez ortak bir depoya entegre ettiği ve ortaya çıkan kodun en azından hatasız oluşturulması gerektiği teknik bir uygulamadır.

Bu terim hakkında anlaşmazlıklar var

Tartışma konusu entegrasyonun sıklığıdır. Bazıları, kodu günde yalnızca bir kez birleştirmenin aslında sürekli entegrasyon için yeterli olmadığını savunuyor. Herkesin sabahları yeni kod aldığı ve akşamları bir kez entegre ettiği bir takıma örnek verilmiştir. Bu makul bir itiraz olsa da, genellikle günde bir kez tanımının oldukça pratik, spesifik ve farklı büyüklükteki ekipler için uygun olduğuna inanılmaktadır.

Diğer bir itiraz ise C++'ın artık geliştirmede kullanılan tek dil olmadığı ve doğrulama yöntemi olarak hatasız derlemenin basitçe gerekli kılınmasının zayıf olduğudur. Bazı test kümelerinin (örneğin, yerel olarak yürütülen birim testleri) de başarıyla tamamlanması gerekir. Şu anda topluluk bunu bir gereklilik haline getirmeye doğru ilerliyor ve gelecekte "derleme + birim testleri", henüz değilse bile, muhtemelen yaygın bir uygulama haline gelecektir.

Sürekli Entegrasyon farklıdır sürekli teslimat (Sürekli Teslimat, CD) özelliği, her entegrasyon döngüsünden sonra bir sürüm adayı gerektirmemesidir.

Kurs boyunca kullanacağımız adımların listesi

1. En son kodu çekin. Şuradan bir şube oluştur: master. Çalışmaya başlamak.
2. Yeni şubenizde taahhütler oluşturun. Yerel olarak oluşturun ve test edin. Geçmek? Bir sonraki adıma geçin. Hata? Hataları veya testleri düzeltip tekrar deneyin.
3. Uzak deponuza veya uzak şubenize gönderin.
4. Bir çekme isteği oluşturun. Değişiklikleri tartışın, tartışma devam ettikçe daha fazla taahhüt ekleyin. Özellik dalında testlerin geçmesini sağlayın.
5. Master'dan gelen taahhütleri birleştir/yeniden oluştur. Birleştirme sonucunda testlerin geçmesini sağlayın.
6. Özellik dalından üretime dağıtın.
7. Bir süre üretimde her şey yolunda giderse, değişiklikleri master ile birleştirin.

️ Hazırlık

Doğru yazılıma sahip olduğunuzdan emin olun

Bu kursu almak için ihtiyacınız olacak node.js и Git istemcisi.

Herhangi bir Git istemcisini kullanabilirsiniz, ancak ben yalnızca komut satırı için komutlar sağlayacağım.

Komut satırını destekleyen bir Git istemcisinin kurulu olduğundan emin olun

Henüz komut satırını destekleyen bir Git istemciniz yoksa kurulum talimatlarını bulabilirsiniz burada.

Depoyu hazırlayın

Kişisel bir kopya (çatal) oluşturmanız gerekecek kurs kodunu içeren şablon deposu GitHub'da. Bu kişisel kopyayı aramayı kabul edelim kurs deposu.

Tamamlamak? Varsayılan ayarları değiştirmediyseniz kurs deponuzun adı büyük olasılıkla continuous-integration-team-scenarios-studentsGitHub hesabınızda bulunur ve URL şöyle görünür

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

Bu adresi arayacağım <URL репозитория>.

Köşeli parantez gibi <тут> böyle bir ifadeyi uygun değerle değiştirmeniz gerektiği anlamına gelir.

Emin olun GitHub eylemleri bu kurs deposuna dahil edilmiştir. Etkinleştirilmemişlerse lütfen sayfanın ortasındaki büyük düğmeye tıklayarak bunları etkinleştirin; bu düğmeye GitHub arayüzünde Eylemler'i tıklayarak ulaşabilirsiniz.

GitHub Eylemleri etkin değilse talimatlarımı uygulayarak kursu tamamlayamazsınız.

Burada oluşturduğumuz listenin mevcut durumunu görmek için GitHub'un Markdown oluşturma yeteneğini her zaman kullanabilirsiniz.

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

Cevaplar hakkında

Bu kursu tamamlamanın en iyi yolu bunu kendi başınıza yapmak olsa da bazı zorluklarla karşılaşabilirsiniz.

Ne yapacağınızı anlamadığınızı ve devam edemeyeceğinizi düşünüyorsanız konuya bakabilirsiniz. solution, başlangıç ​​deponuzdadır.
Lütfen birleştirmeyin solution в master Kurs sırasında. Git'in bize sağladığı tüm yetenekleri kullanarak ne yapacağınızı anlamak veya kodunuzu yazarın koduyla karşılaştırmak için bu dalı kullanabilirsiniz. Tamamen kaybolduysanız şubenizi tamamen değiştirebilirsiniz master bir dalda solution ve ardından çalışma dizininizi ihtiyacınız olan kurs adımına sıfırlayın.

Bunu yalnızca gerçekten ihtiyacınız varsa kullanın

Kodunuzu kaydedin

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

Bu komutlar

• yeniden isimlendirmek master в master-backup;
• yeniden isimlendirmek solution в master;
• yeni şubeye ödeme master ve çalışma dizininin içeriğini yeniden yazın;
• Gelecekte bir "çözüm" dalına ihtiyaç duymanız durumunda "ana"dan (eskiden "çözüm" olan) bir "çözüm" dalı oluşturun.

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

Bu adımlardan sonra kullanabilirsiniz git log master hangi taahhüde ihtiyacınız olduğunu bulmak için.
Çalışma dizininizi bu işleme şu şekilde sıfırlayabilirsiniz:

git reset --hard <the SHA you need>

Sonuçtan memnunsanız, bir noktada depo sürümünüzü uzak bir depoda yayınlamanız gerekecektir. Bunu yaparken uzak dalı açıkça belirtmeyi unutmayın.

git push --force origin master

Lütfen kullandığımızı unutmayın git push --force. Bunu çok sık yapmak istemeniz pek mümkün değildir, ancak burada, ayrıca ne yaptığını anlayan bir depo kullanıcısıyla çok özel bir senaryomuz var.

Çalışmaya başlama

CI adımları listemizi derlemeye başlayalım. Normalde bu adıma uzak depodan kodun en son sürümünü kontrol ederek başlarsınız, ancak henüz yerel bir depomuz yok, bu yüzden onu uzak depodan kopyalıyoruz.

️ Görev: yerel depoyu güncelleyin, bir şube oluşturun master, çalışmaya başlamak

1. Kurs deposunu şuradan klonlayın: <URL репозитория>.
2. başlangıç npm install kurs deposu dizininde; Testleri çalıştırmak için kullandığımız Jest'i kurmamız gerekiyor.
3. Bir şube oluşturun ve adlandırın feature. Bu konuya geçin.

4. Test kodunu şuraya ekleyin: ci.test.js benden bunu yapmamı isteyen yorumlar arasında.

   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. Dosyaya ilk 4 adımı içeren metin ekleyin 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.  

   Takımlar

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

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

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

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

Yeni bir dalda taahhütler oluşturun, yerel olarak oluşturun ve test edin

Taahhüt etmeden önce testleri çalışacak şekilde ayarlayacağız ve ardından kodu taahhüt edeceğiz.

Testlerin otomatik olarak çalıştırıldığı tipik senaryolar

• Yerel olarak:
  • Sürekli olarak veya uygun kod değişikliklerine yanıt olarak;
  • Kaydetme sırasında (yorumlanan veya JIT ile derlenen diller için);
  • Montaj sırasında (derleme gerektiğinde);
  • Taahhüt sırasında;
  • Paylaşılan bir depoya yayınlarken.

• Derleme sunucusunda veya derleme ortamında:
  • Kod kişisel bir şubeye/depoya yayınlandığında.
  • Bu başlıktaki kod test ediliyor.
  • Birleşmenin potansiyel sonucu test edilir (genellikle master).
  • Sürekli entegrasyon aşaması/sürekli teslimat hattı olarak

Tipik olarak, bir test paketi ne kadar hızlı çalışırsa, onu o kadar sık ​​çalıştırmaya gücünüz yetecektir. Tipik bir sahne dağılımı şu şekilde görünebilir.

• Hızlı birim testleri - oluşturma sırasında, CI hattında
• CI hattında taahhüt üzerine yavaş birim testleri, hızlı bileşen ve entegrasyon testleri
• Yavaş bileşen ve entegrasyon testleri - CI hattında
• Güvenlik testleri, yük testleri ve diğer zaman alıcı veya pahalı testler - CI/CD işlem hatlarında, ancak yalnızca yapının belirli modlarında/aşamalarında/işlem hatlarında, örneğin bir sürüm adayı hazırlanırken veya manuel olarak çalıştırılırken.

️Görev

Testleri önce komutu kullanarak manuel olarak çalıştırmanızı öneririm npm test. Bundan sonra testlerimizi commit üzerinde çalıştırmak için bir git hook ekleyelim. Bir sorun var: Git kancaları veri havuzunun bir parçası olarak kabul edilmiyor ve bu nedenle diğer kurs materyalleriyle birlikte GitHub'dan kopyalanamıyor. Kancayı yüklemek için çalıştırmanız gerekir install_hook.sh veya dosyayı kopyalayın repo/hooks/pre-commit yerel dizine .git/hooks/.
Taahhüt ettiğinizde testlerin yapıldığını ve listede belirli anahtar kelimelerin bulunup bulunmadığını kontrol ettiklerini göreceksiniz.

1. Komutu çalıştırarak testleri manuel olarak çalıştırın npm test Kurs deposu klasörünüzde. Testlerin tamamlandığını doğrulayın.
2. Çalıştırarak bir taahhüt kancası (ön taahhüt kancası) ayarlayın install_hook.sh.
3. Değişikliklerinizi yerel deponuza kaydedin.
4. Taahhüt etmeden önce testlerin yapıldığından emin olun.

Bu adımları izledikten sonra deponuz bu şekilde görünmelidir.

Takımlar

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

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

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

Kodu uzak bir depoya veya uzak şubeye yayınlayın

Yerel olarak çalışmayı bitirdikten sonra geliştiriciler genellikle kodlarını kamuya açık hale getirir, böylece sonunda halkla entegre edilebilir. GitHub'da bu genellikle çalışmayı deponun kişisel bir kopyasına (kişisel çatal) veya kişisel bir şubeye yayınlayarak gerçekleştirilir.

• Çatallarla, bir geliştirici uzak paylaşılan bir veri havuzunu klonlayarak bunun çatal olarak da bilinen kişisel bir uzak kopyasını oluşturur. Daha sonra bu kişisel depoyu yerel olarak çalışmak üzere klonlar. İş tamamlandığında ve taahhütler yapıldığında, bunları başkalarının kullanımına açık olacak ve ortak depoya entegre edilebilecekleri çatalına iter. Bu yaklaşım GitHub'daki açık kaynaklı projelerde yaygın olarak kullanılmaktadır. Ayrıca ileri düzey kursumda da kullanılıyor [Git ile Ekip Çalışması ve CI] (http://devops.redpill.solutions/).
• Diğer bir yaklaşım ise yalnızca bir uzak depo kullanmak ve yalnızca şubeyi saymaktır. master paylaşılan depo "korumalı". Bu senaryoda, bireysel geliştiriciler kodlarını uzak bir havuzun dallarına yayınlar, böylece diğerleri bu koda bakabilir, her şey yolundaysa onu birleştirin. master paylaşılan depo.

Bu özel kursta dalları kullanan bir iş akışı kullanacağız.

Kodumuzu yayınlayalım.

️Görev

• Değişiklikleri, çalışma şubenizle aynı adı taşıyan uzak bir şubeye yayınlayın

Takımlar

git push --set-upstream origin feature

Çekme isteği oluştur

Başlığı olan bir çekme isteği oluşturun Adım incelemesi... Düzenlemek feature "ana dal" gibi ve master "temel dal" gibi.

Yüklediğinizden emin olun master onun içinde depoyu çatalla Bir "temel dal" olarak ders materyalleri deposundaki değişiklik taleplerine yanıt vermeyeceğim.

GitHub dilinde "temel dal", çalışmanızı temel aldığınız daldır ve "baş dal" ise önerilen değişiklikleri içeren daldır.

Değişiklikleri tartışın, tartışma devam ettikçe yeni taahhütler ekleyin

Çekme isteği(PR)

Çekme isteği(PR) Kodu tartışmanın ve belgelemenin yanı sıra kod incelemesi yürütmenin bir yoludur. Çekme istekleri, bireysel değişiklikleri genel koda entegre etmenin genel yolundan sonra adlandırılır. Tipik olarak, bir kişi projenin uzaktaki resmi deposunu klonlar ve kod üzerinde yerel olarak çalışır. Bundan sonra kodu kişisel uzak deposuna yerleştirir ve resmi depodan sorumlu olanlardan bu kodu almalarını ister (Çek) kodunu yerel depolarına aktarın, burada inceleyip muhtemelen entegre edin(birleştirme) onun. Bu kavram aynı zamanda başka isimlerle de bilinir, örneğin: birleştirme isteği.

Aslında GitHub veya benzeri platformların çekme isteği özelliğini kullanmanıza gerek yok. Geliştirme ekipleri, yüz yüze iletişim, sesli aramalar veya e-posta dahil olmak üzere diğer iletişim yöntemlerini kullanabilir ancak forum tarzı çekme isteklerini kullanmanın hala birkaç nedeni vardır. Bunlardan bazıları:

• belirli kod değişiklikleriyle ilgili organize tartışmalar;
• hem otomatik test uzmanlarından hem de meslektaşlarından devam eden çalışmalarla ilgili geri bildirimlerin görüntüleneceği bir yer olarak;
• kod incelemelerinin resmileştirilmesi;
• böylece daha sonra şu veya bu kod parçasının arkasındaki nedenleri ve düşünceleri öğrenebilirsiniz.

Genellikle bir şeyi tartışmanız veya geri bildirim almanız gerektiğinde bir çekme isteği oluşturursunuz. Örneğin, birden fazla şekilde uygulanabilecek bir özellik üzerinde çalışıyorsanız, kodun ilk satırını yazmadan önce fikirlerinizi paylaşmak ve planlarınızı ortak çalışanlarınızla tartışmak için bir çekme isteği oluşturabilirsiniz. Eğer iş daha basitse, bir şey zaten yapılmış, taahhüt edilmiş ve tartışılabilecek durumdayken çekme isteği açılır. Bazı senaryolarda, PR'yi yalnızca kalite kontrol nedenleriyle açmak isteyebilirsiniz: otomatik testler yürütmek veya kod incelemelerini başlatmak için. Kararınız ne olursa olsun, pull request'inizde onayını istediğiniz kişileri @bahsetmeyi unutmayın.

Tipik olarak, bir PR oluştururken aşağıdakileri yaparsınız.

• Neyi değiştirmeyi düşündüğünüzü ve nerede olduğunu belirtin.
• Değişikliklerin amacını açıklayan bir açıklama yazın. İsteyebilirsin:
  • kodda açıkça görülmeyen önemli bir şey veya ilgili #bugs ve taahhüt numaraları gibi bağlamı anlamak için yararlı bir şey ekleyin;
  • Birlikte çalışmaya başlamak istediğiniz kişiden @bahsedin veya daha sonra yorumlarda bu kişiden @bahsedebilirsiniz;
  • meslektaşlarınızdan bir konuda yardım etmelerini isteyin veya belirli bir şeyi kontrol edin.

PR'yi açtığınızda bu gibi durumlarda çalışacak şekilde yapılandırılmış testler yürütülür. Bizim durumumuzda bu, yerel olarak yürüttüğümüz testlerin aynısı olacaktır ancak gerçek bir projede ek testler ve kontroller olabilir.

Testler tamamlanana kadar lütfen bekleyin. Testlerin durumunu GitHub arayüzündeki PR tartışmasının alt kısmında görebilirsiniz. Testler tamamlandığında devam edin.

️ CI adımları listesinin rastgeleliği hakkında bir not ekleyin

Bu derste kullanılan liste keyfi ve subjektiftir, bununla ilgili bir not eklemeliyiz.

️ Görev: Bu yorum için bir çekme isteği oluşturun

1. Şubeye geçiş master.
2. Adlı bir şube oluşturun bugfix.
3. Dosyanın sonuna not metni ekleyin 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. Değişiklikleri gerçekleştirin.
5. Konuyu yayınla bugfix uzak bir depoya.
6. Adlı bir çekme isteği oluşturun Açıklama ekleme bir baş dalı ile bugfix ve baz dalımaster.

Yüklediğinizden emin olun master onun içinde depoyu çatalla Bir "temel dal" olarak ders materyalleri deposundaki değişiklik taleplerine yanıt vermeyeceğim.

Deponuz böyle görünmeli.

Takımlar

# Переключитесь на ветку 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 как описано выше

Çekme isteğini onayla "Açıklama ekleme"

️Görev

1. Bir çekme isteği oluşturun.
2. "Çekme isteğini birleştir"i tıklayın.
3. "Birleştirmeyi onayla"yı tıklayın.
4. "Şubeyi sil"e tıklayın, artık buna ihtiyacımız yok.

Bu, birleştirme sonrasındaki taahhütlerin bir diyagramıdır.

️ Çalışmaya ve testler eklemeye devam edin

Bir çekme isteği üzerinde işbirliği yapmak çoğu zaman ek çalışmayla sonuçlanır. Bu genellikle kod incelemesinin veya tartışmasının sonucudur, ancak kursumuzda CI adımları listemize yeni öğeler ekleyerek bunu modelleyeceğiz.

Sürekli entegrasyon genellikle bir miktar test kapsamı içerir. Test kapsamı gereksinimleri farklılık gösterir ve genellikle "katkı kuralları" gibi bir belgede bulunur. Bunu basit tutacağız ve kontrol listemizdeki her satır için bir test ekleyeceğiz.

Ödevleri çalıştırırken önce testleri gerçekleştirmeyi deneyin. Doğru kurulum yaptıysanız pre-commit Hook'u daha erken bağlarsanız, yeni eklenen test çalıştırılacak, başarısız olacak ve hiçbir şey yapılmayacaktır. Testlerimizin aslında bir şeyi test ettiğini bu şekilde bildiğimizi unutmayın. İlginç bir şekilde, testlerden önce kodla başlarsak, testleri geçmek ya kodun beklendiği gibi çalıştığı ya da testlerin aslında hiçbir şeyi test etmediği anlamına gelebilir. Ayrıca, eğer testleri ilk etapta yazmamış olsaydık, hiçbir şey bize bunu hatırlatmayacağı için onları tamamen unutmuş olabilirdik.

Test Odaklı Geliştirme (TDD)

TDD, koddan önce testlerin yazılmasını önerir. TDD'yi kullanan tipik bir iş akışı şuna benzer.

1. Bir test ekleyin.
2. Tüm testleri çalıştırın ve yeni testin başarısız olduğundan emin olun.
3. Kodu yazın.
4. Testleri çalıştırın, tüm testlerin geçtiğinden emin olun.
5. Kodunuzu yeniden düzenleyin.
6. Tekrar et.

Başarısız olan testlerin sonuçları genellikle kırmızıyla, başarılı olanlar ise genellikle yeşille gösterildiğinden, döngü aynı zamanda kırmızı-yeşil-refaktör olarak da bilinir.

️Görev

Öncelikle testleri gerçekleştirmeyi ve başarısız olmalarına izin vermeyi deneyin, ardından CI adım listesinin metnini ekleyin ve kaydedin. Testlerin geçtiğini göreceksiniz ("yeşil").
Ardından yeni kodu uzak depoda yayınlayın ve çekme isteği tartışmasının ve PR durum güncellemesinin altındaki GitHub arayüzünde yürütülen testleri izleyin.

1. Şubeye geçiş feature.

2. Bu testleri ekleyin ci.test.js son aramadan sonra 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. Testleri gerçekleştirmeyi deneyin. Eğer pre-commit hook takılıysa, taahhüt girişimi başarısız olur.
4. Daha sonra bu metni ekleyin 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. Değişiklikleri yerel olarak yapın ve uygulayın.
6. Değişiklikleri şubeye gönderin feature.

Artık böyle bir şeye sahip olmalısınız

Takımlar

# Переключительна ветку 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

Çatışmayı birleştir

Değişiklik İsteğine Git Adım incelemesi.

Yanlış bir şey yapmamış olmamıza ve kodumuz için yapılan testleri geçmemize rağmen hala şubeyi birleştiremiyoruz feature и master. Çünkü diğer konu bugfix ile birleştirildi master biz bu halkla ilişkiler üzerinde çalışırken.
Bu, uzak şubenin master şubeyi temel aldığımız sürümden daha yeni bir sürüme sahip feature. Bu nedenle HEAD'i geri saramayız master ipliğin sonuna kadar feature. Bu durumda, taahhütleri birleştirmemiz veya uygulamamız gerekir. feature yeniden temellendirme master. GitHub, herhangi bir çakışma yoksa aslında otomatik birleştirmeler gerçekleştirebilir. Ne yazık ki bizim durumumuzda her iki dalda da dosyada rekabet eden değişiklikler var ci.md. Bu duruma birleştirme çakışması adı verilir ve bunu manuel olarak çözmemiz gerekir.

Birleştir veya yeniden oluştur

gitmek

• Ek bir birleştirme taahhüdü oluşturur ve iş geçmişini kaydeder.
  • Şubelerin orijinal taahhütlerini orijinal zaman damgaları ve yazarlarıyla birlikte korur.
  • Taahhütlerin SHA'sını ve değişiklik isteği tartışmalarında bunlara olan bağlantıları kaydeder.
• Tek seferlik çakışma çözümü gerektirir.
• Hikayeyi doğrusal olmayan hale getirir.
  • Çok sayıda dal nedeniyle (IDE kablosunu anımsatan) hikayenin okunması zor olabilir.
  • Otomatik hata ayıklamayı daha zor hale getirir; git bisect daha az kullanışlı - yalnızca birleştirme taahhüdünü bulacaktır.

rebase

• Tekrarlar, mevcut daldan ana dalın üstüne birbiri ardına kayıt edilir.
  • Yeni SHA'larla yeni taahhütler oluşturulur ve GitHub'daki taahhütlerin orijinal çekme istekleriyle eşleşmesine ancak karşılık gelen yorumlarla eşleşmemesine neden olur.
  • Taahhütler süreç içinde yeniden birleştirilebilir ve değiştirilebilir, hatta bir araya getirilebilir.
• Birden fazla çatışmanın çözülmesi gerekebilir.
• Doğrusal bir hikayeyi korumanıza olanak tanır.
  • Makul bir neden olmaksızın çok uzun olmadığı sürece hikayenin okunması daha kolay olabilir.
  • Otomatik hata ayıklama ve sorun giderme biraz daha kolaydır: bunu mümkün kılar git bisect, otomatik geri alma işlemlerini daha net ve daha öngörülebilir hale getirebilir.
• Taşınan taahhütlerin bulunduğu bir şubenin bayrakla yayınlanmasını gerektirir --force çekme istekleriyle kullanıldığında.

Tipik olarak ekipler, değişiklikleri birleştirmeleri gerektiğinde her zaman aynı stratejiyi kullanmayı kabul eder. Bu, üstte "saf" bir birleştirme veya "saf" bir taahhüt veya etkileşimli olarak üstte bir taahhütte bulunmak gibi arada bir şey olabilir(git rebase -i) genel depoda yayınlanmayan şubeler için yerel olarak, ancak "genel" şubeler için birleştirme.

Burada birleştirmeyi kullanacağız.

️Görev

1. Kodun yerel bir şubede olduğundan emin olun master uzak bir depodan güncellendi.
2. Şubeye geçiş feature.
3. Şubeyle birleştirme başlatma master. Rekabetçi değişikliklerden kaynaklanan bir birleştirme çakışması ci.md.
4. Çatışmayı, hem CI adımları listemizin hem de bununla ilgili bir notun metinde kalmasını sağlayacak şekilde çözün.
5. Uzak bir şubeye birleştirme taahhüdü yayımlama feature.
6. GitHub kullanıcı arayüzünde çekme isteğinin durumunu kontrol edin ve birleştirme çözümlenene kadar bekleyin.

Takımlar

# Убедитесь, что код в локальное ветке `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, дождитесь пока слияние не будет разрешено.

İyi iş!

Listeyle işiniz bitti ve şimdi çekme isteğini onaylamanız gerekiyor master.

️ Görev: Çekme isteğini onayla "Adımları inceleme"

1. Bir çekme isteği açın.
2. "Çekme isteğini birleştir"i tıklayın.
3. "Birleştirmeyi onayla"yı tıklayın.
4. Artık ihtiyacımız kalmadığı için "Şubeyi sil"i tıklayın.

Bu şu anda deponuz

Ürün hatası

"Test, hataların varlığını göstermek için kullanılabilir, ancak yokluğunu göstermek için asla kullanılamaz" denir. Testlerimiz olmasına ve bize hiçbir hata göstermemelerine rağmen üretime sinsi bir hata girdi.

Böyle bir senaryoda şunlara dikkat etmemiz gerekir:

• üretimde neyin kullanıldığı;
• Konudaki kod master geliştiricilerin yeni çalışmalara başlayabileceği bir hatayla.

Bir sonraki sürümde geri almalı mıyım yoksa düzeltmeli miyim?

Geri alma, bilinen iyi bir önceki sürümü üretime dağıtma ve hatayı içeren taahhütleri geri alma işlemidir. "İleriye doğru sabitleme", bir düzeltmenin eklenmesidir. master ve yeni sürümün mümkün olan en kısa sürede dağıtılması. API'ler ve veritabanı şemaları, sürekli teslimat ve iyi test kapsamıyla birlikte kod üretime dağıtıldıkça değiştiğinden, geri alma genellikle onu bir sonraki sürümde düzeltmekten çok daha zor ve risklidir.

Bizim durumumuzda geri dönmenin herhangi bir riski olmadığı için bu yola gideceğiz çünkü bu bize izin veriyor.

• Üründeki hatayı mümkün olan en kısa sürede düzeltin;
• kodu gir master yeni bir işe başlamak için hemen uygundur.

️Görev

1. Şubeye geçiş master yerel olarak.
2. Yerel depoyu uzak depodan güncelleyin.
3. PR birleştirme işlemini geri alın Adım incelemesi в master.
4. Değişiklikleri uzak bir depoya yayınlayın.

Bu, birleştirme taahhüdünün geri döndürüldüğü bir havuzun geçmişidir

Takımlar

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

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

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

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

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

️ Kendi kendine test

Emin olun ci.md birleştirme işlemi geri alındıktan sonra artık "sinsi hata" metnini içermiyor.

CI adımlarının listesini düzeltin ve ana bilgisayara geri gönderin

Şubenin birleştirme taahhüdünü tamamen geri aldık. feature. İyi haber şu ki şu anda hiçbir hatamız yok master. Kötü haber şu ki, sürekli entegrasyon adımlarından oluşan değerli listemiz de bitti. Bu nedenle ideal olarak düzeltmeyi taahhütlere uygulamamız gerekir. feature ve onları iade et master düzeltmeyle birlikte.

Soruna farklı şekillerde yaklaşabiliriz:

• birleştirmeyi geri alan bir işlemi geri alma feature с master;
• öncekinden taşıma taahhütleri feature.

Bu durumda farklı geliştirme ekipleri farklı yaklaşımlar kullanır, ancak yararlı taahhütleri ayrı bir şubeye taşıyacağız ve bu yeni şube için ayrı bir çekme isteği oluşturacağız.

️Görev

1. adında bir konu oluşturun feature-fix ve geçiş yapın.

2. Önceki şubedeki tüm taahhütleri taşı feature yeni bir konuya. Geçiş sırasında meydana gelen birleştirme çakışmalarını çözün.

   

3. Bir regresyon testi ekleyin ci.test.js:

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

4. Başarısız olmadıklarından emin olmak için testleri yerel olarak çalıştırın.
5. "Sinsi bir hatayla" metnini kaldırın ci.md.
6. Test değişikliklerini ve adım listesi değişikliklerini dizine ekleyin ve bunları kaydedin.
7. Şubeyi uzak bir depoya yayınlayın.

Buna benzer bir şey elde etmelisiniz:

Takımlar

# Создайте ветку под названием 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

Bir çekme isteği oluşturun.

Başlığı olan bir çekme isteği oluşturun Özelliğin düzeltilmesi... Düzenlemek feature-fix "ana dal" gibi ve master "temel dal" gibi.
Testler tamamlanana kadar lütfen bekleyin. Testlerin durumunu PR tartışmasının alt kısmında görebilirsiniz.

Yüklediğinizden emin olun master onun içinde depoyu çatalla Bir "temel dal" olarak ders materyalleri deposundaki değişiklik taleplerine yanıt vermeyeceğim.

Çekme isteğini onayla "Özellik düzeltiliyor"

Düzeltme için teşekkürler! Lütfen değişiklikleri onaylayın master çekme isteğinden.

️Görev

1. "Çekme isteğini birleştir"i tıklayın.
2. "Birleştirmeyi onayla"yı tıklayın.
3. Artık ihtiyacımız kalmadığı için "Şubeyi sil"i tıklayın.

Şu anda sahip olmanız gereken şey bu.

Tebrikler!

İnsanların sürekli entegrasyon sırasında genellikle attığı tüm adımları tamamladınız.

Kursla ilgili herhangi bir sorun fark ederseniz veya onu nasıl geliştireceğinizi biliyorsanız, lütfen şu adreste bir sorun oluşturun: ders materyalleri içeren depolar. Bu kursta ayrıca etkileşimli sürüm GitHub Learning Lab'ı platform olarak kullanmak.

Kaynak: habr.com