CI tercepat yang kami buat, gagal

• Di pasar alat CI/CD, alih-alih berhadapan langsung dengan pemain lama, Earthly berfokus pada kecepatan build, tetapi akhirnya menghentikan Earthly CI dan kembali memusatkan perhatian pada Earthly dan Satellites
• Visi awalnya adalah menyatukan sistem build dan CI menjadi satu lalu mengeksekusinya secara terdistribusi, sehingga paralelisme otomatis, caching, dan reproduksibilitas lokal dapat tersedia sekaligus
• Earthly dan Earthly Satellites masing-masing terbukti lewat konsistensi build dan pipeline CI 2–20 kali lebih cepat, tetapi produk pengganti CI sepenuhnya tidak berhasil menghasilkan adopsi yang cukup
• Pelanggan baru melihat biaya migrasi dan beban penulisan ulang skrip sebagai hambatan besar, sementara pelanggan Satellites yang sudah ada sebenarnya sudah mendapatkan 95% nilai Earthly CI hanya dengan kombinasi CI lama seperti GitHub Actions
• Earthly CI akan dihentikan pada 1 Oktober 2023, dan Earthly akan berinvestasi pada Satellites agar pengguna bisa mendapatkan build cepat tanpa harus meninggalkan CI yang sudah ada

---

Penghentian Earthly CI dan fokus ulang

• Earthly menghentikan Earthly CI dan menata ulang perusahaan dengan berpusat pada Earthly dan Earthly Satellites
• Ke depan, fokus nilainya dipersempit menjadi dua hal
  • build lokal dan reproduksibilitas
  • Earthly Satellites yang bisa digunakan bersama CI yang sudah ada
• Earthly CI menargetkan CI yang cepat, tetapi gagal menciptakan sinyal adopsi awal yang cukup di pasar

Visi awal “CI tercepat”

• Earthly dimulai pada April 2020 dengan tujuan memperbaiki alat CI/CD
• Titik awalnya adalah dua pertanyaan
  • seperti apa jadinya jika CI bisa dijalankan juga di laptop
  • seperti apa sistem CI tercepat di muka bumi
• Jawaban yang ditemukan Earthly adalah bahwa sistem build dan CI harus sama, dan pada saat yang sama harus terdistribusi
• Tujuannya adalah tidak mengulang tahap build yang tidak terpengaruh oleh perubahan, menyediakan eksekusi paralel otomatis, dan memungkinkan bagian mana pun dari build direproduksi secara andal di laptop

Cara tim kecil bersaing dengan vendor CI yang sudah mapan

• Startup tahap awal sulit bersaing dengan pemain lama yang punya dana, SDM, reputasi, dan lebih dari 10 tahun keunggulan waktu dalam hal kematangan, jumlah fitur, dan cakupan integrasi
• Strategi Earthly bukan meyakinkan seluruh pasar, melainkan memberi solusi 10 kali lebih baik kepada sejumlah kecil tim yang sangat menderita karena masalah tertentu
• Validasi awal lebih dekat pada kondisi ketika muncul kelompok kecil pengguna yang tetap antusias memakai produk meskipun masih ada bug dan keterbatasan
• Saat MVP tidak mendapat validasi yang cukup, pendekatan sekadar menambah fitur mudah menyeret startup ke arena persaingan yang justru menguntungkan pemain lama

Rencana 3 tahap menuju Earthly CI

• Earthly tidak langsung membuat Earthly CI sebagai tujuan akhir, melainkan membaginya menjadi beberapa produk independen untuk divalidasi bertahap

• Tahap 1: Earthly

  • Tonggak pertama adalah Earthly
  • Earthly lebih dulu menyediakan sintaks build dan pengalaman menjalankan build on-demand
  • Nilai intinya adalah konsistensi build, yaitu memastikan build berjalan sama apa pun lingkungan eksekusinya
  • Awalnya dijalankan di lokal dan di CI lain, lalu kemudian dipakai di ribuan repositori
  • VMware, Adobe, Namely, Roche, ExpressVPN, dan Bluecore disebut sebagai pengguna
  • Ini adalah proyek bootstrap satu pengembang dengan bug dan keterbatasan, tetapi fakta bahwa orang benar-benar memakainya menjadi sinyal validasi

