Yayına dayalı iş akışı nedir?

Tamamlandı

Burada, GitHub kullanarak yayına dayalı iş akışını nasıl oluşturabileceğiniz açıklanmaktadır.

Yayına dayalı iş akışı nedir?

Yayın tabanlı iş akışı, yazılım yayınlamaya odaklanan bir dizi desen ve ilkedir. Bu fikir geliştirme ekibi için belirgin bir hedef gibi görünse de, bu perspektifin değeri daha incedir. Bu ünitede yayın döngüsünün üç farklı bölümünü nasıl yönlendirdiğinden bahsedeceğiz: projeyi yönetme, dallanma stratejisi seçme ve müşterilere yayınlama.

GitHub proje panolarıyla çalışmayı planlama

Planlama açısından bakıldığında yayın odaklı olmak, sorunların yeni bir sürüm üreten ayrı yinelemelere bölünmesi anlamına gelir. Bu yinelemeler genellikle sprint olarak adlandırılır ve artımlı değişiklikler üretmek için kabaca eşit dönemlerde zaman kutulanır. Başka takımlar, yayın sürümlerinin tamamını, birkaç ay veya daha uzun sürebilecek tek bir yinelemede paketlemeyi tercih eder. GitHub'da bu yinelemeler proje olarak yönetilir.

Bir projenin baskın özelliği yönetim kuruludur. Pano, yineleme için merkezi kayıt planıdır ve çözümlenecek tüm kartları içerir. Kart bir sorunu, çekme isteğini veya genel bir notu temsil edebilir.

Varsayılan olarak, her kart Yapılacaklar sütununda başlar ve iş başladıktan sonra Devam Ediyor sütununa geçer, en sonunda Bitti sütununda biter. Bu sütunları özelleştirebilir, daha fazla sütun ekleyebilir veya ekibinizin sürecine uyacak şekilde bu kartların ve özelliklerinin hareketine otomasyon uygulayabilirsiniz.

Proje panolarını yönetme hakkında daha fazla bilgi edinin.

Kartın proje durumu, depoyla tümleştirilir. Örneğin, bir kartın To Do konumundan Devam ediyor konumuna sürüklendiğinde, kartın durumu değişir ve proje başlığının yanındaki görsel göstergeyi güncelleştirir. Yeşil bölüm, kartların Bitti olarak işaretlenmiş kısmını gösterirken, devam eden kartlar için mor kullanılır. Kalan alan, henüz başlamamış olan kart miktarını temsil eder. Kartları panonun etrafında sürüklemeye ek olarak, bunları ana görünümlerinden güncelleştirebilirsiniz.

Proje panosu kullandığınızda, tüm paydaşların projenin durumunu ve hızını anlamanın kolay bir yolu vardır. Kapsamı tek tek kullanıcılar olan veya bir kuruluşa ait depolar koleksiyonu olan panolar da oluşturabilirsiniz.

Proje panolarıyla çalışmanızın ilerleme durumunu izleme hakkında daha fazla bilgi edinin.

Belirli kilometre taşlarını izleme

GitHub, ekipler veya büyük olasılıkla ekiplerin alt kümeleri için kilometre taşı izlemesi sunar.

Kilometre taşları, sorunların ve çekme isteklerinin öncelikli olarak tamamlanmasına vurgu yapılan proje izlemeye benzer. Ancak, bir projenin ekibin sürecine odaklanabileceği durumlarda, bir kilometre taşı ürüne odaklanır.

Kilometre taşlarıyla çalışmanızın ilerleme durumunu izleme hakkında daha fazla bilgi edinin.

Dallanma stratejisi seçme

Birden çok geliştiricinin paralel olarak çalıştığı depolar için düzgün tanımlanmış bir dallanma stratejisi gerekir. Projenin erken aşamalarında birleşik bir yaklaşıma sahip olmak, ekip ve kod tabanı ölçeğinde karışıklık ve sinir bozuculuk yaratır.

GitHub akışı

GitHub, işbirliğine dayalı yazılım geliştirme platformu sağlamaya ek olarak, çeşitli özelliklerinin kullanımını iyileştirmek için tasarlanmış, önceden tanımlanmış bir iş akışı da sunar. GitHub neredeyse tüm yazılım geliştirme süreçleriyle çalışasa da ekibiniz henüz bir sürece karar vermemişse GitHub akışını göz önünde bulundurmanızı öneririz.

Uzun süreli dallarla çalışma

