Yaptığımız en hızlı CI başarısız oldu

 (earthly.dev)
1 puan yazan GN⁺ 2023-09-13 | 1 yorum | WhatsApp'ta paylaş
  • CI/CD araç pazarında mevcut sağlayıcılarla doğrudan rekabet etmek yerine derleme hızına odaklanan Earthly, Earthly CI'ı sonlandırıp odağını yeniden Earthly ve Satellites'a kaydırıyor
  • Orijinal vizyon, derleme sistemi ile CI'ı tek bir yapıda birleştirmek ve bunu dağıtık çalıştırarak otomatik paralellik, önbellekleme ve yerel yeniden üretilebilirliği birlikte sunmaktı
  • Earthly ve Earthly Satellites sırasıyla derleme tutarlılığı ve 2 ila 20 kat daha hızlı CI işlem hatları ile doğrulama aldı, ancak tam teşekküllü bir CI ikame ürünü yeterli dönüşüm yaratamadı
  • Yeni müşteriler geçiş maliyetini ve betikleri yeniden yazma yükünü büyük bir engel olarak gördü; mevcut Satellites müşterileri ise GitHub Actions gibi mevcut CI kombinasyonlarıyla Earthly CI değerinin zaten %95'ini elde ediyordu
  • Earthly CI, 1 Ekim 2023 tarihinde kapatılıyor; Earthly ise kullanıcıların mevcut CI'larını korurken daha hızlı derlemeler elde etmesini sağlayan Satellites'a yatırım yapıyor

Earthly CI'ın kapatılması ve yeniden odaklanma

  • Earthly, Earthly CI'ı kapatıyor ve şirketi Earthly ile Earthly Satellites etrafında yeniden yapılandırıyor
  • Bundan sonra odaklanacağı değer iki başlıkta toplanıyor
    • yerel derlemeler ve yeniden üretilebilirlik
    • mevcut CI ile birlikte kullanılabilen Earthly Satellites
  • Earthly CI hızlı CI'ı hedefliyordu, ancak pazarda yeterli erken benimseme sinyali üretemedi

“En hızlı CI” için ilk vizyon

  • Earthly, Nisan 2020'de CI/CD araçlarını iyileştirme hedefiyle yola çıktı
  • Çıkış noktası iki soruydu
    • CI dizüstü bilgisayarda da çalışabilse nasıl görünürdü
    • dünyadaki en hızlı CI sistemi nasıl görünürdü
  • Earthly'nin bulduğu yanıt, derleme sistemi ile CI'ın aynı şey olması ve aynı zamanda dağıtık çalışması gerektiğiydi
  • Amaç, değişiklikten etkilenmeyen derleme adımlarını tekrar etmemek, otomatik paralel çalıştırma sağlamak ve derlemenin herhangi bir bölümünü dizüstü bilgisayarda güvenilir biçimde yeniden üretmekti

Küçük bir ekibin mevcut CI sağlayıcılarıyla rekabet etme yolu

  • Erken aşama bir girişimin; tamamlanmışlık, özellik sayısı ve entegrasyon kapsamı açısından para, insan kaynağı, itibar ve 10 yılı aşkın avantajı olan mevcut sağlayıcılarla rekabet etmesi zordur
  • Earthly'nin seçtiği strateji, tüm pazarı ikna etmeye çalışmak yerine belirli bir sorunu çok ağır yaşayan az sayıdaki ekibe 10 kat daha iyi bir çözüm sunmaktı
  • İlk doğrulama, üründe hatalar ve kısıtlar olsa bile onu büyük bir hevesle kullanan küçük bir kullanıcı grubunun oluşmasına yakındı
  • MVP yeterli doğrulama almadığında yalnızca daha fazla özellik eklemek, mevcut oyuncuların avantajlı olduğu bir rekabete sürüklenmeye yol açabilir