• Tahap 2: Earthly Satellites

  • Tonggak kedua adalah Earthly Satellites
  • Satellites adalah remote runner yang bisa dipanggil dari laptop atau dari CI mana pun
  • Nilai intinya adalah kecepatan build yang membuat pipeline CI 2–20 kali lebih cepat lewat caching dan paralelisme
  • Karena Earthly bersifat open source, bahkan sebelum layanan komersial tersedia, pengguna bisa menjalankan sendiri remote runner berbasis Buildkit untuk mendapatkan efek serupa
  • Setelah Satellites terkelola hadir, pengguna mulai memakai produk itu agar tidak perlu mengelola remote runner sendiri
  • Satellites awal masih penuh bug, tidak efisien, dan tidak stabil, tetapi pengguna tetap datang karena hanya sedikit alternatif yang bisa memberi kecepatan CI/CD setara

• Tahap 3: Earthly CI

  • Tonggak ketiga adalah Earthly CI
  • Earthly CI adalah platform CI lengkap yang menggabungkan Earthly dan Satellites, sebagai produk yang hendak bersaing dengan CI seperti GitHub Actions, CircleCI, dan Jenkins
  • Karena Earthly menargetkan konsistensi build dan Earthly CI menargetkan kecepatan build, Earthly menilai Earthly gratis tidak akan mengkanibal monetisasi Earthly CI
  • Namun belakangan, perbedaan proposisi nilai konsistensi vs kecepatan justru menjadi masalah

Hambatan konversi yang terlihat setelah peluncuran

• Earthly CI diluncurkan, diperkenalkan di TechCrunch, dan Earthly juga menyiapkan tulisan blog untuk Reddit dan HackerNews
• Pada 1–2 minggu pertama setelah peluncuran, sekitar 50 email masuk ke daftar tunggu, melampaui target
• Ada perbedaan jelas antara pelanggan baru dan pengguna Earthly yang sudah ada
  • Pelanggan baru sering memandang bahwa “semua CI pada dasarnya mirip, hanya sintaksnya yang berbeda,” sehingga tidak terlalu mendalami diferensiasi Earthly CI
  • Percakapan kebanyakan berujung pada biaya migrasi berupa kebutuhan menulis ulang skrip yang ada dan beradaptasi
  • Pengguna Earthly yang sudah ada telah menyelesaikan migrasi ke Earthfile dan merasakan manfaat Earthly, sehingga lebih siap menjadi pendukung di dalam organisasi
• Untuk pelanggan baru, Earthly belum punya reputasi yang cukup kuat bahwa manfaat yang dijanjikannya bisa diwujudkan dalam skala besar, dan sulit membuktikan pengalaman pengguna lama yang “10 kali lebih mudah” hanya lewat panggilan Zoom singkat

Mengapa pelanggan lama pun tidak pindah ke Earthly CI

• Pelanggan Earthly Satellites yang sudah ada kebanyakan memang sudah menggunakan Satellites di CI/CD mereka
• Earthly mengira kebutuhan akan Earthly CI sudah tervalidasi karena vendor CI hanya menangani trigger pipeline sementara eksekusi sebenarnya terjadi di Satellites
• Tetapi pelanggan Satellites sebenarnya sudah mendapatkan 95% nilai Earthly CI
• Dibanding konfigurasi GitHub Actions + Satellites, Earthly CI tidak cukup lebih baik sehingga alasan untuk berpindah pun lemah
• Pengguna Earthly yang sudah ada tampak seolah mudah berpindah karena mereka sudah memakai Earthfile, tetapi kebutuhan nyatanya lebih banyak
  • ekosistem plugin GitHub
  • action codecov
  • trigger manual
  • trigger berbasis pembuatan git tag
  • pemilihan ukuran mesin
  • pembatalan build lama
  • kepercayaan untuk menitipkan build secret
• MVP Earthly CI memang CI tercepat, tetapi tidak memenuhi beberapa kebutuhan inti
• Beberapa pengguna antusias sempat mencoba Earthly CI, tetapi pemakaiannya tidak meluas lebih dari 2–3 orang dalam organisasi yang lebih besar dan punya anggaran
• Sebagian pengguna Earthly CI kemudian beralih menjadi pengguna Satellites agar tetap mendapatkan ekosistem GitHub sekaligus kecepatan Satellites

Mengapa permintaan demo justru menjadi sinyal negatif

• Earthly melakukan lebih dari 100 panggilan dengan calon pelanggan, tetapi lewat percakapan tatap muka, sulit meyakinkan mereka untuk memakai Earthly CI, Satellites, maupun Earthly
• Sebaliknya, saat pengguna datang sendiri melalui situs web, product-led growth, rekomendasi dari mulut ke mulut, dan content marketing, adopsi Earthly terjadi setiap hari dan trennya juga besar
• Developer tools, terutama yang membutuhkan pekerjaan integrasi, sulit divalidasi melalui model direct sales tradisional
• Kriteria negatif terkuat justru adalah calon pelanggan yang meminta demo
• Tim yang benar-benar berkonversi biasanya datang setelah mengunduh Earthly, membaca dokumentasi, dan menulis Earthfile sendiri, tanpa memerlukan demo
• Developer tools yang membutuhkan integrasi diadopsi mengikuti jadwal pengguna, dan sulit dijual secara paksa atau dipercepat secara agresif

