हमने जो सबसे तेज़ CI बनाया, वह असफल रहा
(earthly.dev)- CI/CD टूल बाजार में मौजूदा खिलाड़ियों से सीधे मुकाबला करने के बजाय बिल्ड स्पीड पर फोकस करने वाली Earthly ने Earthly CI बंद कर दिया और फिर से Earthly और Satellites पर ध्यान केंद्रित किया
- मूल विज़न बिल्ड सिस्टम और CI को एक में मिलाकर उसे distributed तरीके से चलाना था, ताकि automatic parallelism, caching और local reproducibility साथ में मिलें
- Earthly और Earthly Satellites को क्रमशः बिल्ड consistency और 2~20 गुना तेज CI pipelines के रूप में validation मिला, लेकिन पूरा CI replacement product पर्याप्त conversion नहीं ला पाया
- नए ग्राहकों को migration cost और scripts दोबारा लिखने का बोझ बड़ा लगा, और मौजूदा Satellites ग्राहक GitHub Actions जैसे अपने existing CI combination से ही Earthly CI के value का 95% पहले से पा रहे थे
- Earthly CI 1 अक्टूबर 2023 को बंद होगा, और Earthly Satellites में निवेश करेगा ताकि users अपने existing CI को बनाए रखते हुए तेज builds पा सकें
Earthly CI का बंद होना और दोबारा फोकस
- Earthly ने Earthly CI को बंद किया और कंपनी को Earthly तथा Earthly Satellites के इर्द-गिर्द फिर से व्यवस्थित किया
- आगे focus करने वाली value दो चीज़ों तक सीमित की गई है
- local builds और reproducibility
- Earthly Satellites, जिसे existing CI के साथ इस्तेमाल किया जा सकता है
- Earthly CI का लक्ष्य तेज CI था, लेकिन बाजार में शुरुआती adoption के पर्याप्त संकेत नहीं बना पाया
“सबसे तेज़ CI” का मूल विज़न
- Earthly ने अप्रैल 2020 में CI/CD tools को बेहतर बनाने के लक्ष्य से शुरुआत की
- शुरुआती बिंदु दो सवाल थे
- अगर CI laptop पर भी चल सके तो वह कैसा दिखेगा
- पृथ्वी पर सबसे तेज CI system कैसा दिखेगा
- Earthly को मिला जवाब यह था कि build system और CI एक ही होने चाहिए, और साथ ही distributed भी होने चाहिए
- लक्ष्य था बदलाव से प्रभावित न हुए build steps को repeat न करना, automatic parallel execution देना, और build के किसी भी हिस्से को laptop पर reliably reproduce करना
छोटी टीम मौजूदा CI vendors से कैसे मुकाबला करे
- शुरुआती startup के लिए polish, feature count, integration coverage में उन incumbents से मुकाबला करना मुश्किल है जिनके पास funding, लोग, reputation और 10 साल से ज्यादा की बढ़त हो
- Earthly की strategy पूरे market को convince करने के बजाय, किसी खास समस्या से बहुत जूझ रही कुछ teams को 10 गुना बेहतर solution देना था
- शुरुआती validation उस स्थिति जैसा होता है जहां product में bugs और limitations होने के बावजूद passionate users का छोटा group बन जाए
- जब MVP को पर्याप्त validation नहीं मिलता, तो सिर्फ features जोड़ते जाना अक्सर startup को ऐसे competition में खींच ले जाता है जहां incumbents को फायदा होता है
Earthly CI तक पहुंचने की 3-स्टेप योजना
- Earthly ने अंतिम लक्ष्य Earthly CI को तुरंत बनाने के बजाय, उसे कई independent products में बांटकर step-by-step validation करने की कोशिश की
-
Step 1: Earthly
- पहला milestone Earthly था
- Earthly ने पहले build syntax और on-demand build execution experience दिया
- core value थी build consistency, यानी execution environment चाहे जो हो, build एक जैसा चले
- शुरुआत में यह local और दूसरे CI में चला, और बाद में हजारों repositories में इस्तेमाल हुआ
- VMware, Adobe, Namely, Roche, ExpressVPN, Bluecore आदि users के रूप में बताए गए
- यह एक solo developer का बिना funding वाला project था और इसमें bugs व constraints भी थे, लेकिन लोगों का इसे सच में इस्तेमाल करना validation signal बना
-
Step 2: Earthly Satellites
- दूसरा milestone Earthly Satellites था
- Satellites remote runners हैं जिन्हें laptop या किसी भी CI से call किया जा सकता है
- caching और parallelism के जरिए CI pipeline को 2~20 गुना तेज बनाना इसकी core value थी
- Earthly open source था, इसलिए commercial service आने से पहले भी users Buildkit-based remote runner खुद operate करके similar effect पा सकते थे
- managed Satellites आने पर users ने remote runners खुद manage न करने के लिए product इस्तेमाल करना शुरू किया
- शुरुआती Satellites में bugs थे, वे inefficient और unstable थे, लेकिन समान स्तर की CI/CD speed देने वाले alternatives कम थे, इसलिए users आने लगे
-
Step 3: Earthly CI
- तीसरा milestone Earthly CI था
- Earthly CI, Earthly और Satellites को मिलाकर बना complete CI platform था, जिसका उद्देश्य GitHub Actions, CircleCI, Jenkins जैसे CI से compete करना था
- Earthly build consistency को target करता था और Earthly CI build speed को, इसलिए माना गया कि free Earthly, Earthly CI की monetization को cannibalize नहीं करेगा
- लेकिन बाद में consistency बनाम speed वाले value proposition का फर्क समस्या बन गया
launch के बाद सामने आई switching barriers
- Earthly CI ने launch किया, TechCrunch में feature हुआ, और Reddit व HackerNews के लिए blog posts भी तैयार किए गए
- launch के बाद पहले 1~2 हफ्तों में waitlist पर लगभग 50 emails register हुए, जो target से आगे था
- नए customers और existing Earthly users के बीच स्पष्ट अंतर था
- नए customers अक्सर “CI तो बस syntax अलग होने के अलावा सब similar हैं” मानते थे और Earthly CI के differentiation को गहराई से नहीं देखते थे
- बातचीत ज्यादातर existing scripts को फिर से लिखने और adapt करने की migration cost पर चली जाती थी
- existing Earthly users ने पहले ही Earthfile migration पूरा कर लिया था और Earthly के benefits अनुभव कर चुके थे, इसलिए वे organization के अंदर champions बनने के लिए तैयार थे
- नए customers के लिए Earthly के पास यह reputation नहीं थी कि वह promised benefits को बड़े scale पर दे सकता है, और छोटी Zoom call में existing users वाला “10 गुना आसान” experience साबित करना मुश्किल था
मौजूदा customers ने भी Earthly CI पर move क्यों नहीं किया
- existing Earthly Satellites customers में से ज्यादातर CI/CD में पहले से ही Satellites इस्तेमाल कर रहे थे
- Earthly ने माना कि CI provider सिर्फ pipeline trigger संभालता है और actual execution Satellites में होता है, इसलिए Earthly CI की जरूरत validated है
- लेकिन Satellites customers Earthly CI की value का 95% पहले से पा रहे थे
- GitHub Actions + Satellites setup की तुलना में Earthly CI पर्याप्त बेहतर नहीं था, और switch करने की वजह कम थी
- existing Earthly users पहले से Earthfile इस्तेमाल करते थे, इसलिए switch आसान लगेगा, लेकिन actual requirements ज्यादा थीं
- GitHub plugin ecosystem
- codecov action
- manual triggers
- git tag creation-based triggers
- machine size selection
- stale builds cancel करना
- build secrets सौंपने लायक trust
- Earthly CI MVP सबसे तेज CI था, लेकिन कुछ core requirements पूरी नहीं कर पाया
- कुछ enthusiastic users ने Earthly CI आजमाया, लेकिन budget वाले बड़े organizations में 2~3 लोगों से ज्यादा व्यापक उपयोग नहीं हुआ
- कुछ Earthly CI users बाद में GitHub ecosystem और Satellites की speed साथ में पाने के लिए Satellites users बन गए
demo requests नकारात्मक संकेत क्यों बने
- Earthly ने potential customers के साथ 100 से ज्यादा calls कीं, लेकिन face-to-face conversations से Earthly CI, Satellites या Earthly में से किसी product को इस्तेमाल कराने के लिए convince करना मुश्किल था
- इसके उलट, website, product-led growth, word of mouth और content marketing के जरिए users जब खुद आते थे, तो Earthly adoption रोज होता था और growth भी बड़ी थी
- developer tools, खासकर जिनमें integration work चाहिए, उन्हें traditional direct sales तरीके से validate करना मुश्किल था
- सबसे मजबूत negative qualification criterion था demo मांगने वाले potential customers
- असल में convert होने वाली teams Earthly download करती थीं, docs पढ़ती थीं, खुद Earthfile लिखती थीं और फिर संपर्क करती थीं; उन्हें demo की जरूरत नहीं होती थी
- integration work मांगने वाले developer tools users के schedule के अनुसार adopt होते हैं; उन्हें जबरन बेचना या जल्दी push करना मुश्किल है
“CI” की जगह “build” करने वाला A/B test
- उस समय Earthly website का message था “Earthly makes CI super simple”, और first screen का अधिकतर हिस्सा CI पर जोर देता था
- Gavin Johnson ने website पर “CI” शब्द को “build” से बदलने का A/B test सुझाया
- copy “Earthly makes builds super simple” हो गई
- इस एक शब्द के बदलाव से main CTA “Get Earthly” page conversion दोगुना हो गया
- इस result के बाद Earthly CI को लेकर शक और बढ़ गया
ShiftLeft experience से मिली सीख
- Earthly से पहले शुरू हुआ ShiftLeft अब Qwiet.ai कहलाता है
- शुरुआती vision एक security agent का था जिसे production में install करके source code vulnerabilities का फायदा उठाने वाले attacks से cloud apps को protect करना था
- इस product को कई programming languages support करने वाला code analyzer, runtime-specific agents, और सब कुछ जोड़ने वाला distributed backend चाहिए था; यह छोटी startup द्वारा एक साथ तीन companies जितनी complexity बनाने जैसा था
- एक साल से ज्यादा effort के बाद एक programming language में end-to-end working flow बना, लेकिन market response अच्छा नहीं था
- security product के target customers heavily regulated enterprises थे, और product को CI/CD तथा production दोनों में डालना पड़ता था, इसलिए adoption path बहुत कठिन था
- उस समय माना गया कि और features जोड़ने से adoption की कठिनाई पार हो जाएगी, और डेढ़ साल और बनाया गया, लेकिन market इसे नहीं चाहता था
- देर से एहसास हुआ कि complex product को दो अलग products में बांटा जा सकता था
- security professionals के लिए code introspector
- market के दूसरे code analyzers से 40 गुना तेज independent code analyzer
- सबसे बड़ा regret यह था कि signals होने पर पहले नहीं रुके
Earthly का निर्णय
- Earthly ने situation को इस तरह summarize किया
- लोग faster builds चाहते हैं
- लोग CI switch करना पसंद नहीं करते
- नए CI पर differentiated न होने का ठप्पा है, और website पर “CI” देखते ही users drop off हो जाते हैं
- direct customer contact के जरिए design partner-style engagement high migration cost perception की वजह से काम नहीं करता
- Earthly CI MVP पर्याप्त early adopter group नहीं बना पाया
- जब कहा जाता है कि existing CI बदले बिना Earthly Satellites से faster builds मिल सकते हैं, तो response बेहतर होता है
- core problem Earthly CI में features की कमी नहीं थी
- किसी promising early product के लिए ऐसा group होना चाहिए जो missing features सहकर भी benefits लेना चाहे, लेकिन Earthly CI में उस स्तर का signal पर्याप्त नहीं था
- इसलिए Earthly ने Earthly CI बंद कर, काम कर रहे Earthly और Earthly Satellites पर focus करने का फैसला किया
shutdown schedule और user migration
- Earthly CI 1 अक्टूबर 2023 को बंद होगा
- Earthly CI को beta/experimental stage के रूप में mark किया गया था, लेकिन Earthly users के migration में मदद करेगा
- Earthly किसी भी CI के साथ काम करता है, इसलिए Earthly CI से बाहर migration आसान माना गया
- अगर faster builds जारी रखने हैं तो Earthly Satellites जोड़े जा सकते हैं, और Satellites में free tier भी है
- transition support Earthly Slack community में सीधे दिया जाएगा
Satellites में आगे investment की दिशा
- Earthly Satellites fast और consistent builds के साथ-साथ users को अपना CI बनाए रखने देता है, इसलिए growth signals मिल रहे हैं
- Earthly CI shutdown से मिला समय उन features में invest होगा जिनकी Earthly community मांग करती रही है
- CPU, memory, disk, network I/O usage सहित Satellite metrics
- local builds और Satellites builds दोनों के लिए web UI में Build history
- बदली हुई files build को affect नहीं करतीं तो तुरंत skip करने वाला Auto-skip
docker buildके fast alternative के रूप में Satellites पर Dockerfile builds remote execute करने की capability- self-hosted remote Buildkit का better-supported version, यानी self-hosted Satellites
- एक single build को कई Satellites में distribute करके speed बढ़ाने की capability
- पूरी तरह distributed serverless Satellites, यानी Compute v2
- Earthly Satellites किसी भी CI के साथ काम करने वाले remote build runners हैं और Earthly Cloud के जरिए इस्तेमाल किए जा सकते हैं
- Earthly एक open source build framework है जो एक बार लिखकर कहीं भी चलाने वाली build consistency देता है, और CI failures को local computer पर आसानी से reproduce करने में मदद करता है
1 टिप्पणियां
Hacker News की राय
यह पोस्ट अच्छी तरह दिखाती है कि open source करते समय अपनी पूरी core value क्यों नहीं दे देनी चाहिए। Earthly open source था, इसलिए Earthly Satellite users पहले से ही Earthly CI की value का 95% पा रहे थे।
मुझे open source बहुत पसंद है, लेकिन अगर business model में open source शामिल है, तो differentiator चाहिए। सिर्फ बहुत तेज़ होने से आगे, लोगों के पास credit card निकालने या उससे भी आगे accounting purchase order process शुरू करने की वजह होनी चाहिए।
GitLab CI/CD को paid customers तक सीमित करता है, Travis/CircleCI build time या credits सीमित करते हैं, Azure DevOps शैतानी है, और ArgoCD जटिल है। GitHub Actions ठीक है अगर आपके पास runners चलाने के लिए hardware है, और enterprise में Jenkins का झुंड लोगों को ज़्यादा परिचित लगता है।
एक पूर्व DevOps director के तौर पर मेरा पहला सवाल होता है: “वह कौन-सा feature है जो मुझे इसे self-host करने के बजाय खरीदने पर मजबूर करेगा?” अगर मेरे पास इसे खुद चलाने की technical capability है, और मैं अपने cloud और DevOps pipeline को अपने business के हिसाब से चला सकता हूँ, तो आपको मुझे समझाना होगा कि मैं आपको पैसे क्यों दूँ।
मेरा मतलब यह नहीं कि software के काम करने के लिए ज़रूरी features छिपा दिए जाएँ; बात support या enterprise-grade integrations जैसे business features को paid रखने की है। power users खुद को अधिक support कर लेते हैं, इसलिए उनके लिए कम भुगतान वाला tiered model भी संभव लगता है।
बचे हुए users को paid में convert किया जा सकता है, लेकिन यह काफी बड़ा दांव है। हाल का एक अच्छा उलटा उदाहरण Docker हो सकता है, जहाँ strict open source छोड़कर विवादास्पद license और product changes करने पड़े।
“open core” के बाहर के code को पढ़ न पाना, bug fixes contribute न कर पाना या self-host न कर पाना बहुत frustrate करता है, और open source license व source available license को अलग करने वाली चीज़ें मेरे लिए खास ज़रूरी नहीं हैं।
मैं ठंडा पानी नहीं डालना चाहता, लेकिन यह सचमुच copy-paste product जैसा है।
Jenkins, Google Borg, Cloud Foundry, Concourse Pipelines मौजूद हैं, और background देखें तो Ex-Google, Ex-VMW, RabbitMQ हैं, इसलिए यह हैरानी की बात नहीं।
मूल लेखक भले ही इन tools के source के पास न रहे हों, कम-से-कम उस कहानी के cousin तो हैं ही।
Sales cycle लंबा होता है, और integration के लिए security और networking सहित कई axes पर executive buy-in चाहिए।
उन्होंने अच्छी चीज़ बनाई, लेकिन upstream समस्याएँ इतनी जटिल हैं कि यह उस क्षेत्र की बहुत साधारण कहानी लगी जहाँ लोग custom-built और general-purpose product के बीच लगातार आते-जाते रहते हैं। इसमें oversight की कमी से लेकर micromanagement तक, अपरिपक्वता से लेकर “हमेशा से ऐसा ही करते आए हैं” को न छोड़ पाने वाली over-experience तक सब मिला हुआ है।
शायद unpopular opinion हो, लेकिन toolchain बेचते हुए आप समस्याओं के समुद्र को उबालने जैसा काम कर रहे हैं। Business और technology पानी की तरह सबसे कम resistance वाले छेद की तरफ बहते हैं, और इस प्रक्रिया में “core business” की नींव को भी काट सकते हैं। मेरे अनुभव में, ऐसे toolchains ने सबसे बड़ा payoff दिया है जो guidance या “nurturing strategy” की तरह काम करते हैं और removable guardrails रखते हैं।
“तेज़” होना sales point नहीं है। Developers धीमी pipelines नहीं चाहते, लेकिन इसका मतलब यह नहीं कि वे तेज़ pipelines चाहते हैं।
Pipeline speed, pipeline service के overhead से ज़्यादा इस पर निर्भर करती है कि pipeline को कैसे structure किया गया है, और अन्य CI/CD services भी पहले से बहुत तेज़ हैं। उदाहरण के लिए CircleCI को भी GitHub Actions और GitLab CI/CD की तुलना में बेचना आसान नहीं है; तो यह service कैसे अलग थी? क्या इसने GitHub/GitLab/CircleCI आदि की तुलना में वास्तविक value जोड़ी? कुछ मिनट के build में milliseconds कम करना जवाब नहीं है।
असफलता की वजह यह थी कि marketing साफ तौर पर कमजोर और काफी बेईमान थी।
Jenkins, Actions या Earthly—आप जिससे भी compile करें, अगर वही build node इस्तेमाल हो रहा है तो compile time समान होगा। जब CI कुछ seconds में start हो जाता है, तब 20x तेज़ होने का दावा करना बहुत मायने नहीं रखता।
Caching और parallel execution CI में पुराने concepts हैं, और सभी modern build systems यह कर सकते हैं।
CI का core feedback है, लेकिन collaboration या data को ऊपर surface करने वाला पक्ष खास नहीं दिखा। मैंने detail में नहीं देखा, लेकिन इसे front and center होना चाहिए। अंत में, मैं build के लिए फिर कभी कोई DSL introduce नहीं करना चाहता।
तेज़ CI का आखिर मतलब क्या है?
CI एक बहुत बड़ा हो चुका shell script है, जो build चलाता है और failure की सूचना देता है। आम तौर पर build tool खुद इतना धीमा हो जाता है कि उसके मुकाबले CI runner की लागत लगभग 0 होनी चाहिए
अगर आप तेज़ CI चाहते हैं, तो tsc, clang, rustc वगैरह तेज़ होने चाहिए; उन्हें
execसे call करने वाला program और तेज़ होना ज़रूरी नहीं हैविषय पर थोड़ा और सीधे कहें तो, अगर आप CI बेच रहे हैं और business fail हुआ है, तो वजह यही है कि आप value दे नहीं पाए। लोग आपके बिना भी build scripts ठीक से चला सकते हैं
बात
execcall करने वाले program के तेज़ होने की नहीं है, बल्कि ऐसे program की है जिसे शुरू से ही पता है किexeccall करने की ज़रूरत नहीं हैपता नहीं आपने क्या measure किया, लेकिन एक उदाहरण दूँ तो Jenkins का default landing page speed के लिहाज से disaster है। वह पूरे cluster के recent build data को जगह-जगह दिखाने की कोशिश करता है, और बहुत बड़े न होने वाले cluster में भी हर build चलाने वाले अलग-अलग nodes से सैकड़ों से हजारों items लाने पड़ सकते हैं
default behavior रोकने वाली किसी खास setting के बिना सिर्फ landing page load करके मैंने अनगिनत बार Jenkins को गिराया है
CI server के पास आम तौर पर अपना database होता है और वह jobs, artifacts, users, secrets जैसी तरह-तरह की CI entities manage करता है। यह काफी बड़ा हो सकता है और proper indexing वगैरह का ध्यान रखना पड़ता है
CI में कई executors होते हैं, और ये अक्सर dynamically provision किए जाते हैं। मान लीजिए VM या Docker images को executor nodes पर deploy करना है। इन्हें cluster में तेजी से distribute करना भी आसान काम नहीं है। आप artifacts को भी पूरे cluster में distribute करना चाहेंगे, और इसमें भी time और resources लगते हैं
CI को असल में garbage collection, reporting और self-diagnosis के लिए अपनी bookkeeping भी चाहिए होती है। पर्याप्त बड़े cluster में latency कम करने के लिए खास मेहनत न की जाए तो ये सब मिलकर बहुत ज्यादा latency पैदा कर सकते हैं
ccache के बारे में सुना है?
लेकिन सच में, “बस तेज़ tsc/clang/rustc चाहिए” कहना बहुत भोला है। CI जैसे distributed system में build को तेज़ बनाने के लिए यह भी हल करना पड़ता है कि cache को कैसे distribute करेंगे और build को कैसे modularize करेंगे। आपने सुना होगा कि programming में सबसे मुश्किल चीज़ों में से एक cache invalidation है; यह बात सिर्फ आधी मज़ाक है
एक काफी messy GitHub Actions script ठीक करने में मुझे बहुत समय लगा, क्योंकि debug cycle 10 मिनट का था
अच्छा है कि वे service बस बंद कर रहे हैं, पूरी company बंद नहीं कर रहे। मुझे यह tool इतना पसंद था कि मैं अक्सर इसकी hiring page देखा करता था
Earthfile syntax, Dockerfile syntax का बहुत ही तार्किक और incremental evolution है, और Dockerfile अकेले जिन कई कामों को असंभव या बहुत awkward बना देता था, उन्हें यह आसान कर देता है
याद है जब Docker ने BuildKit और buildx पेश किए थे, तब वह Dockerfile को general-purpose build system के रूप में आगे बढ़ाना चाहता था—यानी containers के अलावा file artifacts वगैरह बनाने के लिए भी। Earthly ने उस idea को सच में अच्छी तरह implement किया
मैं इसे संतोषजनक तरीके से इस्तेमाल कर रहा हूँ, लेकिन अभी इसके लिए पैसे नहीं दे रहा
सिर्फ इस लेख से ईमानदारी से समझना थोड़ा मुश्किल था कि हुआ क्या था। कई बार पढ़ने के बाद भी terminology अभी भी उलझा रही है। लगता है कम-से-कम दो अलग-अलग समस्याएँ थीं
मौजूदा CI YAML, यानी GitHub/GitLab से Earthly नाम के Makefile/Dockerfile hybrid में CI configuration migrate करने की समस्या
मौजूदा CI से Earthly द्वारा hosted service पर job runners migrate करने की समस्या
मुझे लगा पहला काम मुश्किल है। भाषा बदलने में महीनों या सालों भी लग सकते हैं
लेकिन ब्लॉग पोस्ट क्या कह रही है, यह ठीक से समझ नहीं आया। मुझे लगा था उन्होंने वह हिस्सा validate कर लिया था; क्या इसका मतलब यह नहीं कि लोग switch कर पा रहे थे?
लेकिन अंत में कहते हैं कि validate नहीं हुआ था। क्या customers को एक नहीं, दो migrations करनी पड़ रही थीं?
तो अब आगे क्या होगा? Earthly syntax बनाए रखेंगे लेकिन CI छोड़ देंगे? Migration में मुश्किल हिस्सा वही syntax नहीं था? अभी भी confusion है
मूल बात यह है कि उन्होंने मान लिया था कि बहुत तेज़ builds killer feature होंगे, लेकिन बनाने से पहले उस assumption को validate नहीं किया? या users को ठीक से segment नहीं कर पाए और यह नहीं समझ पाए कि high-paying customers की ज़रूरतें अलग हैं? या paid customers की असली समस्या हल करने वाली चीज़ को बस free में दे दिया?
और यह देखते हुए कि यह थोड़ा confusing लेख CEO ने लिखा है, मन में सवाल उठता है कि confusion सिर्फ editing की कमी है या पूरी प्रक्रिया के दौरान company के अंदर भी सच में काफी confusion था
काफी पहले Steve Blank ने “Founders and dysfunctional families” [1] नाम के लेख में लिखा था कि कई founders chaos में बड़े होते हैं, इसलिए chaos manage करने में अच्छे होते हैं, और यह बात मुझ पर भी निश्चित रूप से लागू होती है। उन्होंने जोड़ा था कि सफलता और असफलता का फर्क इस पर निर्भर कर सकता है कि founder non-chaos state को भी handle कर सकता है या नहीं
जो founder ऐसा नहीं कर पाता, वह अक्सर अपनी company में “organizational hand grenade” फेंकता है ताकि चीज़ें फिर उसी chaos level पर लौट आएँ जिसमें वह अच्छा है। इस observation ने बाद के वर्षों में मुझे कई बार रुककर सोचने पर मजबूर किया
[1] https://steveblank.com/2009/05/18/founders-and-dysfunctional...
लोगों का CI समय के साथ एक ऐसा mixed model बन जाता है जो company द्वारा अपने-अपने software बनाने और deploy करने के तरीकों को encapsulate करता है। इसे ऐसे समझें जैसे CI को Airflow की तरह arbitrary automation job runner के रूप में misuse किया जा रहा हो
Migration की शुरुआत उन चीज़ों को reverse-engineer करने से होती है जिन्हें लोग पहले से जानते थे, और उसके बाद ही उन सभी चीज़ों को खोलकर किसी दूसरे तरीके से express किया जा सकता है
कोई भी दुनिया रोककर इसे व्यवस्थित करना नहीं चाहता
यह लेख इसलिए confusing है क्योंकि author समस्या के बहुत करीब है, और details में जाने से पहले outsider के perspective से समझाने की जरूरत थी। फिर भी लगता है जरूरी जानकारी मौजूद है
नतीजतन, लगता है उन्होंने language-specific build systems और उन्हें चलाने वाले continuous build systems के बीच एक encapsulation layer बनाई
तुलना के लिए Bazel जैसी चीज़ है; Bazel सब कुछ करता है, लेकिन उसे पूरी तरह अपनाने के लिए language-specific build system को Bazel की build language से replace करने में पूरी तरह commit करना पड़ता है, और काम करवाने के लिए अक्सर source files की location भी बदलनी पड़ती है
यह language के अपने build system का इस्तेमाल करने के तरीके की तुलना में अनजान लग सकता है, लेकिन C programmers के लिए स्वाभाविक हो सकता है, क्योंकि C में अपना build system नहीं है। Java भी कई अफसोसनाक build systems से गुजरने के बाद दुर्भाग्य से Gradle पर आकर टिक गया
Language-specific build systems आखिरकार सब कुछ नहीं करते, क्योंकि हर language की conventions और ecosystem अलग होते हैं। आधुनिक systems जानते हैं कि वे किन चीज़ों में अच्छे हैं और वहीं तक सीमित रहते हैं
इसलिए जो tools सच में कई languages और artifacts को समझते हैं, वे अक्सर shell scripts, makefile, Dockerfile, continuous build खुद, या यहाँ तक कि हाथ से किए गए काम होते हैं। वे जिस layer को सुधारना चाहते हैं, वह यही हिस्सा है
हालांकि उनका तरीका आखिर क्यों बेहतर है, इस पर मूलभूत insight अभी साफ़ पकड़ में नहीं आती
पहले काम के सिलसिले में Earthly को थोड़ा देखा था। वजह यह थी कि GitLab, Azure DevOps, Jenkins और शायद GitHub Actions तक, कई CI प्लेटफ़ॉर्म के लिए integration लिखने पड़ रहे थे
आखिर में हमने बहुत मिलते-जुलते product Dagger को चुना, क्योंकि वह कई CI systems से integrate होने वाला एक और अच्छा BuildKit frontend था, और उस समय pipeline definitions के लिए इस्तेमाल हो रहा DSL बेहतर लग रहा था
लेकिन बाद में इस फैसले पर गहरा पछतावा हुआ। Dagger के developers ने उस language को लगभग छोड़कर popular programming languages के SDK धड़ाधड़ निकालने की दिशा पकड़ ली। वे सभी imperative हैं, सभी Turing-complete हैं, और मेरी राय में इस domain के लिए ठीक fit नहीं हैं
इसलिए अब मैं फिर उसी नरक में लौट आया हूँ और इन सभी systems के साथ हाथ से integration कर रहा हूँ, और ऐसे tools को फिर किसी startup के भरोसे छोड़ने में हिचकिचाहट होती है
मेरे लिए Earthly जैसी चीज़ का सबसे आकर्षक use case अब भी यही है। “push करो और देखो क्या होता है” लगभग सभी CI systems का standard है, और यह भयानक workflow है
अगर किसी बड़े organization में अलग-अलग CI/CD platforms इस्तेमाल करने वाली teams को support करना हो, तो Earthly जैसी चीज़ काफी दर्द कम कर सकती है। लेकिन आकर्षण एक और CI जोड़ने में नहीं, बल्कि ठीक-ठीक मौजूदा CI platforms को support करने में है
पुराने CUE implementation की मुख्य समस्या यह थी कि BuildKit के directed acyclic graph solver और CUE के directed acyclic graph solver को मिलाने की कोशिश की गई, जबकि दोनों उलटी दिशाओं में काम करते थे
करीब 3 साल पहले CUE expert के तौर पर मैंने इस समस्या को सुलझाने में मदद करने की कोशिश की थी। मुझे लगता है Dagger के लिए SDK कहीं बेहतर solution है
पसंद हो या न हो, industry का बड़ा हिस्सा इसी दिशा में बढ़ रहा है। Pulumi भी एक और उदाहरण है। imperative cloud infrastructure को लेकर मैं convinced हूँ, और builds भी कुछ हद तक इसमें fit होते लगते हैं
अतिरिक्त रूप से, मैं नया CUE + Dagger setup explore करने वाला हूँ, लेकिन यह पुराने Dagger engine से अलग तरह से काम करेगा
मुख्य बात यह है कि हमने declarative layer को static CUE config से dynamic GraphQL query में shift किया है। और GraphQL schema से कई languages की client libraries generate की हैं
इसलिए पहले की तरह directed acyclic graph को declaratively compose किया जा सकता है, और अपनी पसंद की किसी भी language में किया जा सकता है। pure GraphQL से सीधे DAG भी execute कर सकते हैं। इसे browser में सीधे आज़माने के लिए https://play.dagger.cloud देखें
एक उपयोगी analogy SQL है। SQL declarative language है, लेकिन आम तौर पर दूसरी languages, अक्सर imperative languages, के साथ इस्तेमाल होती है
उम्मीद है यह explanation मददगार होगा और आप Dagger पर एक बार फिर विचार करेंगे
“2~20 गुना तेज़ builds” वाला वाक्य पूरे लेख में कई बार आता है। किससे तुलना की गई है? baseline न हो तो यह line बेकार marketing nonsense है
“stack को simplify क्यों न करें? CI vendor और हमें दोनों को पैसे देने के बजाय सिर्फ हमें क्यों न दें?” वाला हिस्सा इसलिए है, क्योंकि वे जिस CI के लिए “pay” कर रहे हैं, वह बाकी stack के साथ bundled आता है। GitLab और GitHub में सिर्फ CI product से कहीं ज्यादा चीज़ें हैं
“नए लोग Earthly CI को लेकर skeptical थे, उन्होंने सोचा कि सभी CI एक जैसे हैं, बस syntax अलग है, और फिर आगे नहीं देखा” वाला हिस्सा भी समझ आता है
हमारी CI में खुद ज्यादा दिलचस्पी नहीं है; बस जरूरत है कि वह ठीक से काम करे
अगर किसी app के लिए working CI manifest है, तो नए app में वही manifest लेकर बस कुछ जगह find-and-replace कर देते हैं। पहली बार बनाते समय दर्द हो सकता है, लेकिन examples देखने पर भी यह GitLab में वही काम करने से खास आसान नहीं लगता
सच कहूँ तो अगर उन्होंने GitLab या GitHub CI config लेकर तुरंत Earthfile बनाने वाला converter जोड़ दिया होता, तो कम से कम लोग उसे try तो कर लेते