Earthly CI'a giden 3 aşamalı plan

  • Earthly, nihai hedefi olan Earthly CI'ı doğrudan inşa etmek yerine bunu birbirinden bağımsız birkaç ürüne bölerek adım adım doğrulamayı denedi

  • 1. aşama: Earthly

    • İlk kilometre taşı Earthly idi
    • Earthly önce derleme sözdizimini ve isteğe bağlı derleme çalıştırma deneyimini sundu
    • Temel değer, yürütme ortamından bağımsız olarak derlemelerin aynı şekilde çalışmasını sağlayan derleme tutarlılığı idi
    • İlk dönemde yerelde ve farklı CI sistemlerinde çalıştı, daha sonra binlerce depoda kullanılmaya başlandı
    • VMware, Adobe, Namely, Roche, ExpressVPN ve Bluecore kullanıcılar arasında anıldı
    • Bu, tek geliştiricili ve finansmansız bir projeydi; hataları ve sınırlamaları vardı ama insanların gerçekten kullanması bir doğrulama sinyali oldu

  • 2. aşama: Earthly Satellites

    • İkinci kilometre taşı Earthly Satellites idi
    • Satellites, dizüstü bilgisayardan ya da herhangi bir CI'dan çağrılabilen uzak bir çalıştırıcıdır
    • Önbellekleme ve paralellik sayesinde CI işlem hatlarını 2 ila 20 kat hızlandıran derleme hızı temel değerdi
    • Earthly açık kaynak olduğu için kullanıcılar, ticari hizmet çıkmadan önce de Buildkit tabanlı uzak çalıştırıcıları kendileri yöneterek benzer etki elde edebiliyordu
    • Yönetilen Satellites çıktığında kullanıcılar, uzak çalıştırıcıyı kendileri yönetmemek için ürünü kullanmaya başladı
    • İlk Satellites sürümleri hatalı, verimsiz ve kararsızdı; ancak aynı düzeyde CI/CD hızı sunan alternatifler az olduğu için kullanıcı çekti

  • 3. aşama: Earthly CI

    • Üçüncü kilometre taşı Earthly CI idi
    • Earthly CI, Earthly ile Satellites'ı birleştiren tam bir CI platformuydu ve GitHub Actions, CircleCI, Jenkins gibi CI çözümleriyle rekabet etmeyi amaçlıyordu
    • Earthly derleme tutarlılığına, Earthly CI ise derleme hızına odaklandığı için ücretsiz Earthly'nin Earthly CI gelir modelini baltalamayacağı düşünülüyordu
    • Ancak daha sonra tutarlılık ile hız arasındaki değer önerisi farkı bir soruna dönüştü

Lansman sonrası ortaya çıkan geçiş engeli

  • Earthly CI lansmanını yaptı, TechCrunch tarafından tanıtıldı ve Reddit ile Hacker News için blog yazıları hazırlandı
  • Lansmandan sonraki ilk 1-2 haftada bekleme listesine yaklaşık 50 e-posta adresi kaydoldu ve bu hedefin üzerindeydi
  • Yeni müşteriler ile mevcut Earthly kullanıcıları arasında belirgin bir fark vardı
    • Yeni müşteriler çoğu zaman “CI'lar sadece sözdizimi bakımından farklıdır, gerisi benzerdir” diye düşündü ve Earthly CI'ın farkını derinlemesine incelemedi
    • Görüşmelerin çoğu, mevcut betikleri yeniden yazma ve uyum sağlama gerektiren geçiş maliyeti etrafında döndü
    • Mevcut Earthly kullanıcıları ise Earthfile dönüşümünü zaten tamamlamış ve Earthly'nin avantajlarını deneyimlemiş oldukları için kurum içinde savunucu olmaya hazırdı
  • Yeni müşteriler nezdinde Earthly'nin vaat ettiği avantajları büyük ölçekte sunabileceğine dair itibar eksikti ve kısa bir Zoom görüşmesinde mevcut kullanıcı deneyimindeki “10 kat daha kolay” hissini kanıtlamak zordu

Mevcut müşteriler neden Earthly CI'a geçmedi

  • Mevcut Earthly Satellites müşterilerinin çoğu, CI/CD süreçlerinde zaten Satellites kullanıyordu
  • Earthly, CI sağlayıcısının yalnızca işlem hattı tetikleyicisini üstlendiğini ve gerçek çalıştırmanın Satellites üzerinde gerçekleştiğini gördüğü için Earthly CI ihtiyacının doğrulandığını düşündü
  • Ancak Satellites müşterileri Earthly CI değerinin zaten %95'ini alıyordu
  • GitHub Actions + Satellites yapısıyla karşılaştırıldığında Earthly CI yeterince daha iyi değildi ve geçmek için güçlü bir neden sunmuyordu
  • Mevcut Earthly kullanıcılarının Earthfile kullandığı için geçişin kolay olacağı düşünülse de pratikte gereksinimler daha fazlaydı
    • GitHub eklenti ekosistemi
    • codecov action
    • manuel tetikleme
    • git tag oluşturma temelli tetikleme
    • makine boyutu seçimi
    • eski derlemeleri iptal etme
    • derleme sırlarını emanet edebilecekleri güven
  • Earthly CI MVP'si en hızlı CI'dı, ancak bazı temel gereksinimleri karşılamıyordu
  • Bazı hevesli kullanıcılar Earthly CI'ı denedi, ancak bütçesi olan daha büyük organizasyonlarda 2-3 kişiden öteye yayılamadı
  • Earthly CI kullanan bazı kullanıcılar daha sonra hem GitHub ekosistemini hem de Satellites hızını almak için Satellites kullanıcısına dönüştü