A/B test yang mengganti “CI” menjadi “build”

• Saat itu, pesan di situs Earthly adalah “Earthly makes CI super simple” dan sebagian besar hero section menekankan CI
• Gavin Johnson mengusulkan A/B test untuk mengganti kata “CI” di situs web menjadi “build”
• Salinannya berubah menjadi “Earthly makes builds super simple”
• Perubahan satu kata ini menggandakan konversi halaman CTA utama “Get Earthly” menjadi dua kali lipat
• Setelah hasil ini, keraguan terhadap Earthly CI sendiri makin besar

Pelajaran dari pengalaman ShiftLeft

• ShiftLeft, yang dimulai sebelum Earthly, kini dikenal sebagai Qwiet.ai
• Visi awalnya adalah agen keamanan yang dipasang di production untuk melindungi aplikasi cloud dari serangan yang memanfaatkan kerentanan pada source code
• Produk ini membutuhkan penganalisis kode untuk banyak bahasa pemrograman, agen untuk tiap runtime, dan backend terdistribusi yang menyatukan semuanya, hampir seperti startup kecil yang mencoba membangun kompleksitas setara tiga perusahaan sekaligus
• Setelah lebih dari setahun, mereka berhasil membuat alur end-to-end yang berfungsi untuk satu bahasa pemrograman, tetapi respons pasar buruk
• Target pelanggan produk keamanan itu adalah enterprise dengan regulasi ketat, dan produk harus dimasukkan ke CI/CD sekaligus production, sehingga jalur adopsinya sangat sulit
• Saat itu mereka mengira kesulitan adopsi bisa diatasi dengan menambah lebih banyak fitur, lalu membangun lagi selama satu setengah tahun, tetapi pasar tetap tidak menginginkannya
• Terlambat disadari bahwa produk kompleks itu bisa dipecah menjadi dua produk berbeda
  • code introspector untuk pakar keamanan
  • penganalisis kode independen yang 40 kali lebih cepat daripada penganalisis kode lain di pasar
• Penyesalan terbesar adalah tidak berhenti lebih cepat ketika sinyalnya sebenarnya sudah ada

Penilaian yang diambil Earthly

• Ringkasan situasi menurut Earthly adalah sebagai berikut
  • orang menginginkan build yang lebih cepat
  • orang tidak suka mengganti CI
  • CI baru membawa stigma tidak terdiferensiasi, dan pengguna keluar begitu melihat kata “CI” di situs web
  • keterlibatan ala design partner melalui kontak langsung dengan pelanggan tidak berhasil karena persepsi biaya migrasi yang tinggi
  • MVP Earthly CI gagal membentuk kelompok adopter awal yang cukup
  • respons menjadi lebih baik ketika Earthly mengatakan bahwa build yang lebih cepat bisa didapat lewat Earthly Satellites tanpa mengganti CI yang ada
• Masalah intinya bukan kekurangan fitur pada Earthly CI
• Jika sebuah produk awal benar-benar menjanjikan, seharusnya ada kelompok yang tetap mau menoleransi kekurangan fitur demi mendapatkan manfaatnya, tetapi sinyal pada level itu tidak cukup terlihat di Earthly CI
• Karena itu, Earthly memutuskan menghentikan Earthly CI dan fokus pada Earthly serta Earthly Satellites yang sudah terbukti berjalan

Jadwal penghentian dan transisi pengguna

• Earthly CI akan dihentikan pada 1 Oktober 2023
• Earthly CI memang sudah ditandai sebagai beta/eksperimental, tetapi Earthly tetap membantu transisi pengguna
• Karena Earthly dapat bekerja bersama CI mana pun, migrasi keluar dari Earthly CI dinilai mudah
• Jika tetap menginginkan build cepat, pengguna bisa menghubungkan Earthly Satellites, yang juga memiliki tier gratis
• Dukungan transisi diberikan langsung melalui komunitas Slack Earthly

Arah investasi berikutnya untuk Satellites

