अपना कोड जोड़ें: असली कोडबेस में बदलाव करें, जाँचें, मंज़ूर करें, डिप्लॉय करें और वापस लौटाएँ

प्रोजेक्ट का नाम दें, फिर रिपॉज़िटरी का पता (GitHub के हरे Code बटन से) और वह ब्रांच चिपकाएँ जिससे साइट चलती है, आम तौर पर main। चुनें कि aiKit उस तक कैसे पहुँचेगा। GitHub token: GitHub पर इसी एक रिपॉज़िटरी के लिए बनाया गया fine-grained token, जिसमें Contents को Read and write पर सेट किया गया हो; यह https:// पते के साथ जाता है। Deploy key: केवल इस रिपॉज़िटरी के लिए बनाई गई key pair, जिसका public हिस्सा आप रिपॉज़िटरी की Settings, Deploy keys में जोड़ते हैं, और Allow write access चिह्नित हो; यह git@ पते के साथ जाती है। Public repository: केवल पढ़ने के लिए, इसलिए मंज़ूर किए गए बदलाव सहेजे नहीं जा सकते; इसका उपयोग केवल देखने के लिए करें।

token या key आप खुद चिपकाते हैं। यह aiKit के engine पर एन्क्रिप्टेड रूप में सहेजी जाती है और किसी को भी दोबारा नहीं दिखाई जाती। यह पेज केवल एक फ़िंगरप्रिंट दिखाता है। रिपॉज़िटरी जोड़ने पर कोड engine पर कॉपी होता है और पढ़ा जाता है कि प्रोजेक्ट किस प्रकार का है (Laravel, JavaScript, या static files)। रिपॉज़िटरी में कुछ भी नहीं बदलता।

आपके पास पहले से मौजूद प्रोजेक्ट को भी जोड़ा जा सकता है: उसके Hosting टैब पर, मालिक को Connect your code दिखता है।

आपका अपना सर्वर: साइट बिल्कुल वहीं रहती है जहाँ अभी है। सर्वर का पता डालें, SSH port (आम तौर पर 22), वह login जिसका aiKit उपयोग करता है (सेटअप चरण एक बनाता है जिसका नाम aikit है), साइट का फ़ोल्डर (Laravel Forge साइट के लिए /home/forge/your-site.com), वह deploy command जो साइट पहले से उपयोग करती है (आम तौर पर bash scripts/deploy.sh), और वे पेज जिन्हें हर डिप्लॉय के बाद जवाब देना चाहिए, हर पंक्ति में एक पूरा पता। सर्वर login की private key चिपकाएँ (सेटअप चरण 1 में बनी)। सहेजें और कनेक्शन जाँचें।

पहली बार जब aiKit सर्वर तक पहुँचता है, तो वह सर्वर का फ़िंगरप्रिंट दिखाता है और पूछता है Is this your server? इसे सेटअप चरण 6 में सर्वर द्वारा प्रिंट किए गए से मिलाएँ। केवल It matches दबाएँ। Connect तब दबाएँ जब दोनों एक जैसे हों। इसके बाद उस पते पर कोई दूसरा सर्वर अस्वीकार कर दिया जाता है। जाँच पास होने पर पेज बताता है कि सर्वर अभी कौन-सा संस्करण चला रहा है।

aiKit होस्टिंग: aiKit कोड खुद बनाता और परोसता है, शुरुआत के लिए एक मुफ़्त पता के साथ। साइटों और front end के लिए सबसे अच्छा।

Server setup के अंतर्गत पेज आठ कॉपी-और-पेस्ट चरण दिखाता है, जो आपकी वैल्यू के साथ पहले से भरे हैं; हर एक के साथ Copy बटन है। चरण 1 और 8 आपके कंप्यूटर पर चलते हैं, चरण 2 से 7 sudo अधिकार वाले उपयोगकर्ता के रूप में सर्वर पर चलते हैं।

ये क्या बनाते हैं: बिना पासवर्ड और बिना shell वाला एक login (चरण 2)। इसकी एकमात्र key एक छोटी gate script (चरण 3 और 5) से बंधी है, जो ठीक दो कमांड स्वीकार करती है: status (कौन-सा संस्करण चल रहा है, और साइट maintenance mode में है या नहीं) और एक सटीक commit का deploy। Deploy साइट के अपने उपयोगकर्ता के रूप में एक sudo नियम के ज़रिए चलता है, जाँचता है कि GitHub पर ब्रांच उसी सटीक commit की ओर इशारा करती है, फिर आपकी मौजूदा deploy script को बिना बदले चलाता है। चरण 4 फ़ोल्डर अनुमतियाँ सेट करता है ताकि login केवल साइट के फ़ोल्डर तक पहुँचे: उसी home फ़ोल्डर की दूसरी साइटों तक नहीं, और .env तक कभी नहीं। चरण 7 इन सबकी जाँच करता है और बताता है कि हर पंक्ति के लिए आपको क्या दिखना चाहिए, और चरण 8 aiKit में key चिपकाने से पहले आपके कंप्यूटर से login की जाँच करता है।

