CI/CD Pipeline
- ●CI (Continuous Integration) মানে ঘন ঘন code merge করে স্বয়ংক্রিয়ভাবে build ও test করা।
- ●CD হতে পারে Continuous Delivery (এক ক্লিকে release-ready) বা Continuous Deployment (সম্পূর্ণ স্বয়ংক্রিয় production release)।
- ●Pipeline-এর ধাপগুলো — build, test, deploy — automation দিয়ে চলে, ফলে দ্রুত ও নির্ভরযোগ্য release হয়।
সমস্যাটা কী?
পুরোনো দিনে software release ছিল ভয়ংকর ব্যাপার। ডেভেলপাররা সপ্তাহ-মাসব্যাপী আলাদা আলাদা branch-এ কাজ করত, তারপর একদিন সব merge করতে গিয়ে দেখা যেত শত শত conflict — যাকে বলা হতো "merge hell" বা "integration hell"। তারপর কেউ একজন রাত জেগে manually code build করত, FTP দিয়ে server-এ file copy করত, আর প্রার্থনা করত যেন সব ঠিক চলে। একটা ছোট ভুল হলেই পুরো site ডাউন।
এই প্রক্রিয়া ছিল ধীর, ভুলে ভরা আর ভীতিকর। দরকার ছিল এমন একটা ব্যবস্থা যেখানে code merge, test আর deploy — সব স্বয়ংক্রিয় আর ঘন ঘন হয়। সেই সমাধানই CI/CD।
মূল ধারণা
CI/CD হলো software development-এর একটি practice যেখানে code-এর integration, testing এবং deployment স্বয়ংক্রিয় pipeline-এর মাধ্যমে দ্রুত ও নিরাপদে করা হয়।
তিনটি ধারণা গুলিয়ে ফেলা সহজ:
- Continuous Integration (CI): ডেভেলপাররা দিনে কয়েকবার নিজের code মূল branch-এ merge করে। প্রতিবার merge-এ স্বয়ংক্রিয়ভাবে build ও test চলে, ফলে bug দ্রুত ধরা পড়ে।
- Continuous Delivery (CD): প্রতিটি পরিবর্তন সবসময় release-ready থাকে, কিন্তু production-এ পাঠাতে শেষে একটা manual "deploy" বোতাম চাপতে হয়।
- Continuous Deployment (CD): test pass করলেই কোনো মানুষের হস্তক্ষেপ ছাড়া স্বয়ংক্রিয়ভাবে production-এ চলে যায়।
কীভাবে কাজ করে
Pipeline-এর ধাপ
একটা সাধারণ pipeline এই ধাপগুলো অনুসরণ করে:
| ধাপ | কাজ |
|---|---|
| Source | কেউ code push বা pull request করলে pipeline trigger হয় |
| Build | code compile করে চালানোর উপযোগী artifact (যেমন Docker image) বানায় |
| Test | unit test, integration test, lint চালায় |
| Deploy (staging) | staging environment-এ পাঠিয়ে যাচাই করে |
| Deploy (production) | চূড়ান্তভাবে live server-এ পাঠায় |
কোনো একটা ধাপ ব্যর্থ হলে pipeline থেমে যায়, এবং খারাপ code পরের ধাপে যেতে পারে না। এটাই হলো নিরাপত্তা।
Automation কেন গুরুত্বপূর্ণ
মূল কথা — মানুষ ভুল করে, কিন্তু script ভুল করে না। একবার pipeline ঠিকঠাক লিখলে প্রতিবার একই ধাপ একইভাবে চলবে। কেউ "test চালাতে ভুলে গেছে" — এমন হবে না।
একটি GitHub Actions উদাহরণ
name: CI Pipeline
on:
push:
branches: [main]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '18'
- run: npm install
- run: npm test
- run: npm run build
এখানে main branch-এ push হলেই GitHub একটা ভার্চুয়াল মেশিনে code নামায়, dependency install করে, test চালায়, আর build করে — সম্পূর্ণ স্বয়ংক্রিয়ভাবে।
CI/CD-কে ভাবো একটা গার্মেন্টস কারখানার assembly line হিসেবে। কাপড় (code) এক প্রান্তে ঢোকে, তারপর কাটিং, সেলাই, কোয়ালিটি চেক — প্রতিটি ধাপ নির্দিষ্ট। কোনো শার্টে সেলাই খারাপ হলে quality check ধাপেই সেটা বাতিল হয়, খারাপ শার্ট প্যাকেজিং পর্যন্ত পৌঁছায় না। আগে যেমন একজন দরজি একা সব করত (manual, ধীর, ভুলপ্রবণ), এখন assembly line দ্রুত আর নির্ভরযোগ্য। CI/CD ঠিক তেমনই — code-কে ধাপে ধাপে check করে শুধু ভালো জিনিসই বাজারে (production) পাঠায়।
প্রকারভেদ
deployment-এর automation মাত্রা অনুযায়ী:
- Continuous Integration only: শুধু build ও test স্বয়ংক্রিয়, deploy হাতে।
- Continuous Delivery: deploy-ready, কিন্তু production-এ যেতে manual approval।
- Continuous Deployment: পুরো প্রক্রিয়া স্বয়ংক্রিয়, test pass হলেই live।
জনপ্রিয় tool: GitHub Actions, GitLab CI, Jenkins, CircleCI।
কখন ব্যবহার করবে / করবে না
ব্যবহার করবে যখন:
- একাধিক ডেভেলপার একসাথে কাজ করছে।
- ঘন ঘন release দরকার।
- manual deployment-এ ভুল হচ্ছে বা সময় নষ্ট হচ্ছে।
সতর্কতা:
- Continuous Deployment তখনই নিরাপদ যখন test coverage যথেষ্ট ভালো। দুর্বল test থাকলে এটি বরং দ্রুত production ভাঙবে।
Pipeline-এ কখনো secret (password, API key, token) সরাসরি লিখো না। GitHub Actions-এর Secrets বা vault ব্যবহার করো। আর test ধাপকে কখনো skip বা bypass করার অভ্যাস গড়ে তুলো না — তাড়াহুড়োয় test বন্ধ করে deploy করা মানে নিজের পায়ে কুড়াল মারা।
বাস্তব উদাহরণ
একটা SaaS startup-এর কথা ভাবো যেখানে ১০ জন ডেভেলপার কাজ করে। প্রতিদিন তারা ২০-৩০ বার code push করে। প্রতিটি push-এ GitHub Actions স্বয়ংক্রিয়ভাবে build ও test চালায়। কারো code test ভাঙলে সাথে সাথে Slack-এ notification যায়, ডেভেলপার তখনই ঠিক করে।
main branch-এ merge হলে code আগে staging-এ যায়, সেখানে দল যাচাই করে। সব ঠিক থাকলে এক ক্লিকে (Continuous Delivery) production-এ যায়। এর ফলে যেখানে আগে সপ্তাহে একবার ভয়ে ভয়ে release হতো, এখন দিনে কয়েকবার নির্ভয়ে release হয়। Bug-ও কম হয়, কারণ ছোট ছোট পরিবর্তন আলাদাভাবে test হয়।
Interview-তে CI আর CD-র পার্থক্য জিজ্ঞেস করলে স্পষ্ট করে বলো — CI = ঘন ঘন merge + স্বয়ংক্রিয় build/test; Continuous Delivery = সবসময় deploy-ready কিন্তু manual approval; Continuous Deployment = সম্পূর্ণ স্বয়ংক্রিয় production release। অনেকে শেষ দুটো গুলিয়ে ফেলে — তুমি যদি manual approval-এর পার্থক্যটা ধরে বলো, তোমার বোঝাপড়া আলাদা করে চোখে পড়বে।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Continuous Integration-এর মূল লক্ষ্য কী?
2. Continuous Delivery আর Continuous Deployment-এর পার্থক্য কী?
3. Pipeline-এ test ধাপ build-এর পরে রাখা হয় কেন?