Demo talebinin neden tersine olumsuz sinyal olduğu

  • Earthly potansiyel müşterilerle 100'den fazla görüşme yaptı, ancak yüz yüze konuşmalarla Earthly CI, Satellites ya da Earthly ürünlerinden herhangi birini kullanmaya ikna etmek zordu
  • Buna karşılık kullanıcılar web sitesi, ürün odaklı büyüme, kulaktan kulağa yayılma ve içerik pazarlaması üzerinden kendiliklerinden geldiğinde Earthly'nin benimsenmesi her gün gerçekleşiyor ve artış gösteriyordu
  • Geliştirici araçları, özellikle entegrasyon çalışması gerektiren araçlar, geleneksel doğrudan satış yöntemiyle doğrulanması zor ürünlerdi
  • En güçlü olumsuz eleme ölçütü, demo talep eden potansiyel müşteriler oldu
  • Gerçekten dönüşen ekipler Earthly'yi indirip belgeleri okuyor, Earthfile'ı kendileri yazıyor ve ardından iletişime geçiyordu; demoya ihtiyaç duymuyordu
  • Entegrasyon gerektiren geliştirici araçları, kullanıcının kendi takvimine göre benimsenir; zorla satılması ya da hızlıca itilmesi zordur

“CI” yerine “build” kullanan A/B testi

  • O dönemde Earthly web sitesinin mesajı “Earthly makes CI super simple” idi ve ilk ekranın büyük kısmı CI'ı vurguluyordu
  • Gavin Johnson, web sitesinde “CI” kelimesini “build” ile değiştiren bir A/B testi önerdi
  • Metin “Earthly makes builds super simple” olarak değiştirildi
  • Sadece bu tek kelimelik değişiklik, ana CTA olan “Get Earthly” sayfasındaki dönüşümü iki katına çıkardı
  • Bu sonucun ardından Earthly CI'ın kendisine yönelik şüpheler büyüdü

ShiftLeft deneyiminden çıkarılan dersler

  • Earthly'den önce başlatılan ShiftLeft bugün Qwiet.ai adıyla biliniyor
  • İlk vizyon, üretim ortamına kurulan ve kaynak koddaki güvenlik açıklarını kullanan saldırılardan bulut uygulamalarını koruyan bir güvenlik ajanıydı
  • Bu ürün, birden fazla programlama dilini destekleyen kod çözümleyicileri, çalışma zamanına özel ajanlar ve her şeyi birleştiren dağıtık bir arka uç gerektiriyordu; bu da küçük bir girişimin aynı anda üç şirketlik karmaşıklıkta bir sistem kurmasına benziyordu
  • Bir yıldan uzun çabanın ardından tek bir programlama dilinde uçtan uca çalışan bir yapı oluşturuldu, ancak pazar tepkisi iyi olmadı
  • Güvenlik ürününün hedef müşterileri, regülasyonun ağır olduğu kurumsal şirketlerdi ve ürünü hem CI/CD'ye hem de üretim ortamına yerleştirmek gerektiği için benimseme yolu çok zordu
  • O dönemde daha fazla özellik eklemenin benimseme zorluğunu aşacağı düşünüldü ve bunun için 1,5 yıl daha geliştirildi, ancak pazar bunu istemedi
  • Daha sonra, bu karmaşık ürünün iki farklı ürüne bölünebileceği fark edildi
    • güvenlik uzmanları için bir kod içgörü aracı
    • pazardaki diğer kod çözümleyicilerden 40 kat daha hızlı bağımsız bir kod çözümleyici
  • En büyük pişmanlık, sinyaller ortadayken daha erken durmamış olmaktı

Earthly'nin vardığı sonuç

  • Earthly'nin özetlediği tablo şuydu
    • insanlar daha hızlı derlemeler istiyor
    • insanlar CI değiştirmekten hoşlanmıyor
    • yeni CI ürünlerinin farklılaşmadığı yönünde bir damga var ve kullanıcılar web sitesinde “CI” kelimesini görür görmez ayrılıyor
    • müşteriyle doğrudan temas kurulan tasarım ortağı benzeri yaklaşım, yüksek geçiş maliyeti algısı nedeniyle işlemiyor
    • Earthly CI MVP'si yeterli bir erken benimseyen kitlesi oluşturamadı
    • mevcut CI'ı değiştirmeden Earthly Satellites ile daha hızlı derleme elde edilebildiği söylendiğinde tepki olumlu oluyor
  • Temel sorun Earthly CI'ın özellik eksikliği değildi
  • Umut vadeden bir erken ürün için, eksik özellikleri tolere edip yine de avantajı almak isteyen bir grubun var olması gerekir; ancak Earthly CI tarafında bu düzeyde yeterli sinyal oluşmadı
  • Bu nedenle Earthly, Earthly CI'ı kapatıp çalışan ürünler olan Earthly ve Earthly Satellites'a odaklanma kararı aldı

Kapanış takvimi ve kullanıcı geçişi

  • Earthly CI 1 Ekim 2023 tarihinde kapatılıyor
  • Earthly CI beta/deneysel olarak etiketlenmiş olsa da Earthly, kullanıcıların geçişine destek veriyor
  • Earthly, her türlü CI ile birlikte çalıştığı için Earthly CI'dan ayrılma yönündeki geçişin kolay olduğunu düşünüyor
  • Hızlı derlemelere devam etmek isteyenler Earthly Satellites bağlayabilir; Satellites için ücretsiz katman da bulunuyor
  • Geçiş desteği doğrudan Earthly Slack community üzerinden sunuluyor