• Earthly Satellites menunjukkan sinyal pertumbuhan bukan hanya karena build yang cepat dan konsisten, tetapi juga karena memungkinkan pengguna tetap mempertahankan CI mereka sendiri
• Waktu yang didapat dari penghentian Earthly CI akan dipakai untuk berinvestasi pada fitur yang selama ini diminta komunitas Earthly
  • Satellite metrics yang mencakup penggunaan CPU, memori, disk, dan network I/O
  • Build history di web UI untuk build lokal maupun build Satellites
  • Auto-skip yang langsung melewati build jika file yang diubah tidak memengaruhi build
  • kemampuan menjalankan build Dockerfile dari jarak jauh di Satellites sebagai alternatif cepat untuk docker build
  • self-hosted Satellites sebagai versi yang lebih didukung dari self-hosted remote Buildkit
  • fitur untuk mendistribusikan satu build ke beberapa Satellites demi meningkatkan kecepatan
  • Compute v2, yaitu Satellites serverless yang sepenuhnya terdistribusi
• Earthly Satellites adalah remote build runner yang bekerja dengan CI mana pun dan dapat digunakan melalui Earthly Cloud
• Earthly adalah framework build open source yang memberikan konsistensi build tulis sekali jalan di mana saja, serta membantu mereproduksi kegagalan CI dengan mudah di komputer lokal

[GN⁺]

Komentar Hacker News

• Tulisan ini menunjukkan dengan baik mengapa saat membuat sesuatu menjadi open source, Anda tidak boleh menyerahkan seluruh nilai intinya. Karena Earthly bersifat open source, pengguna Earthly Satellite sudah menikmati 95% nilai Earthly CI
  Saya sangat menyukai open source, tetapi jika open source menjadi bagian dari model bisnis, diperlukan faktor pembeda. Lebih dari sekadar sangat cepat, harus ada alasan bagi orang untuk mengeluarkan kartu kredit, atau bahkan menjalani proses purchase order akuntansi
  GitLab membatasi CI/CD untuk pelanggan berbayar, Travis/CircleCI membatasi waktu build atau kredit, Azure DevOps terasa seperti setan, dan ArgoCD rumit. GitHub Actions cukup baik jika Anda punya hardware untuk menjalankan runner, dan di enterprise, sekawanan Jenkins cenderung sudah akrab
  Sebagai mantan direktur DevOps, hal pertama yang akan saya tanyakan adalah: “Fitur apa yang membuat saya harus membeli, bukan meng-host sendiri?” Kalau saya punya kemampuan teknis untuk menjalankannya sendiri, dan bisa mengoperasikan cloud serta pipeline DevOps saya sesuai kebutuhan bisnis kami, Anda harus meyakinkan saya mengapa saya harus membayar Anda
  Bukan berarti fitur yang esensial agar software berfungsi harus disembunyikan; maksudnya fitur bisnis seperti dukungan atau integrasi kelas enterprise bisa dijadikan berbayar. Model bertingkat juga tampak mungkin, di mana power user membayar lebih sedikit karena mereka lebih banyak mendukung diri sendiri

  • Saya tidak yakin pembatasan fitur secara tradisional berhasil dengan baik di ranah developer tools. Churn alat sangat tinggi, sehingga jika Earthly sengaja melemahkan produknya, sebagian besar developer mungkin akan pindah ke alternatif gratis meskipun lebih inferior, misalnya taskfile
    Pengguna yang tersisa mungkin bisa dikonversi menjadi berbayar, tetapi itu taruhan yang cukup besar. Contoh pembalikan yang bagus belakangan ini mungkin Docker, tetapi itu membutuhkan proses meninggalkan open source yang ketat dan melakukan perubahan lisensi serta produk yang sangat kontroversial
  • Saat membaca bagian “di enterprise, sekawanan Jenkins sudah akrab,” saya mengira hanya organisasi kami yang terakhir seperti itu, jadi agak melegakan secara aneh bahwa konfigurasi tidak suci ini ternyata cukup standar
  • Runner GitLab CI bisa di-host sendiri dan dapat digunakan juga di versi komunitas gratis
  • Ini mungkin kontroversial, tetapi untuk layanan, saya berharap pendekatan komersial source available menjadi lebih arus utama dan tidak terlalu banyak dicela dibanding “open core”
    Sangat menjengkelkan ketika tidak bisa membaca kode di luar “open core”, berkontribusi perbaikan bug, atau meng-host sendiri, dan faktor-faktor yang membedakan lisensi open source dari lisensi source available tidak terlalu saya perlukan
  • Jika seseorang bisa menangani pembuatan pola applicationset dengan baik, sepertinya ArgoCD bisa dibungkus menjadi sebuah produk. D2iQ sudah melakukannya dengan Flux, tetapi kami keluar dari D2iQ bahkan sebelum sempat mencobanya