अगर एक सर्वर पर दूसरे व्यवसाय भी होस्ट हैं, तो यही खासियत है: aiKit login केवल इसी एक साइट को डिप्लॉय कर सकता है, और कुछ नहीं। साइट का कोड अब भी साइट के उपयोगकर्ता के रूप में चलता है, ठीक वैसे ही जैसे जब आप खुद GitHub से डिप्लॉय करते हैं, इसीलिए हर बदलाव की समीक्षा होती है और जोखिम वाली फ़ाइलें सुरक्षित रहती हैं।

सबसे ऊपर चार टाइल। Repository: रिपॉज़िटरी, ब्रांच, सबसे नया commit, और प्रोजेक्ट का प्रकार। Runs on: आपका अपना सर्वर (login और उसने आखिरी बार कब जवाब दिया) या aiKit होस्टिंग। Live release: वह रिलीज़ जो साइट चला रही है, किसने बनाई, और कब। Pages: जाँच के समय जितने जवाब देने वाले पेज जवाब दे पाए; Check now उन्हें फिर से देखता है, और जो पेज जवाब नहीं दे पाया वह नीचे सूचीबद्ध होता है और उसका जवाब भी दिखाया जाता है।

टाइलों के नीचे: Request a change (या अभी खुला बदलाव), Releases, Change log, Protected files, और मालिक के लिए, Connection।

लिखें कि क्या बदलना है, पेज का नाम और आप क्या देखना चाहते हैं, फिर Make the change दबाएँ। कार्ड Change #1 में बदल जाता है, जिसमें लाइव प्रगति दिखती है: नवीनतम कोड लाना, वे फ़ाइलें जिन्हें AI पढ़ता और बदलता है, फिर हर जाँच। AI केवल फ़ाइलें बदलता है; वह कोई कमांड नहीं चलाता। हर प्रोजेक्ट में एक समय पर एक बदलाव खुला रहता है, और हर अनुरोध प्रोजेक्ट की AI सीमा में गिना जाता है।

पूरा होने पर आपको दिखता है: अनुरोध और किसने माँगा; AI के अनुसार उसने क्या किया; जाँचें, हर एक पर टिक या क्रॉस और उसका आउटपुट; जाँचे गए पेजों के लिए Preview बटन; Added, Changed या Removed के साथ फ़ाइलें, और जहाँ लागू हो वहाँ Protected बैज; और अंतर (diff), फ़ाइल-दर-फ़ाइल, जोड़ी गई पंक्तियों के लिए हरा और हटाई गई पंक्तियों के लिए लाल। यही अंतर बिल्कुल वही है जो commit और डिप्लॉय होगा।

मंज़ूरी दें और डिप्लॉय करें (मालिक और बिल्डर) बदलाव को एक ऐसे संदेश के साथ ब्रांच में कमिट करता है जिसमें लिखा होता है कि किसने माँगा और किसने मंज़ूरी दी। फिर उसे पुश करता है (कभी ज़बरदस्ती नहीं: अगर इस बीच किसी और ने पुश कर दिया है, तो बदलाव "पुराना" चिह्नित हो जाता है और कुछ भी डिप्लॉय नहीं होता), उसे डिप्लॉय करता है, और पेजों की जाँच करता है। रद्द करें पुष्टि के बाद बदलाव को हटा देता है; कुछ भी डिप्लॉय नहीं हुआ था। रिव्यूअर सब कुछ पढ़ सकते हैं, पर इनमें से कोई भी बटन नहीं दबा सकते।

जाँच पास होने के बाद क्या करना है, यह सेटिंग कनेक्शन, जाँच और रिव्यू के अंतर्गत है। मंज़ूरी का इंतज़ार डिफ़ॉल्ट है। स्वचालित रूप से डिप्लॉय तभी होता है जब हर जाँच पास हो और कोई सुरक्षित फ़ाइल न बदली गई हो; बाकी सभी स्थितियों में बदलाव इंतज़ार करता है।

Laravel प्रोजेक्ट के लिए जाँचें ये हैं: हर बदली गई PHP फ़ाइल सही तरीके से पढ़ी जाती है (php -l); हर Blade व्यू कंपाइल होता है (php artisan view:cache); फ़्रंट एंड बिल्ड होता है (npm run build); और ऐप एक टेस्ट रन में शुरू होता है, जिसमें एक अस्थायी SQLite डेटाबेस होता है, जो रिपॉज़िटरी से माइग्रेट और सीड किया जाता है, और Pages में दिए गए हर पेज को टेस्ट रन में खोलने पर 200 जवाब आना चाहिए। ये जाँचें aiKit के इंजन पर चलती हैं, कभी आपके सर्वर पर या आपके लाइव डेटाबेस के खिलाफ नहीं। प्रोजेक्ट की .env फ़ाइल कभी कॉपी या पढ़ी नहीं जाती; टेस्ट रन को अस्थायी सेटिंग्स मिलती हैं।

