आपका Rust प्रोजेक्ट असली CI/CD का हकदार क्यों है?
\n\nकल्पना करें: आप Rust में लिख रहे हैं, कंपाइलर आपका सबसे अच्छा दोस्त है, borrow checker आपको आराम नहीं करने देता, और कोड बिजली की गति से काम करता है। लेकिन जब डिप्लॉय की बारी आती है, तो जादू खत्म हो जाता है। मैन्युअल टेस्ट चलाना, लोकल मशीन पर बिल्ड करना, SCP के ज़रिए सर्वर पर बाइनरी अपलोड करना – यह कहीं न जाने का रास्ता है। खासकर जब प्रोजेक्ट बड़ा हो जाता है और टीम में दूसरा डेवलपर आ जाता है।
\n\nCI/CD (Continuous Integration / Continuous Deployment) सिर्फ एक फैशनेबल शब्द नहीं है। यह एक सिस्टम है जो रूटीन कामों को अपने हाथ में ले लेता है: टेस्ट चलाना, कोड स्टाइल जांचना, रिलीज़ वर्जन बनाना और उसे वहां भेजना जहां उसे काम करना चाहिए। Rust के लिए, जो विश्वसनीयता और प्रदर्शन पर जोर देता है, बिल्ड ऑटोमेशन भाषा के दर्शन का स्वाभाविक विस्तार है।
\n\nइस लेख में हम GitHub Actions पर Rust एप्लिकेशन के लिए शुरू से CI/CD पाइपलाइन सेटअप करेंगे। आप सीखेंगे कि टेस्टिंग, लिंटिंग, अलग-अलग प्लेटफॉर्म के लिए बाइनरी बिल्ड और डिप्लॉय कैसे व्यवस्थित करें। सब कुछ रियल कोड उदाहरणों के साथ जिन्हें आप अपने प्रोजेक्ट में कॉपी कर सकते हैं।
\n\nहम क्या ऑटोमेट करेंगे?
\n\nकोड लिखने से पहले, आइए अपने लक्ष्य तय करें। हमारी पाइपलाइन चार काम करेगी:
\n\n- \n
- लिंटिंग और फॉर्मेटिंग – ताकि कोड Rust मानकों के अनुरूप हो और सामान्य गलतियों से मुक्त हो। \n
- टेस्टिंग – सभी यूनिट टेस्ट और, यदि हों, तो इंटीग्रेशन टेस्ट चलाना। \n
- बाइनरी बिल्ड – ऑप्टिमाइज़्ड वर्जन (release) का कंपाइलेशन। \n
- डिप्लॉय – बिल्ड आर्टिफैक्ट को सर्वर या GitHub रिलीज़ पर अपलोड करना। \n
यह सब हर बार main ब्रांच पर पुश करने या pull request बनाने पर अपने आप होगा। जादू जैसा लगता है? असल में यह सिर्फ YAML फ़ाइलें और Cargo के कुछ कमांड हैं।
चरण 1: प्रोजेक्ट तैयार करना
\n\nउदाहरण के लिए हम Actix-web पर एक सरल वेब सर्वर लेंगे। लेकिन पाइपलाइन सार्वभौमिक है: यह किसी भी Rust प्रोजेक्ट के लिए उपयुक्त है, चाहे वह CLI यूटिलिटी हो, लाइब्रेरी हो या माइक्रोसर्विस।
\n\nएक नया प्रोजेक्ट बनाएं:
\n\ncargo new rust-ci-cd-demo --bin\ncd rust-ci-cd-demo\n\nCargo.toml में डिपेंडेंसी जोड़ें:
[dependencies]\nactix-web = "4"\nserde = { version = "1", features = ["derive"] }\n\nऔर src/main.rs में सबसे सरल कोड:
use actix_web::{get, App, HttpResponse, HttpServer, Responder};\n\n#[get("/")]\nasync fn hello() -> impl Responder {\n HttpResponse::Ok().body("Hello from Rust CI/CD!")\n}\n\n#[actix_web::main]\nasync fn main() -> std::io::Result<()> {\n HttpServer::new(|| {\n App::new().service(hello)\n })\n .bind(("0.0.0.0", 8080))?\n .run()\n .await\n}\n\nsrc/main.rs में एक सरल टेस्ट जोड़ें (फ़ाइल के नीचे):
#[cfg(test)]\nmod tests {\n use actix_web::{test, App, web};\n use crate::hello;\n\n #[actix_web::test]\n async fn test_hello_endpoint() {\n let app = test::init_service(App::new().service(hello)).await;\n let req = test::TestRequest::get().uri("/").to_request();\n let resp = test::call_service(&app, req).await;\n assert!(resp.status().is_success());\n }\n}\n\nसब कुछ तैयार है। अब सबसे दिलचस्प हिस्सा – CI/CD सेटअप।
\n\nचरण 2: GitHub Actions वर्कफ़्लो बनाएं
\n\nGitHub Actions GitHub का बिल्ट-इन CI/CD टूल है। यह YAML फ़ाइलों पर आधारित है जो .github/workflows/ डायरेक्टरी में रहती हैं। इसे बनाएं:
mkdir -p .github/workflows\ntouch .github/workflows/ci.yml\n\nci.yml खोलें और पाइपलाइन लिखना शुरू करें। इसे "Rust CI/CD Pipeline" नाम दें।
बेसिक ट्रिगर और एनवायरनमेंट
\n\nname: Rust CI/CD Pipeline\n\non:\n push:\n branches: [ main ]\n pull_request:\n branches: [ main ]\n\nenv:\n CARGO_TERM_CO