• Saya tidak ingin menyiram air dingin, tetapi ini secara harfiah nyaris seperti produk copy-paste
  Ada Jenkins, Google Borg, Cloud Foundry, Concourse Pipelines, dan melihat latar belakangnya—ex-Google, ex-VMW, RabbitMQ—itu tidak mengejutkan
  Bahkan jika penulis artikel asli tidak berada dekat sumber alat-alat di atas, setidaknya ini seperti sepupu dari cerita tersebut
  Siklus penjualan panjang, dan integrasi membutuhkan persetujuan eksekutif di banyak sumbu, termasuk keamanan dan jaringan
  Mereka memang membuat sesuatu yang bagus, tetapi masalah di upstream terlalu majemuk, sehingga ini terasa seperti cerita tanpa banyak isi di area yang terus bolak-balik antara kustom dan produk umum. Ada campuran mulai dari ketiadaan pengawasan sampai micromanagement, dari ketidakmatangan sampai pengalaman berlebihan yang tidak bisa melepaskan “cara yang selalu dipakai”
  Mungkin ini opini tidak populer, tetapi menjual toolchain berarti mencoba merebus lautan masalah. Bisnis dan teknologi mengalir seperti air, mencari celah dengan resistansi paling kecil, dan dalam prosesnya kadang mengikis fondasi “bisnis inti”. Dari pengalaman saya, toolchain yang bekerja seperti pedoman atau “strategi pengasuhan”, dengan guardrail yang bisa dilepas, memberikan imbal hasil terbesar

  • Lebih mendasarnya, produk ini tidak punya alasan yang cukup untuk digunakan, apalagi alasan untuk dibayar
    “Cepat” bukan selling point. Developer tidak menginginkan pipeline yang lambat, tetapi itu tidak berarti mereka menginginkan pipeline yang cepat
    Kecepatan pipeline jauh lebih ditentukan oleh bagaimana pipeline disusun daripada overhead layanan pipeline, dan layanan CI/CD lain juga sudah sangat cepat. Misalnya, CircleCI pun tidak mudah dijual dibanding GitHub Actions dan GitLab CI/CD; lalu bagaimana layanan ini terdiferensiasi? Apakah ia menambah nilai nyata dibanding GitHub/GitLab/CircleCI dan sejenisnya? Mengurangi milidetik dari build berdurasi beberapa menit bukanlah jawabannya

• Alasan kegagalannya adalah marketing-nya terang-terangan ceroboh dan cukup tidak jujur
  Jika menggunakan node build yang sama, baik Anda mengompilasi dengan Jenkins, Actions, maupun Earthly, waktu kompilasi akan sama. Mengklaim 20x lebih cepat ketika CI sudah mulai dalam beberapa detik tidak terlalu bermakna
  Caching dan eksekusi paralel adalah konsep lama di CI, dan semua sistem build modern bisa melakukannya
  Inti CI adalah feedback, tetapi saya tidak banyak melihat sisi kolaborasi atau mengangkat data ke level lebih tinggi. Saya belum melihatnya secara mendetail, tetapi ini seharusnya berada di depan. Terakhir, saya tidak ingin memperkenalkan DSL lagi untuk build

  • Mengatur caching dan paralelisasi dengan GitHub Actions, Jenkins, Docker, dan Make jauh lebih sulit daripada melakukannya hanya dengan Earthly
  • Bisakah Anda menjelaskan lebih lanjut apa maksud “feedback”? Saya penasaran jenis feedback seperti apa yang Anda harapkan dari CI

