CI/CD क्यों ज़रूरी है, भले ही आप रोबोट न हों?
\n\nसोचिए: शुक्रवार की शाम, आपने अभी-अभी एक नया फीचर पूरा किया है, FTP के ज़रिए सर्वर पर कोड अपलोड कर रहे हैं (हाँ, ऐसा अब भी होता है), और... साइट व्हाइट स्क्रीन ऑफ डेथ के साथ क्रैश हो जाती है। परिचित लग रहा है? अगर आपके पास PHP के लिए CI/CD पाइपलाइन होती, तो सब कुछ अपने आप हो जाता: टेस्ट पुश करते ही फेल हो जाते, कोड प्रोडक्शन पर नहीं जाता, और आप आराम से चाय पीने चले जाते।
\n\nContinuous Integration और Continuous Delivery (या Deployment) सिर्फ फैशनेबल शब्द नहीं हैं। ये आपके निजी सहायक हैं जो कोड चेक करते हैं, टेस्ट चलाते हैं, लिंट करते हैं, आर्टिफैक्ट्स बनाते हैं और सर्वर पर डिप्लॉय करते हैं। इस लेख में मैं दिखाऊंगा कि GitHub Actions का उपयोग करके PHP के लिए CI/CD पाइपलाइन को शुरुआत से कैसे सेटअप करें। कोई अमूर्त बातें नहीं - सिर्फ असली कोड और काम के उदाहरण।
\n\nCI/CD पाइपलाइन क्या है और PHP डेवलपर को इसकी ज़रूरत क्यों है?
\n\nCI/CD पाइपलाइन ऑटोमैटिक स्टेप्स का एक क्रम है जो हर बार जब आप रिपॉजिटरी में कोड पुश करते हैं तो चलता है। PHP के लिए यह विशेष रूप से महत्वपूर्ण है, क्योंकि:
\n\n- \n
- PHP एक डायनामिक भाषा है, और कई गलतियाँ (टाइपो, गलत टाइप) रनटाइम पर ही पकड़ में आती हैं। \n
- डिप्लॉय अक्सर "जुगाड़" से किया जाता है - SCP, rsync या FTP के ज़रिए (दिल की पीड़ा)। \n
- टीमें बढ़ती हैं, और मैन्युअल जाँचें एक बाधा बन जाती हैं। \n
PHP के लिए CI/CD सेटअप करने पर आपको मिलता है:
\n- \n
- हर पुश पर ऑटोमैटिक टेस्टिंग। \n
- कोड स्टाइल की जाँच (PSR-12, आपका आंतरिक मानक)। \n
- स्टेजिंग/प्रोडक्शन पर ऑटोमैटिक डिप्लॉय। \n
- बिल्ड स्टेटस के बारे में Telegram/Slack पर नोटिफिकेशन। \n
टूल चुनना: GitHub Actions क्यों?
\n\nकई विकल्प हैं: Jenkins, GitLab CI, Bitbucket Pipelines, CircleCI। लेकिन PHP के लिए CI/CD पाइपलाइन को शुरुआत से सेटअप करने के लिए मैं GitHub Actions की सलाह देता हूँ। क्यों?
\n\n- \n
- पब्लिक रिपॉजिटरी के लिए फ्री (और प्राइवेट के लिए 2000 मिनट प्रति माह - काफी है)। \n
- सब कुछ एक ही जगह - कोड, issues, actions। \n
- रेडीमेड एक्शन्स का विशाल इकोसिस्टम - पहिया फिर से नहीं बनाना पड़ता। \n
लेकिन अगर आप GitLab का उपयोग करते हैं - सिद्धांत वही हैं, बस YAML सिंटैक्स अलग है। चलिए शुरू करते हैं।
\n\nचरण 1: रिपॉजिटरी संरचना और बेसिक फ़ाइलें
\n\nडेमो के लिए हम Laravel पर एक सामान्य PHP प्रोजेक्ट लेंगे (लेकिन यह दृष्टिकोण किसी भी फ्रेमवर्क के लिए काम करता है)। आपकी संरचना इस तरह दिखनी चाहिए:
\n\nmy-php-app/\n├── .github/\n│ └── workflows/\n│ └── ci-cd.yml\n├── src/\n├── tests/\n├── composer.json\n├── phpunit.xml\n└── .php_cs.dist (अगर PHP-CS-Fixer का उपयोग कर रहे हैं)\n\n.github/workflows/ फ़ोल्डर और ci-cd.yml फ़ाइल बनाएँ - यह आपकी पाइपलाइन का दिल है।
चरण 2: बेसिक YAML - निरंतर एकीकरण (CI)
\n\nसरल शुरुआत करें: main में हर पुश या pull request पर टेस्ट और लिंटिंग चलाएँ। यहाँ एक न्यूनतम PHP CI/CD पाइपलाइन है:
\n\nname: PHP CI/CD Pipeline\n\non:\n push:\n branches: [ main, develop ]\n pull_request:\n branches: [ main ]\n\njobs:\n build-and-test:\n runs-on: ubuntu-latest\n\n steps:\n - uses: actions/checkout@v4\n\n - name: Setup PHP\n uses: shivammathur/setup-php@v2\n with:\n php-version: '8.2'\n extensions: mbstring, pdo, sqlite, gd\n coverage: xdebug\n\n - name: Install dependencies\n run: composer install --prefer-dist --no-progress\n\n - name: Run PHP CS Fixer (Lint)\n run: vendor/bin/php-cs-fixer fix --dry-run --diff\n\n - name: Run PHPStan (Static Analysis)\n run: vendor/bin/phpstan analyse src --level=5\n\n - name: Run Tests\n run: vendor/bin/phpunit --coverage-text\n\nयहाँ क्या हो रहा है?
\n- \n
- checkout - कोड लाता है। \n
- setup-php - PHP सेटअप करता है।