osFoundry / Platform
बिल्ड pipeline और CI
हर पुश install → lint → build → deploy ट्रिगर करता है। लॉग्स स्ट्रीम होते हैं, आर्टिफ़ैक्ट्स रखे जाते हैं।
यह क्या है
Build pipeline और CI, osFoundry के Apps & Backend के पीछे की continuous-integration परत है। जब आप किसी app का कोड push करते हैं, तो osFoundry एक तय और अनुमानित क्रम चलाता है: dependencies install करना, lint, build, और फिर deploy। कोई अलग CI service जोड़ने की ज़रूरत नहीं, कोई YAML हाथ से लिखने की ज़रूरत नहीं, और कोई runner तैयार करने की ज़रूरत नहीं। यह pipeline workspace का हिस्सा है, इसलिए किसी app को ship करना उसमें अपना काम save करने जैसा ही एक कदम है।
osFoundry के भीतर यही pipeline एक code push को चालू app में बदलता है। हर stage क्रम से चलती है और पहली विफलता पर रुक जाती है, इसलिए कोई lint error या टूटा हुआ build कभी deploy तक नहीं पहुँचता। हर stage के logs आपके पास तब आते हैं जब run चल रहा होता है, यानी आप install का output, lint की warnings और build errors रियल-टाइम में देखते हैं, न कि किसी लाल निशान का इंतज़ार करके बाद में dump खंगालते हैं। जब build सफल होता है, तो बने artefacts सुरक्षित रखे जाते हैं, इसलिए हर deploy की गई version एक टिकाऊ रिकॉर्ड छोड़ती है जिसे आप बाद में देख सकते हैं, न कि एक ऐसा build जो पूरा होते ही गायब हो जाए।
यह इसलिए मायने रखता है क्योंकि ship करने में देरी अक्सर विफल deploy और उसकी वजह समझने के बीच के चक्र में होती है। लाइव logs इस चक्र को छोटा कर देते हैं: आप ठीक वही stage और line देख लेते हैं जहाँ run टूटा, उसी workspace से जहाँ आप chat, agents, code और data लिखते हैं। चूँकि osFoundry bring-your-own-key और local-first है, यह pipeline ऐसे workflow में फिट बैठता है जहाँ आप अपनी keys और अपने data का नियंत्रण अपने पास रखते हैं, बजाय अपनी build प्रक्रिया किसी तीसरे-पक्ष CI vendor को सौंपने के, जिसकी अपनी per-seat कीमत होती है और आपके logs रखने की अपनी जगह।
मुख्य क्षमताएँ
- हर push वही चार stages क्रम से चलाता है: install, lint, build, deploy
- Pipeline पहली विफल stage पर रुक जाता है, इसलिए टूटा हुआ build कभी deploy नहीं होता
- हर stage के logs run चलने के दौरान लाइव आते हैं, उसके खत्म होने के बाद नहीं
- Build artefacts हर version के लिए सुरक्षित रखे जाते हैं, जो आपने ship किया उसका टिकाऊ रिकॉर्ड बनता है
- कोई अलग CI service, runner या हाथ से लिखा YAML सेट करने की ज़रूरत नहीं; यह workspace का हिस्सा है
उपयोग के मामले
- अकेला builder: कोई app push करें और install, lint व build को लाइव देखें, deploy से पहले ही विफल lint stage पकड़ लें
- आंतरिक apps ship करती छोटी टीम: तय install-lint-build-deploy क्रम पर भरोसा करें ताकि कोई बिना-समीक्षा या टूटा build उपयोगकर्ताओं तक न पहुँचे
- deploy debug करता developer: किसी पुराने run के सुरक्षित artefacts और लाइव logs को स्क्रॉल करें और वह ठीक stage खोजें जहाँ कोई version टूटा
सामान्य प्रश्न
जब मैं किसी osFoundry app में code push करता हूँ तो क्या चलता है?
एक तय pipeline: dependencies install, lint, build, और फिर deploy। Stages क्रम से चलती हैं और pipeline पहली विफल stage पर रुक जाता है, इसलिए विफल lint या build कभी deploy stage तक नहीं पहुँचता।
क्या run के दौरान मैं build logs देख सकता हूँ?
हाँ। हर stage के logs run चलने के दौरान लाइव आपके पास आते हैं, इसलिए आप install, lint और build का output रियल-टाइम में देखते हैं, बजाय run के पूरा होने का इंतज़ार करके बाद में कोई स्थिर dump पढ़ने के।
क्या deploy होने के बाद पुराने builds रखे जाते हैं?
हाँ। सफल builds के artefacts सुरक्षित रखे जाते हैं, इसलिए हर deploy की गई version एक टिकाऊ रिकॉर्ड छोड़ती है जिस पर आप लौट सकते हैं, न कि एक ऐसा build जो पूरा होते ही गायब हो जाए।