• Apa sebenarnya arti CI yang cepat?
  CI adalah skrip shell yang sudah terlalu membesar, yang menjalankan build dan memberi tahu jika gagal. Umumnya alat build itu sendiri yang menjadi terlalu lambat, sehingga biaya runner CI semestinya nyaris nol dibandingkan itu
  Kalau menginginkan CI yang cepat, tsc, clang, rustc, dan sejenisnya harus cepat; bukan program yang memanggil semuanya dengan exec yang harus menjadi lebih cepat
  Kalau lebih sesuai topik, jika Anda menjual CI dan bisnisnya gagal, itu karena tidak berhasil memberikan nilai. Orang-orang bisa menjalankan skrip build dengan baik tanpa Anda

  • Setelah membaca cepat tulisannya, sepertinya yang dimaksud di sini adalah CI yang menangani hal-hal seperti caching artefak build secara otomatis, sehingga tidak perlu mengompilasi ulang seluruh repositori untuk setiap commit
    Ini bukan soal program yang memanggil exec lebih cepat, melainkan soal program yang tahu bahwa sejak awal tidak perlu memanggil exec
  • Saya berharap sesederhana “CI adalah skrip shell yang terlalu membesar yang menjalankan build dan memberi tahu jika gagal”
    Entah apa yang diukur, tetapi sebagai contoh, halaman landing default Jenkins adalah bencana dari sisi kecepatan. Ia mencoba menampilkan data build terbaru dari seluruh cluster di berbagai tempat, dan bahkan pada cluster yang tidak terlalu besar, mungkin harus mengambil ratusan hingga ribuan item dari masing-masing node yang menjalankan build
    Saya sudah tak terhitung berapa kali membuat Jenkins mati hanya dengan memuat halaman landing tanpa konfigurasi khusus yang mencegah perilaku default itu
    Server CI biasanya memiliki database sendiri dan mengelola berbagai entitas CI seperti job, artefak, pengguna, dan secret. Ini bisa menjadi cukup besar dan perlu memperhatikan indexing yang tepat, dan sebagainya
    CI memiliki banyak runner, dan runner ini sering diprovisikan secara dinamis. Bayangkan harus mendistribusikan image VM atau Docker ke node runner. Menyebarkannya dengan cepat ke seluruh cluster juga bukan hal mudah. Artefak juga kemungkinan ingin Anda distribusikan ke seluruh cluster, dan itu pun memakan waktu serta sumber daya
    CI pada praktiknya juga membutuhkan pembukuan sendiri untuk garbage collection, pelaporan, dan diagnosis mandiri. Pada cluster yang cukup besar, semua ini bisa menghasilkan latensi yang sangat tinggi jika tidak ada upaya khusus untuk mengurangi latensi
    Pernah dengar ccache?
    Tapi sungguh, mengatakan “cukup punya tsc/clang/rustc yang cepat” itu terlalu naif. Untuk membuat build cepat dalam sistem terdistribusi bernama CI, Anda juga harus memecahkan cara mendistribusikan cache ini dan cara memodularisasi build. Anda mungkin pernah mendengar bahwa salah satu hal tersulit dalam pemrograman adalah invalidasi cache, dan itu hanya sebagian bercanda
  • Satu-satunya bagian dari tawaran Earthly yang terasa mengena bagi saya adalah kemampuan menjalankan CI secara lokal. Saat men-debug CI, jika bisa menjalankannya di komputer sendiri, masalah bisa ditemukan jauh lebih cepat
    Saya menghabiskan waktu lama menyesuaikan skrip GitHub Actions yang cukup berantakan, karena siklus debug-nya 10 menit
  • Benar sekaligus tidak. Melakukan caching dan mengetahui kapan harus menjalankan tsc/clang/rustc juga meningkatkan performa
  • Bagian sulit dalam CI adalah menemukan pekerjaan yang tidak perlu dilakukan. Di situlah waktu bisa dihemat

• Syukurlah mereka hanya menghentikan layanannya dan tidak menutup seluruh perusahaan. Saya sangat menyukai alat ini sampai-sampai sering melihat halaman lowongan mereka
  Sintaks Earthfile adalah evolusi yang sangat masuk akal dan bertahap dari sintaks Dockerfile, dan memudahkan banyak hal yang mustahil atau sangat canggung jika hanya memakai Dockerfile
  Saya ingat ketika Docker memperkenalkan BuildKit dan buildx, mereka mencoba mendorong Dockerfile sebagai sistem build serbaguna, yaitu untuk membuat artefak file dan sebagainya, bukan hanya container. Earthly benar-benar mengimplementasikan ide itu dengan baik

  • Coba gunakan Dagger. Menurut saya lebih baik daripada Earthly
    Saya memakainya dengan puas, tetapi belum membayar untuk itu