Satellites için gelecekteki yatırım yönü

  • Earthly Satellites, hızlı ve tutarlı derlemelerin yanı sıra kullanıcıların kendi CI'larını koruyabilmelerini sağladığı için büyüme sinyalleri gösteriyor
  • Earthly CI'ın kapatılmasıyla kazanılan zaman, Earthly topluluğunun talep ettiği özelliklere yatırılacak
    • CPU, bellek, disk ve ağ I/O kullanımını içeren Satellite metrics
    • hem yerel derlemeler hem de Satellites derlemeleri için web arayüzünde Build history
    • değişen dosyalar derlemeyi etkilemiyorsa anında atlayan Auto-skip
    • docker build için hızlı bir alternatif olarak Satellites üzerinde Dockerfile derlemelerini uzaktan çalıştırma özelliği
    • self-hosted remote Buildkit için daha iyi desteklenen sürüm olan self-hosted Satellites
    • tek bir derlemeyi birden fazla Satellite'a dağıtarak hızlandırma özelliği
    • tamamen dağıtık, sunucusuz Satellites olan Compute v2
  • Earthly Satellites, herhangi bir CI ile birlikte çalışan bir uzak derleme çalıştırıcısıdır ve Earthly Cloud üzerinden kullanılabilir
  • Earthly, bir kez yazıp her yerde çalıştırılabilen derleme tutarlılığı sunan ve CI hatalarını yerel bilgisayarda kolayca yeniden üretmeye yardımcı olan açık kaynak bir derleme çatısıdır

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-13
Hacker News yorumları

  • Açık kaynak yaparken temel değerin tamamını elden çıkarmamak gerektiğini iyi gösteren bir yazı. Earthly açık kaynak olduğu için Earthly Satellite kullanıcıları zaten Earthly CI değerinin %95’inden yararlanıyordu.
    Açık kaynağı çok seviyorum, ama iş modelinizde açık kaynak varsa bir farklılaştırıcı unsur gerekir. Sadece aşırı hızlı olmanın ötesinde, insanların kredi kartını, hatta muhasebe satın alma siparişi sürecini devreye sokması için bir neden olmalı.
    GitLab, CI/CD’yi ücretli müşterilerle sınırlandırıyor; Travis/CircleCI derleme süresini veya kredileri kısıtlıyor; Azure DevOps şeytani; ArgoCD ise karmaşık. GitHub Actions, çalıştırıcıları döndürecek donanımınız varsa fena değil; kurumsal tarafta da Jenkins sürüleri daha tanıdık geliyor.
    Eski bir DevOps direktörü olarak ilk soracağım şey şu olur: “Bunu kendimiz barındırmak yerine satın almamızı sağlayan özellik ne?” Bunu bizzat işletebilecek teknik yeteneğim varsa, bulutumu ve DevOps pipeline’ımı işimize uygun şekilde çalıştırabiliyorsam neden size para ödemem gerektiğine beni ikna etmelisiniz.
    Yazılımın çalışması için zorunlu özellikleri saklayın demiyorum; destek veya kurumsal düzey entegrasyonlar gibi işlevleri ücretli tutmaktan söz ediyorum. İleri düzey kullanıcılar kendi kendilerine daha fazla destek verdikleri için daha az ödeyecekleri katmanlı bir model de mümkün görünüyor.

    • Geliştirici araçları alanında özellik kısıtlamasının geleneksel olarak ne kadar işe yaradığından emin değilim. Araçlardan kaçış oranı zaten çok yüksek; Earthly ürünü bilerek zayıflatırsa çoğu geliştirici muhtemelen daha kötü olsa bile ücretsiz bir alternatife, örneğin taskfile’a geçer.
      Kalan kullanıcıları ücretliye çevirmek mümkün olabilir ama bu oldukça büyük bir kumar. Yakın zamandaki iyi bir ters örnek Docker olabilir; ancak orada katı açık kaynaktan vazgeçip tartışmalı lisans ve ürün değişiklikleri yapmak gerekti.
    • “Kurumsal tarafta Jenkins sürüleri daha tanıdık” kısmını görünce, bunu yapan son kurumun biz olduğumuzu sanıyordum; bu kutsal olmayan kurulumun bir ölçüde standart olduğunu görmek tuhaf biçimde içimi rahatlattı.
    • GitLab CI çalıştırıcısı kendi ortamınızda barındırılabilir ve ücretsiz Community Edition’da da kullanılabilir.
    • Tartışmalı olabilir ama servislerde “open core” yerine ticari source available yaklaşımının daha ana akım ve daha az tepki çeken bir yol olmasını isterdim.
      “Open core”un dışındaki kodu okuyamamak, hata düzeltmelerine katkı verememek veya kendiniz barındıramamak çok can sıkıcı; açık kaynak lisanslarıyla source available lisanslarını ayıran unsurlar da bana pek gerekli gelmiyor.
    • Biri ApplicationSet’te kalıplaştırmayı iyi ele alırsa ArgoCD’nin etrafına bir ürün sarılabilir gibi. D2iQ bunu Flux ile zaten yapıyor, ama biz daha denemeden D2iQ’dan çıkmıştık.

  • Heves kırmak istemem ama bu, kelimenin tam anlamıyla kopyala-yapıştır ürüne yakın.
    Jenkins, Google Borg, Cloud Foundry, Concourse Pipelines var; kökenlerine bakınca Ex-Google, Ex-VMW, RabbitMQ olduğu için şaşırtıcı da değil.
    Asıl yazının yazarı bu araçların kaynağına yakın olmasa bile, en azından o hikâyenin kuzeni sayılır.
    Satış döngüsü uzun; entegrasyonlar güvenlik ve ağ dahil birden fazla eksende yönetici onayı gerektiriyor.
    İyi bir şey yapmışlar, ama üst akıştaki sorun o kadar bileşik ki özelleştirilmiş çözüm ile genel amaçlı ürün arasında sürekli gidip gelen bir alanda pek içi dolu olmayan bir hikâye gibi geldi. Denetim eksikliğinden mikro yönetime, deneyimsizlikten “hep böyle yaptık” tarzını bırakamayacak kadar aşırı deneyime kadar her şey birbirine karışmış.
    Popüler olmayan bir görüş olabilir ama bir araç zinciri satarken sorunlar denizini kaynatmaya çalışmış oluyorsunuz. İş ve teknoloji su gibi en az direnç gösteren deliği bulup oradan akar; bu süreçte “ana işin” temelini de aşındırabilir. Deneyimime göre, kılavuz veya “yetiştirme stratejisi” gibi çalışan ve çıkarılabilir korkulukları olan araç zincirleri en büyük getiriyi sağladı.

    • Daha temelde, bu üründe kullanmak bir yana, para ödemek için de yeterli neden yoktu.
      “Hızlı” bir satış argümanı değildir. Geliştiriciler yavaş pipeline istemez, ama bu hızlı pipeline istedikleri anlamına gelmez.
      Pipeline hızı, pipeline servisinin ek yükünden çok pipeline’ı nasıl kurguladığınıza bağlıdır; diğer CI/CD servisleri de zaten çok hızlı. Örneğin CircleCI bile GitHub Actions ve GitLab CI/CD’ye kıyasla satması kolay değilken, bu servis nasıl farklılaşıyordu? GitHub/GitLab/CircleCI vb.’ye kıyasla gerçek bir değer katıyor muydu? Dakikalar süren derlemelerde milisaniyeleri azaltmak çözüm değil.

  • Başarısız olmasının nedeni pazarlamanın bariz biçimde özensiz ve epey dürüstlükten uzak olmasıydı.
    Jenkins, Actions veya Earthly ile derleseniz de aynı build node’u kullanıyorsanız derleme süresi aynı olacaktır. CI birkaç saniye içinde başlıyorken 20 kat hızlı olduğunu iddia etmenin pek anlamı yok.
    Önbellekleme ve paralel yürütme CI’da eski kavramlar; modern build sistemlerinin hepsi bunları yapabiliyor.
    CI’ın özü geri bildirimdir; iş birliği veya veriyi yukarı taşıma tarafı ise pek görünmüyordu. Ayrıntılı bakmadım ama bunun ön planda olması gerekir. Son olarak, derlemeler için bir daha asla DSL devreye almak istemiyorum.

    • GitHub Actions, Jenkins, Docker ve Make ile önbellekleme ve paralelleştirme ayarlamak, tek başına Earthly ile yapmaktan çok daha zor.
    • “Geri bildirim” derken ne kastettiğini biraz daha açıklayabilir misin? CI’da ne tür geri bildirim beklediğini merak ediyorum.

  • Hızlı CI tam olarak ne demek?
    CI, derlemeyi çalıştırıp başarısızlığı bildiren, fazla büyümüş bir shell script’idir. Genelde derleme aracının kendisi o kadar yavaşlar ki CI runner maliyetinin buna kıyasla neredeyse 0 olması gerekir.
    Hızlı CI istiyorsanız tsc, clang, rustc vb. hızlı olmalı; onları exec ile çağıran programın daha hızlı olması değil.
    Konuya daha uygun söylemek gerekirse, CI satıyorsanız ve iş başarısız olduysa bunun nedeni değer sunamamış olmanızdır. İnsanlar siz olmadan da build script’lerini gayet iyi çalıştırabilir.

    • Yazıya hızlıca göz gezdirince, burada kastedilen şey build çıktılarının cache’lenmesi gibi işleri otomatik hallederek her commit’te tüm depoyu yeniden derlemek zorunda bırakmayan CI gibi görünüyor.
      exec çağıran programın daha hızlı olmasından değil, en başta exec çağırmaya gerek olmadığını bilen bir programdan bahsediliyor.
    • “CI, derlemeyi çalıştırıp başarısızlığı bildiren aşırı büyümüş bir shell script’idir” demek için keşke gerçekten o kadar basit olsaydı.
      Neyi ölçtüğünüzü bilmiyorum ama bir örnek vermek gerekirse Jenkins’in varsayılan açılış sayfası hız açısından felaket. Kümenin tamamındaki son build verilerini şurada burada göstermeye çalışıyor ve çok da büyük olmayan kümelerde bile her build’i çalıştıran ayrı düğümlerden yüzlerce, hatta binlerce öğe çekmesi gerekebiliyor.
      Varsayılan davranışı engelleyen özel bir ayar olmadan yalnızca açılış sayfasını yükleyerek sayısız kez Jenkins’i öldürdüm.
      CI sunucularının genelde kendi veritabanı olur ve işler, çıktılar, kullanıcılar, gizli değerler gibi her tür CI varlığını yönetir. Oldukça büyüyebilir ve uygun indeksleme gibi konulara dikkat etmek gerekir.
      CI’da birden fazla runner bulunur ve bunlar sık sık dinamik olarak provision edilir. VM ya da Docker imajlarının runner node’larına dağıtılması gerektiğini düşünün. Bunu kümeye hızlıca yaymak da kolay iş değildir. Çıktıları da kümenin tamamına dağıtmak istersiniz; bu da zaman ve kaynak yer.
      CI’ın fiilen garbage collection, raporlama ve kendi kendini tanılama için kendi defter tutma mekanizmalarına da ihtiyacı vardır. Yeterince büyük kümelerde gecikmeyi azaltmak için özel çaba göstermezseniz bunların hepsi çok yüksek latency yaratabilir.
      ccache’i duydunuz mu?
      Ama gerçekten, “hızlı tsc/clang/rustc yeter” demek fazla safça. CI denen dağıtık sistemde build’i hızlı yapmak için bu cache’i nasıl dağıtacağınızı, build’i nasıl modülerleştireceğinizi de çözmeniz gerekir. Programlamadaki en zor şeylerden birinin cache invalidation olduğunu duymuşsunuzdur; bu yalnızca kısmen şakadır.
    • Earthly’nin önerileri içinde bana gerçekten hitap eden tek kısım CI’ı yerelde çalıştırabilmekti. CI’ı debug ederken kendi bilgisayarınızda çalıştırabiliyorsanız sorunu çok daha hızlı bulursunuz.
      Oldukça dağınık bir GitHub Actions script’ini oturtmam uzun sürdü, çünkü debug döngüsü 10 dakikaydı.
    • Hem doğru hem değil. Cache kullanmak ve tsc/clang/rustc’nin ne zaman çalıştırılması gerektiğini bilmek de performansı iyileştirir.
    • CI’daki zor kısım, yapılması gerekmeyen işleri tespit etmektir. Zamanı oradan kazanırsınız.

  • Servisi sadece kapatıp tüm şirketi kapatmıyor olmalarına sevindim. Bu aracı gerçekten sevdiğim için işe alım sayfasına sık sık bakacak kadar ilgileniyordum.
    Earthfile söz dizimi, Dockerfile söz diziminin çok makul ve kademeli bir evrimi; yalnızca Dockerfile ile imkânsız ya da çok garip olan birçok işi kolaylaştırıyor.
    Docker’ın BuildKit ve buildx’i getirdiğinde Dockerfile’ı genel amaçlı bir build sistemi, yani yalnızca container değil dosya çıktıları vb. üretmek için de kullanmaya itmeye çalıştığını hatırlıyorum. Earthly bu fikri gerçekten iyi hayata geçirdi.

    • Dagger’ı denemenizi öneririm. Earthly’den daha iyi olduğunu düşünüyorum.
      Memnun şekilde kullanıyorum ama henüz para ödemiyorum.

  • Sadece bu yazıdan ne olduğunu dürüstçe söylemek gerekirse anlamak biraz zordu. Birkaç kez okudum ama terimler hâlâ kafa karıştırıyor. En az iki ayrı sorun varmış gibi görünüyor
    Mevcut CI YAML’ını, yani GitHub/GitLab’dakini, Earthly adlı Makefile/Dockerfile karışımı bir şeye CI yapılandırmasını taşımak sorunu
    Mevcut CI’dan Earthly’nin barındırdığı servise iş yürütücülerini taşımak sorunu
    Birincisinin zor iş olduğunu düşünmüştüm. Çünkü dili değiştirmek aylar, hatta yıllar sürebilir
    Ama blog yazısının ne söylediğini pek anlayamıyorum. O kısmı doğruladıklarını sanıyordum; bu, insanların geçiş yapabildiği anlamına gelmiyor mu?
    Ama sonda doğrulanmadığını söylüyor. Müşteriler bir değil, iki kez mi migrasyon yapmak zorundaydı?
    Peki şimdi ne olacak? Earthly sözdizimini koruyup CI’dan vaz mı geçiyorlar? Taşınması zor olan kısım o sözdizimi değil miydi? Hâlâ kafam karışık

    • Böyle düşünenin sadece ben olmamam iyi oldu. Hem ürün geliştirme hem de geliştirici araçları tarafına ilgi duyuyorum; ama bu biraz kafa karıştırıcı yazıyı okuyunca “adınıza sevindim ya da üzüldüm” gibi bir noktada kaldım
      Esas mesele, çok daha hızlı build’lerin killer feature olduğunu varsayıp bunu geliştirmeden önce o varsayımı doğrulamamaları mı? Yoksa kullanıcıları doğru segmentlere ayıramayıp yüksek ödeme yapan müşterilerin ihtiyaçlarının farklı olduğunu fark etmemeleri mi? Ya da ücretli müşterilerin gerçek sorununu çözen şeyi ücretsiz olarak sunmaları mı?
      Bir de bu biraz kafa karıştırıcı yazıyı CEO’nun yazdığı düşünülünce, kafa karışıklığının sadece edit eksikliğinden mi kaynaklandığını, yoksa süreç boyunca şirket içinde de gerçekten çok fazla kafa karışıklığı mı olduğunu merak ediyorum
      Uzun zaman önce Steve Blank, “Founders and dysfunctional families” [1] adlı yazısında birçok kurucunun kaos içinde büyüdüğü için kaosu yönetmekte iyi olduğunu yazmıştı; bu kesinlikle benim için de geçerli. Başarı ile başarısızlık arasındaki farkın, kurucunun kaos olmayan durumu da yönetip yönetememesine bağlı olabileceğini eklemişti
      Bunu yapamayan kurucular, iyi oldukları kaos seviyesine geri dönmek için kendi şirketlerine “örgütsel el bombaları” atma eğilimindedir. Bu gözlem sonraki yıllarda beni birçok kez durup düşünmeye itti
      [1] https://steveblank.com/2009/05/18/founders-and-dysfunctional...
    • Bu bir sözdizimi migrasyonu sorunu değil
      İnsanların CI’ı zaman içinde, şirketin her bir yazılımı nasıl derleyip dağıttığını kapsayan karma bir modele dönüşür. CI’ı Airflow gibi keyfi otomasyon işleri çalıştıran bir yürütücü olarak kötüye kullanma durumunu düşünün
      Migrasyon, insanların eskiden bildiklerini önce tersine mühendislikle çıkarmakla başlar; ancak ondan sonra bunların hepsini söküp farklı bir şekilde ifade edebilirsiniz
      Kimse dünyayı durdurup bunu düzenlemek istemez

  • Bu yazı, yazar soruna fazla yakın olduğu için kafa karıştırıcı; ayrıntılara girmeden önce dışarıdan birinin bakış açısıyla açıklanması gerekiyor. Yine de gerekli bilgiler var gibi
    Sonuç olarak, dile özgü build sistemi ile onu çalıştıran sürekli build sistemi arasında bir kapsülleme katmanı oluşturmuşlar gibi görünüyor
    Karşılaştırma için Bazel gibi bir şey var; Bazel her şeyi yapar ama onu tamamen benimsemek için dile özgü build sistemini Bazel’in build diliyle değiştirmeye kendinizi adamanız gerekir ve çalıştırmak için çoğu zaman kaynak dosyalarının yerini de taşımanız gerekir
    Bu, dilin kendi build sistemini kullanma biçimine kıyasla yabancı gelebilir; ancak kendi build sistemi olmayan C programcıları için doğal gelebilir. Java da birkaç talihsiz build sisteminden geçtikten sonra ne yazık ki Gradle’da karar kıldı
    Dile özgü build sistemleri, her dilin konvansiyonları ve ekosistemi farklı olduğu için sonunda her şeyi yapmaz. Modern olanlar iyi oldukları alanı bilir ve orada kalır
    Bu yüzden birden fazla dili ve çıktıyı gerçekten anlayan araçlar çoğu zaman shell script’leri, makefile’lar, Dockerfile’lar ve sürekli build’in kendisidir. Hatta bazen elle yapılır. İyileştirmeye çalıştıkları katman tam olarak bu
    Ancak yöntemlerinin neden daha iyi olduğuna dair temel içgörü hâlâ net biçimde yakalanmış değil

  • Bir süre önce iş gereği Earthly’ye kısaca bakmıştım. Çünkü GitLab, Azure DevOps, Jenkins ve belki GitHub Actions’a kadar birden fazla CI platformu için entegrasyon yazmam gerekiyordu.
    Sonunda oldukça benzer bir ürün olan Dagger’ı seçtik; çeşitli CI sistemleriyle entegre olan bir başka iyi BuildKit frontend’iydi ve o dönemde pipeline tanımları için kullandığı DSL daha iyi görünüyordu.
    Ama bu karardan derin bir pişmanlık duydum. Çünkü Dagger geliştiricileri o dili fiilen terk edip popüler programlama dilleri için SDK’lar yağdırma yönüne gittiler. Hepsi imperative, hepsi Turing-complete ve bence bu alana pek uygun değiller.
    Bu yüzden şimdi yeniden cehenneme dönmüş durumdayım; tüm bu sistemlerle elle entegrasyon yapıyorum ve bu tür araçları tekrar bir startup’a emanet etmekte tereddüt ediyorum.
    Benim için Earthly benzeri bir şeyin hâlâ en cazip kullanım senaryosu tam olarak bu. “Push et ve ne olduğuna bak” neredeyse tüm CI sistemlerinin standardı ama berbat bir çalışma akışı.
    Büyük bir organizasyonda farklı CI/CD platformları kullanan ekipleri desteklemeniz gerekiyorsa Earthly gibi bir şey epey acıyı azaltabilir. Ama cazibesi bir CI daha eklemekte değil, tam olarak mevcut CI platformlarını desteklemesinde.

    • CI/CD ve provisioning doğası gereği sıranın önemli olduğu işler olduğu için, kişisel olarak CUE uygulamasındansa SDK yaklaşımını tercih ederim.
      Eski CUE uygulamasının temel sorunu, BuildKit’in yönlü çevrimsiz grafik çözücüsüyle CUE’nun yönlü çevrimsiz grafik çözücüsünü uyumlu hale getirmeye çalışmasıydı; ikisi ters yönde çalışıyordu.
      Yaklaşık 3 yıl önce bir CUE uzmanı olarak bu sorunu çözmeye yardımcı olmaya çalıştım. Dagger için SDK’nın çok daha iyi bir çözüm olduğunu düşünüyorum.
      Beğenseniz de beğenmeseniz de sektörün önemli bir kısmı bu yöne gidiyor. Pulumi de başka bir örnek. Imperative cloud infrastructure konusunda ikna oldum; build’ler de buna bir ölçüde uyuyor gibi görünüyor.
      Ek olarak, yeni bir CUE + Dagger yapısını keşfetmeyi planlıyorum ama eski Dagger engine’inden farklı çalışacak.
    • Dagger CEO’su olarak söyleyeyim: Popüler diller için SDK’lar sunuyoruz ve bu dillerin imperative olduğu doğru. Ama Dagger hâlâ declarative bir sistem, yani ilk sürümde beğendiğiniz kısımlar olduğu gibi duruyor.
      Esas nokta, declarative katmanı statik CUE ayarlarından dinamik GraphQL sorgularına taşımış olmamız. Ayrıca GraphQL şemasından çeşitli diller için client kütüphaneleri ürettik.
      Böylece eskisi gibi yönlü çevrimsiz grafiği declarative biçimde kurabildiğiniz gibi, bunu tercih ettiğiniz herhangi bir dille de yapabiliyorsunuz. Saf GraphQL ile doğrudan DAG çalıştırmanız da mümkün. Tarayıcıdan hemen deneyebileceğiniz https://play.dagger.cloud adresine bakabilirsiniz.
      Yararlı bir benzetme SQL’dir. SQL declarative bir dildir ama genellikle başka dillerle, çoğu zaman imperative dillerle birlikte kullanılır.
      Umarım bu açıklama yardımcı olur ve Dagger’ı bir kez daha değerlendirirsiniz.

  • “2 ila 20 kat daha hızlı build” ifadesi yazı boyunca birkaç kez geçiyor. Neye kıyasla? Bir baseline yoksa bu ifade değersiz bir pazarlama saçmalığıdır.

    • Diğer platformlarda cache olmadan, paralelleştirme olmadan çalışan build’lerle kıyaslanıyor.

  • “Neden stack’i basitleştirmeyelim? CI sağlayıcısına ve bize ayrı ayrı para vermek yerine sadece bize ödeme yapın?” kısmının nedeni, onların “para ödedikleri” CI’ın stack’in geri kalanıyla birlikte gelmesi. GitLab ve GitHub’da basit bir CI ürününden çok daha fazlası var.
    “Yeni gelenler Earthly CI’a şüpheyle baktı; tüm CI’ların aynı olup sadece söz diziminin farklı olduğunu düşündü ve daha fazla incelemedi” kısmını da anlayabiliyorum.
    Biz CI’ın kendisiyle pek ilgilenmiyoruz; sadece gerekli ve düzgün çalışması yeterli.
    Bir uygulama için çalışan bir CI manifest’iniz varsa, yeni uygulamada aynı manifest’i alıp birkaç yerde bul-değiştir yaparak kullanırsınız. İlk oluştururken acı olabilir ama örneklere bakınca GitLab’da aynı şeyi yapmaktan özellikle daha kolay görünmüyor.
    Açıkçası GitLab ya da GitHub CI ayarlarını alıp anında Earthfile’a dönüştüren bir converter eklemiş olsalardı, en azından denememizi sağlayabilirlerdi.