- GitHub Actions’a yönelik memnuniyetsizlik
- Ekip yaklaşık 15 mühendisten oluşuyor ve herkes sürekli olarak
main branch’ine kod push ediyor
- Kod, birden çok modüle ayrılmış bir monorepo yapısında bulunuyor ve trunk tabanlı geliştirme yaklaşımıyla günde birkaç kez deploy ediliyor
- GitHub Actions’ın iyi kullanıldığı durumlar da var, ancak belirli bir ölçek veya ortamda sınırları net biçimde ortaya çıkıyor
Pull request ve zorunlu kontroller
- Monorepo birden fazla klasöre ayrılmış durumda ve her klasör için test, build ve deploy işlemleri bağımsız olarak yürütülüyor
- GitHub Actions
paths özelliği kullanılarak yalnızca belirli bir klasörde değişiklik olduğunda ilgili pipeline tetikleniyor
- Pull request merge edilmeden önce tüm kontrollerin geçmesi gerektiği ilkesi iyi olsa da, monorepo yapısıyla birleştiğinde sorun yaratıyor
- Örnek:
web-app1 - Unit tests adlı kontrol “zorunlu” olarak ayarlanmışsa, ancak web-app1 klasöründe değişiklik yoksa bu kontrol hiç çalışmıyor
- Sonuç olarak yalnızca bir taraftaki klasör değişse bile diğer klasörlerle ilgili testler çalışmadığı için merge işleminin kendisi imkansız hale geliyor
- GitHub tarafında zorunlu kontroller isim bazında değil de, “o anda tetiklenen tüm kontroller geçerse merge edilebilir” gibi bir yaklaşımla ele alınsa sorun çözülebilir; ancak 3 yıldır bir değişiklik olmaması hayal kırıklığı yaratıyor
- İlgili GitHub issue başlıklarında 1, 2 bu sorunun ne kadar büyük etkisi olduğu da görülebiliyor
- Sonuçta bunu aşmak için ek pipeline’lar çalıştırmak veya bakımını yapmak karmaşık ve maliyetli hale geliyor
Yeniden kullanılabilirlik ve YAML
- Pipeline ölçeği büyüdükçe GitHub Actions ile yönetmek giderek daha zor hale geliyor
- Çok sayıda
if ifadesi ekleniyor ve workflow’ları ayırsanız bile yönetilecek dosya sayısı arttığı için bakım kolaylığı düşüyor
- Yeniden kullanımda tek satırda bitebilecek çağrı bölümü bile birden fazla satır ve tekrar eden ayarlar gerektiriyor; bu yüzden
.github klasöründe şimdiden 30’dan fazla dosya birikmiş durumda
needs bölümü de refactor sırasında silinen job’ları yansıtmazsa hatayı fark etmek zaman alıyor- GitHub Actions yerelde çalıştırılamadığı için geliştirme ve test süreçleri zorlaşıyor
act gibi araçlar olsa da, gerçek kullanımda kısıtları fazla olduğundan çoğu zaman beklentileri karşılamıyor
GitHub’ın ilgisizliği
- Yukarıdaki sorunlar içinde en büyük problem, GitHub’ın bu issue’ları çok da önemli görmüyor gibi durması
- Birçok issue’nun yıllardır açık kalması ve açık roadmap’e dahil edilmemesi, iyileştirme konusunda istek olmadığı izlenimini veriyor
- Uzun süredir gündemde olan bazı sorunlarla ilgili issue’ların yakın zamanda topluca kapatılması da toplulukta tepkiye yol açtı
Seçenekler
- Bu sorunlar ve GitHub’ın iyileştirme konusundaki isteksizliği düşünüldüğünde, GitHub Actions’ı benimsemeden önce dikkatli olmak gerekiyor
- Piyasada GitLab, Jenkins, TeamCity gibi çeşitli başka CI/CD seçenekleri bulunuyor
- Dagger gibi yeni yaklaşımlar sunan araçları değerlendirmek de faydalı olabilir
6 yorum
CI/CD için en iyisi gitlab
Ben de GitLab kullanırken GitHub Actions ortamına geçtiğimde hiçbir şeyin çalışmadığını düşündüğümü hatırlıyorum...
GitHub'da depoları gruplara göre toparlayıp yönetememek de benim en büyük memnuniyetsizliklerimden biri..
Pipeline konusunda GitLab gerçekten çok iyi gibi görünüyor. Yukarıda söylenenlerin hepsi GitLab'da zaten yapılabiliyor.
Monorepo söz konusu olduğunda, hangi klasör değişirse hangi şeylerin çalıştırılması gerektiğini yapılandırmak da kolay.
Bunun için GitHub Actions’ın geçmişini bilmek gerekiyor ama...
İlk GitHub Actions, bugünkü durumdan farklı bir tablo çiziyordu...
Açılmasından 6 ay kadar önceydi galiba (hafızam biraz bulanık), GitHub Microsoft tarafından satın alınmıştı ve sanırım Actions geliştirmesinin Microsoft tarafında Azure DevOps ekibiyle birlikte yürütülmesine karar verilmişti.
Bu sırada Azure DevOps’a artık yeni özellik gelmiyordu ve Azure DevOps’taki özelliklerin yenileri GitHub Actions’ta çıkıyordu...
O dönemde YAML’a geçildi ve bugünkü ortam oluşmuştu.... hüzünlü yüz
Sonrasında geliştiriciler kendi ana işlerine geri döndü ve artık üzerinde fazla çalışılmayan bir durumda gibi görünüyor...
Üzücü...
Şu an şirkette CI/CD’yi GitHub Actions tabanlı kurduk... şimdilik eksik hissettiğimiz bir nokta olmadığı için kullanmaya devam ediyoruz ama...
Yine de dikkatle izlemek gerekecek sanırım...
Hacker News görüşleri
Pipeline DSL, gerçek mantığı içermemeli; yalnızca işleri orkestre etmek için kullanılmalı. Karmaşık işler script olarak hazırlanmalı ve basitçe çalıştırılabilir olmalı. Bu sayede aynı işler GitHub Actions, Jenkins, Azure DevOps gibi ortamlarda kolayca yürütülebilir
GitHub Actions yapılandırırken, önceden hazırlanmış action'lardan kaçınıp onu yalnızca basit bir shell çalıştırıcısı olarak kullanmak daha iyi. Script'leri Python, Ruby, Bash vb. ile yazıp GitHub Action içinde çalıştırırsanız yerelde test etmek kolaylaşır ve gereksiz acıyı azaltır
GitHub Actions, yalnızca belirli koşullar sağlandığında kontrolleri çalıştırabilir. Ancak bu kuralları kullanınca "Pull request ve zorunlu kontroller" sorunuyla karşılaşırsınız. Harici servislerle kullanırken zorunlu kontroller mutlaka geçmelidir; aksi halde merge yapılamaz
'Pull request ve zorunlu kontroller' sorununu çözmenin bir yolu, her zorunlu kontrol workflow'u için bir 'no op' sürümü oluşturup koşullar sağlanmadığında bunun çalışmasını ve 0 koduyla çıkmasını sağlamaktır. Bu, temel olarak işe yarayan ama biraz karmaşık bir çözümdür
Travis CI, CI'ı yerelde test etmek için harikaydı. GitHub Actions, GitLab CI ile rekabet etmek için yapıldı ve şirket pazarında pay kaybediyordu
Buildkite denemeniz öneriliyor. GitHub Actions'ın ötesine geçiyorsanız Buildkite iyi bir alternatif olabilir. Büyük ölçekli Amerikan teknoloji şirketlerinde kullanma deneyimi olmuş ve CI'ın tek keyifli kısmı buydu
GitHub Actions'ın mimarisi, güvenlik kararlarının yanlış verilmesine yol açabilir. Örneğin organizasyon veya depo secret'ları kullanışlıdır ama güvenlik açığına dönüşebilir. Depo environment'larının ayrı secret'ları olabilir, ancak doğru workflow'un yalnızca doğru environment'a erişebilmesini sağlamanız gerekir
CI sistemlerinin genel felsefesi hatalı. CI'ın kodu çalıştırması yerine, kod CI'ı çalıştırmalı. CI, kullanıcıların sisteme bilgi verebilmesi için bir API sunmalı
Bazel kullanarak CI aracının Bazel target'larını build etmesini sağlayabilir ve gerektiğinde remote build execution ile paralelliği artırabilirsiniz. Bu yaklaşım yaklaşık 10M+ satır kod ya da büyük ölçekli servisler için uygundur
GitHub'da her zaman yeşil kalması gereken "zorunlu kontroller" tanımlanabilir. Ancak bunlar yalnızca belirli klasörlerde değişiklik olduğunda çalışıyorsa, başka klasörlerde değişiklik yapıldığında merge edemezsiniz. Tüm testleri çalıştırmıyorsanız entegrasyonun anlamı kalmaz; bu yüzden testleri hızlı çalıştırabilir hale getirmek gerekir