• Sejujurnya, dari tulisan ini saja agak sulit memahami apa yang sebenarnya terjadi. Saya sudah membacanya beberapa kali, tetapi istilah-istilahnya masih membingungkan. Sepertinya setidaknya ada dua masalah terpisah
  Masalah migrasi konfigurasi CI dari CI YAML yang ada, yaitu GitHub/GitLab, ke Earthly, semacam campuran Makefile/Dockerfile
  Masalah migrasi runner pekerjaan dari CI yang ada ke layanan yang di-hosting oleh Earthly
  Saya mengira yang pertama adalah hal yang sulit. Mengganti bahasa bisa memakan waktu berbulan-bulan atau bertahun-tahun
  Namun saya tidak benar-benar paham apa yang dikatakan posting blog itu. Bukankah bagian itu dianggap sudah divalidasi, artinya orang bisa beralih?
  Tetapi di akhir disebutkan bahwa itu belum divalidasi. Apakah maksudnya pelanggan harus melakukan dua migrasi, bukan satu?
  Jadi sekarang bagaimana? Apakah sintaks Earthly tetap dipertahankan tetapi CI ditinggalkan? Bukankah bagian yang sulit dimigrasikan itu sintaksnya? Saya masih bingung

  • Syukurlah bukan cuma saya. Saya tertarik pada pengembangan produk maupun alat developer, tetapi setelah membaca tulisan yang agak membingungkan ini, saya jadi berada di posisi kira-kira “senang mendengarnya, atau turut prihatin”
    Apakah intinya mereka berasumsi bahwa build yang jauh lebih cepat adalah killer feature, tetapi tidak memvalidasi asumsi itu sebelum membangunnya? Atau mereka gagal melakukan segmentasi pengguna dengan benar sehingga tidak menyadari bahwa kebutuhan pelanggan bernilai tinggi berbeda? Atau mereka justru memberikan secara gratis sesuatu yang memecahkan masalah nyata pelanggan berbayar?
    Dan melihat tulisan yang cukup membingungkan ini ditulis oleh CEO, saya jadi bertanya-tanya apakah kebingungan itu sekadar kurang penyuntingan, atau memang ada banyak kebingungan nyata di dalam perusahaan sepanjang prosesnya
    Dulu Steve Blank menulis artikel “Founders and dysfunctional families” [1], bahwa banyak founder tumbuh dalam kekacauan sehingga mahir mengelola kekacauan, dan itu jelas berlaku juga bagi saya. Ia menambahkan bahwa perbedaan antara sukses dan gagal bisa bergantung pada apakah founder juga mampu menangani keadaan yang tidak kacau
    Founder yang tidak mampu melakukannya cenderung melempar “granat organisasi” ke perusahaannya sendiri untuk kembali ke tingkat kekacauan yang mereka kuasai. Pengamatan itu membuat saya berkali-kali berhenti dan berpikir selama bertahun-tahun setelahnya
    [1] https://steveblank.com/2009/05/18/founders-and-dysfunctional...
  • Ini bukan masalah migrasi sintaks
    CI orang-orang, seiring waktu, menjadi model campuran yang mengenkapsulasi semua cara perusahaan membangun dan mendistribusikan tiap perangkat lunaknya. Bayangkan situasi ketika CI disalahgunakan sebagai runner pekerjaan otomatisasi arbitrer seperti Airflow
    Migrasi dimulai dengan terlebih dahulu merekayasa balik apa yang dulu diketahui orang, baru setelah itu semua hal tersebut bisa diurai dan diekspresikan dengan cara lain
    Tidak ada yang ingin menghentikan dunia dan merapikannya

• Tulisan ini membingungkan karena penulisnya terlalu dekat dengan masalahnya, dan perlu menjelaskannya dari sudut pandang orang luar sebelum masuk ke detail. Meski begitu, informasi yang diperlukan tampaknya ada
  Pada akhirnya, mereka tampaknya membuat lapisan enkapsulasi antara sistem build per bahasa dan sistem continuous build yang menjalankannya
  Sebagai perbandingan, ada sesuatu seperti Bazel. Bazel melakukan semuanya, tetapi untuk mengadopsinya sepenuhnya, Anda harus berkomitmen mengganti sistem build per bahasa dengan bahasa build milik Bazel, dan sering kali juga memindahkan lokasi file sumber agar bisa berjalan
  Ini bisa terasa asing dibandingkan cara memakai sistem build bawaan bahasa, tetapi bagi programmer C yang bahasanya tidak memiliki sistem build sendiri, ini bisa terasa alami. Java juga, setelah melewati beberapa sistem build yang menyedihkan, sayangnya menetap di Gradle
  Sistem build per bahasa pada akhirnya tidak melakukan semuanya karena tiap bahasa memiliki konvensi dan ekosistem yang berbeda. Sistem modern mengetahui ruang lingkup yang mereka kuasai dan tetap berada di sana
  Karena itu, alat yang benar-benar memahami banyak bahasa dan artefak sering kali adalah skrip shell, makefile, Dockerfile, atau continuous build itu sendiri. Bahkan kadang dilakukan secara manual. Lapisan yang ingin mereka perbaiki adalah bagian ini
  Namun wawasan mendasar tentang mengapa pendekatan mereka lebih baik masih belum tertangkap dengan jelas