विफल जाँच मंज़ूरी देने से रोक देती है। केवल मालिक ही डिप्लॉय पर टिक कर सकता है, भले ही जाँच विफल हुई हो, उस स्थिति में जब विफलता का कारण लाइव साइट को प्रभावित न करता हो।

पूर्वावलोकन टेस्ट रन से बदले हुए ऐप को नए टैब में खोलता है, जिसमें टेस्ट डेटा और फ़ॉर्म बंद होते हैं। आखिरी उपयोग के 15 मिनट बाद यह बंद हो जाता है, और बदलाव को मंज़ूरी मिलने या रद्द होने पर खत्म हो जाता है।

AI सुरक्षित फ़ाइलों को हाथ नहीं लगाता। सूची की शुरुआत इनसे होती है: वे माइग्रेशन जो लाइव साइट पर पहले ही चल चुके हैं (लाइव रिलीज़ में हर माइग्रेशन, क्योंकि हर डिप्लॉय उन्हें चलाता है), नए माइग्रेशन (वे अगले डिप्लॉय पर लाइव डेटाबेस बदल देंगे), डिप्लॉय स्क्रिप्ट, और डिपेंडेंसी फ़ाइलें (composer.json, composer.lock, package.json, package-lock.json)। हर प्रविष्टि बताती है कि वह क्यों है। मालिक कोई फ़ाइल या फ़ोल्डर जोड़ता है (config/** का मतलब config के अंदर की हर चीज़ है) और कारण लिखता है, प्रविष्टियाँ हटाता है, और सुरक्षित फ़ाइलें सहेजें दबाता है।

किसी सुरक्षित फ़ाइल को जानबूझकर बदलने के लिए, मालिक इस अनुरोध के लिए सुरक्षित फ़ाइलों की अनुमति दें पर टिक करता है। फिर बदलाव दिखाता है कि उसने किन सुरक्षित फ़ाइलों को छुआ है, और केवल मालिक ही इसे मंज़ूरी दे सकता है, हाँ, सुरक्षित फ़ाइलों में बदलाव डिप्लॉय करें पर टिक करने के बाद। जो बिल्डर कुछ भी टिक नहीं करता, उसे सुरक्षित फ़ाइलों तक कोई पहुँच नहीं मिलती।

.env फ़ाइलें, निजी कुंजियाँ और auth.json एक सख्त श्रेणी में हैं: इन्हें कभी पढ़ा नहीं जाता, कभी बदला नहीं जाता, कभी diff का हिस्सा नहीं बनतीं, और इसे कोई बंद नहीं कर सकता।

पहली बार जब aiKit आपके सर्वर तक पहुँचता है, तो वह दर्ज करता है कि सर्वर क्या चला रहा है, और उसे रिलीज़ 1, aiKit से पहले नाम देता है, ताकि aiKit के पहले डिप्लॉय को भी रोलबैक किया जा सके। उसके बाद हर डिप्लॉय एक क्रमांकित रिलीज़ होता है: बदलाव (एक मंज़ूर किया गया बदलाव; उसका नाम उस बदलाव को खोलता है), दोबारा डिप्लॉय, या रोलबैक, साथ में उसका कमिट, किसने किया, उसकी स्थिति (लाइव, पुराना, लाइव पर पेज विफल, डिप्लॉय विफल), कितने पेजों ने जवाब दिया, और डिप्लॉय लॉग। aiKit आखिरी 5 रखता है।

नवीनतम कोड डिप्लॉय करें ब्रांच पर अभी जो भी सबसे नया है उसे पुष्टि के बाद डिप्लॉय करता है, उदाहरण के लिए जब किसी ने सीधे कोई सुधार पुश किया हो।

इस पर वापस जाएँ, किसी पुरानी रिलीज़ पर, एक नया कमिट बनाता है जिसकी फ़ाइलें बिल्कुल उसी रिलीज़ की होती हैं, उसे पुश करता है, सामान्य तरीके से डिप्लॉय करता है, और फिर पेजों की जाँच करता है। इतिहास कभी बदला नहीं जाता, इसलिए रोलबैक को भी रोलबैक किया जा सकता है।

हर अनुरोध अपने नंबर, अनुरोध, किसने माँगा, किसने मंज़ूर या रद्द किया, कब, और अभी उसकी स्थिति के साथ। किसी पंक्ति को दबाने पर उसकी जाँच और diff के साथ वह बदलाव खुलता है; पते में ?change=<id> जुड़ जाता है, ताकि आप लिंक अपनी टीम के साथ साझा कर सकें।