Uzun süreli dal, hiçbir zaman silinmemiş bir Git dalıdır. Bazı ekipler, kısa süreli özellik ve hata düzeltme dalları için bu ekiplerden tamamen kaçınmayı tercih eder. Bu takımlar için, tüm eforların hedefi, işini main içinde birleştiren bir çekme isteği üretmektir. Bu yaklaşım, önceki bir sürümü desteklemeyen birinci taraf web uygulamaları gibi hiçbir zaman geriye bakma gereksinimi olmayan projeler için etkili olabilir.

Ancak uzun süreli dalın, takımın öncelikli çıkarlarını desteklediği belirli durumlar vardır. Uzun süreli dal için en yaygın durum, bir ürünün, uzun süre boyunca desteklenmesi gereken birden çok sürümünün olması durumudur. Bir takımın bu taahhüt için plan yapması gerektiğinde depo release-v1.0, release-v2.0 vb. standart bir kuralı izlemelidir. Yazma erişiminin denetlenmesi ve yanlışlıkla silinememeleri için bu dalların GitHub'da korumalı olarak işaretlenmesi gerekir.

Takımlar, kök dal olarak main bakımını yapmaya devam etmeli ve projenin geleceğine uyduğu sürece yayın dalı değişiklikleri yukarı akışını birleştirmelidir. release-v3.0 için bakım çalışmasının depoyu karmaşıklaştırmaması için zamanı geldiğinde main, release-v2.0 öğesini temel almalıdır.

Uzun süreli dallara bakım yapma

Bir hata düzeltmesinin release-v2.0 dalıyla birleştirildiğini ve sonra da yukarı akışın main dalıyla birleştirildiğini varsayın. Daha sonra bu hatanın release-v1.0 dalda da bulunduğu ve düzeltmenin hala bu sürümü kullanan müşteriler için geri aktarılması gerektiği keşfedildi. Bu düzeltmeyi geri aktarmanın en iyi yolu nedir?

Dalın main içine release-v1.0 birleştirilmesi uygun bir seçenek değildir çünkü bu sürüme dahil edilmesi amaçlanmamış çok sayıda işleme içerir. Aynı nedenle geçerli release-v1.0 işlemeye yeniden bağlanma main seçeneği yoktur.

Alternatif bir seçenek olarak release-v1.0 dalında düzeltme el ile yeniden uygulanabilir, ancak bu yaklaşım için çok daha fazla yeniden çalışma gerekir ve birden çok sürümde ölçekleme de yapılamaz. Öte yandan Git, cherry-pick komutu biçiminde bu soruna otomatik bir çözüm sunar.

Git’in seçerek uygulama komutu nedir?

git cherry-pick, bir daldan diğerine belirli commit’leri uygulamanıza olanak sağlayan bir komuttur. Yalnızca seçilen commit’leri yineler ve bunları hedef dala yeni commit’ler olarak uygular. Gerekirse, geliştiriciler eski sürüme taşımayı tamamlamadan önce tüm çakışmaları birleştirebilir.

Git'in cherry-pick'i hakkında daha fazla bilgi edinin.

Tüketicilere yayınlama

Bir ürün yayınlanmaya hazır olduğunda GitHub, ürünü paketleme ve tüketicilere bildirim gönderme işlemini kolaylaştırır.

Sürüm oluşturma, formu doldurmak kadar kolaydır:

• Uygulanacak bir Git etiketi girin. Bu etiket gibi v1.0.2 izlemelidir. GitHub, belirttiğiniz Git etiketini oluşturma sürecini yönetir.
• Yayınınız için bir ad girin. Bazı yaygın yöntemler şunlardır:
  • Açıklayıcı bir ad kullanma
  • Git sürümünü kullanma
  • Yayının önceki sürümden bu yana nasıl değiştiğine ilişkin kısa bir özet kullanın
  • Kod adı veya rastgele tümcecik kullanma
• Yayın notları sağlayın. Bu görevi, önceki sürümden bu yana yapılan değişiklikleri analiz eden ve ilişkili çekme isteği başlıklarını içeren Yayın Taslak Oluşturucu uygulamasıyla otomatikleştirebilirsiniz.
• Sürümün bir parçası olarak önceden oluşturulmuş yükleyiciler gibi dosyaları sağlamak istiyorsanız, bunları forma sürükleyip bırakabilirsiniz. GitHub sizin için otomatik şekilde gerçekleştirdiğinden, kaynağı paketlemeniz gerekmez.
• Bu kutuyu işaretleyerek sürümün yayın öncesi olup olmadığını belirtin. Bu gösterge, müşterilerin isterse yayın öncesi sürümlerden kaçınmasına yardımcı olur.

Yayın yayımlandıktan sonra depoyu izleyen herkes bir bildirim alır.

GitHub sürümleri hakkında daha fazla bilgi edinin.