• Dulu saya sempat meninjau Earthly sebentar karena pekerjaan. Alasannya, kami harus menulis integrasi untuk berbagai platform CI seperti GitLab, Azure DevOps, Jenkins, dan mungkin juga GitHub Actions
  Pada akhirnya kami memilih Dagger, produk yang sangat mirip, karena itu adalah frontend BuildKit lain yang cukup bagus dan terintegrasi dengan berbagai sistem CI, serta DSL yang saat itu dipakai untuk mendefinisikan pipeline terlihat lebih baik
  Namun saya jadi sangat menyesali keputusan ini. Sebab para pengembang Dagger pada dasarnya meninggalkan bahasa itu dan beralih ke arah merilis banyak SDK untuk bahasa pemrograman populer. Semuanya imperatif, semuanya Turing-complete, dan menurut saya tidak cocok untuk ranah ini
  Jadi sekarang saya kembali ke neraka, mengintegrasikan semua sistem ini secara manual, dan jadi ragu untuk kembali mempercayakan alat semacam ini kepada startup
  Bagi saya, bagian ini tetap menjadi use case paling menarik dari sesuatu seperti Earthly. “Push lalu lihat apa yang terjadi” adalah standar di hampir semua sistem CI, dan itu alur kerja yang buruk sekali
  Jika harus mendukung tim-tim di organisasi besar yang memakai berbagai platform CI/CD, sesuatu seperti Earthly bisa mengurangi cukup banyak penderitaan. Namun daya tariknya bukan pada menambahkan satu CI lagi, melainkan tepat pada dukungan untuk platform CI yang sudah ada

  • CI/CD dan provisioning pada dasarnya adalah pekerjaan yang urutannya penting, jadi secara pribadi saya lebih menyukai pendekatan SDK dibanding implementasi CUE
    Masalah utama implementasi CUE lama adalah upaya mencocokkan solver graf asiklik berarah milik BuildKit dengan solver graf asiklik berarah milik CUE, padahal keduanya bekerja ke arah yang berlawanan
    Sekitar 3 tahun lalu, sebagai ahli CUE, saya mencoba membantu menyelesaikan masalah ini. Menurut saya SDK adalah solusi yang jauh lebih baik untuk Dagger
    Suka atau tidak, sebagian besar industri sedang bergerak ke arah ini. Pulumi adalah contoh lain. Saya sudah diyakinkan oleh infrastruktur cloud imperatif, dan build juga tampaknya cukup cocok di sini sampai batas tertentu
    Sebagai tambahan, kami berencana mengeksplorasi konfigurasi CUE + Dagger yang baru, tetapi itu akan bekerja berbeda dari engine Dagger lama
  • Berbicara sebagai CEO Dagger, benar bahwa kami menyediakan SDK untuk bahasa-bahasa populer dan bahasa-bahasa itu bersifat imperatif. Namun Dagger tetap merupakan sistem deklaratif, jadi bagian yang Anda sukai dari versi awal masih tetap ada
    Intinya, kami memindahkan lapisan deklaratif dari konfigurasi CUE statis ke kueri GraphQL dinamis. Lalu kami menghasilkan library klien untuk berbagai bahasa dari skema GraphQL
    Jadi Anda tetap bisa menyusun graf asiklik berarah secara deklaratif seperti dulu, sekaligus bisa melakukannya dalam bahasa apa pun yang Anda sukai. Anda juga bisa menjalankan DAG langsung dengan GraphQL murni. Lihat https://play.dagger.cloud yang bisa dicoba langsung di browser
    Analogi yang berguna adalah SQL. SQL adalah bahasa deklaratif, tetapi biasanya dipakai bersama bahasa lain, sering kali bahasa imperatif
    Semoga penjelasan ini membantu dan membuat Anda mempertimbangkan Dagger sekali lagi

• Ungkapan “build 2–20 kali lebih cepat” muncul beberapa kali di seluruh tulisan. Dibandingkan dengan apa? Tanpa baseline, frasa ini hanyalah omong kosong marketing yang tidak bernilai

  • Dibandingkan dengan build di platform lain yang berjalan tanpa caching dan tanpa paralelisasi

• Bagian “Mengapa tidak menyederhanakan stack saja? Daripada membayar vendor CI dan kami sekaligus, bukankah lebih baik hanya membayar kami?” terjadi karena CI yang mereka “bayar” sudah disediakan bersama sisa stack. GitLab dan GitHub punya jauh lebih banyak hal daripada sekadar produk CI
  Saya juga paham bagian “orang-orang baru skeptis terhadap Earthly CI, menganggap semua CI sama dan hanya sintaksnya yang berbeda, lalu tidak melihat lebih jauh”
  Kami tidak terlalu peduli pada CI itu sendiri; kami hanya membutuhkannya dan ingin itu berjalan dengan benar
  Jika sebuah aplikasi sudah punya manifes CI yang berfungsi, aplikasi baru cukup memakai manifes yang sama dengan beberapa find-and-replace. Mungkin ada rasa sakit saat pertama membuatnya, tetapi dari contoh-contohnya pun tidak terlihat jauh lebih mudah daripada melakukan hal yang sama di GitLab
  Sejujurnya, jika mereka menyertakan converter yang menerima konfigurasi GitLab atau GitHub CI lalu langsung membuat Earthfile, setidaknya itu mungkin bisa membuat orang mencobanya