CI/CD কী? Continuous Integration ও Delivery সহজ ভাষায়
CI/CD হলো সফটওয়্যার প্রকাশের একটি পদ্ধতি, যেখানে প্রতিটি কোড পরিবর্তন স্বয়ংক্রিয়ভাবে বিল্ড ও পরীক্ষা করা হয় এবং — পাস করলে — প্রকাশের জন্য প্রস্তুত বা প্রকাশিত হয়। CI (continuous integration) মানে পরিবর্তনগুলো ঘন ঘন মেশানো হয় এবং প্রতিবার স্বয়ংক্রিয় পরীক্ষা দিয়ে যাচাই করা হয়। CD (continuous delivery বা deployment) মানে যেসব পরিবর্তন পাস করে, সেগুলো প্যাকেজ করে ব্যবহারকারীদের দিকে কম বা কোনো ম্যানুয়াল কাজ ছাড়াই এগিয়ে দেওয়া হয়।
মূল কথা সহজ: ভুল করার মিনিট কয়েক পরেই ধরা, সপ্তাহ পরে কোনো গ্রাহকের চোখে পড়ার বদলে।
AI দিয়ে অ্যাপ বানালে CI/CD কেন গুরুত্বপূর্ণ
AI বিল্ডাররা কোড পরিবর্তন দ্রুত করে। একটি প্রম্পট দশটি ফাইল ছুঁতে পারে। এই গতি ভালো, যতক্ষণ না চেকআউট পেজের একটি পরিবর্তন নীরবে লগইন পেজ ভেঙে দেয় আর কোনো ব্যবহারকারী ইমেইল না করা পর্যন্ত কেউ খেয়াল না করে।
এই ঠিক সমস্যার জন্যই CI/CD একটি নিরাপত্তা জাল। প্রতিটি পরিবর্তন ধরে নেওয়ার বদলে একটি পাইপলাইন প্রতিবার একই পরীক্ষাগুলো চালায়:
- অ্যাপ কি এখনও কোনো ত্রুটি ছাড়া বিল্ড হচ্ছে?
- স্বয়ংক্রিয় টেস্টগুলো কি এখনও পাস করছে?
- কোড কি প্রজেক্টের নিয়ম (টাইপ, ফরম্যাটিং, নিরাপত্তা স্ক্যান) মানছে?
কোনো পরীক্ষা ব্যর্থ হলে পরিবর্তনটি ব্যবহারকারীদের কাছে পৌঁছানোর আগেই থামানো হয়। কোড যত দ্রুত বদলায়, একটি পরীক্ষা যা কখনও ক্লান্ত হয় না বা কোনো ধাপ এড়ায় না, তত মূল্যবান।
একটি দৈনন্দিন উপমা
একটি বেকারির কথা ভাবুন, যারা প্রতি সকালে দোকানে রুটি সরবরাহ করে।
- CI/CD ছাড়া, প্রতিটি কারিগর এক সপ্তাহ ধরে নিজের রেসিপি বদলায়, তারপর শুক্রবার রাতে সবাই একসাথে মিশিয়ে আশা করে রুটি ফুলবে। না ফুললে কারও জানা থাকে না কার পরিবর্তনে সমস্যা হয়েছে।
- CI-এর সাথে, প্রতিটি ছোট রেসিপি পরিবর্তন সাথে সাথে একটি পরীক্ষামূলক ব্যাচে বানিয়ে যাচাই করা হয় — স্বাদ, ওজন, আকার। একটি খারাপ পরিবর্তন সেদিনই ধরা পড়ে, এবং আপনি জানেন ঠিক কোনটি ছিল।
- CD-র সাথে, যাচাইয়ে পাস করা রুটি সরাসরি ডেলিভারি ভ্যানে যায়, প্রতিবার একই রকম প্যাকেট ও লেবেল দিয়ে, ভোর ৫টায় কেউ হাতে বাক্স সাজানোর বদলে।
যাচাইটি কারিগরদের ভালো করে না। এটি তাদের ভুলগুলো সস্তা করে।
CI/CD পাইপলাইন কীভাবে কাজ করে
একটি পাইপলাইন হলো ধাপগুলোর একটি তালিকা, যা একটি CI/CD সার্ভিস স্বয়ংক্রিয়ভাবে চালায় যখন কিছু ঘটে — সাধারণত যখন কেউ GitHub-এর মতো একটি রিপোজিটরিতে কোড পুশ করে। একটি সাধারণ পাইপলাইন এমন দেখায়:
| ধাপ | কী ঘটে | কী ধরে |
|---|---|---|
| ১. Trigger | কোড পুশ করা হয় বা একটি pull request খোলা হয় | — |
| ২. Install | একটি নতুন মেশিন কোড ও তার ডিপেন্ডেন্সি ডাউনলোড করে | অনুপস্থিত বা ভাঙা প্যাকেজ |
| ৩. Build | অ্যাপ কম্পাইল বা বান্ডল করা হয় | সিনট্যাক্স ও টাইপ ত্রুটি, ভাঙা ইমপোর্ট |
| ৪. Test | স্বয়ংক্রিয় টেস্ট চলে | যেসব ফিচার আর কাজ করে না |
| ৫. Checks | Linting, ফরম্যাটিং, নিরাপত্তা স্ক্যান | স্টাইল সমস্যা, পরিচিত ঝুঁকিপূর্ণ প্যাকেজ, ফাঁস হওয়া কী |
| ৬. Staging-এ deploy | অ্যাপ প্রোডাকশনের একটি টেস্ট কপিতে যায় | শুধু আসল পরিবেশে দেখা যায় এমন সমস্যা |
| ৭. Production-এ deploy | অ্যাপ লাইভ হয় — স্বয়ংক্রিয়ভাবে বা অনুমোদনের পর | — |
প্রতিটি ধাপ একটি পরিষ্কার মেশিনে চলে, কারও ল্যাপটপে নয়, তাই “আমার কম্পিউটারে তো চলছিল” বলার সুযোগ থাকে না। কোনো ধাপ ব্যর্থ হলে পাইপলাইন থেমে যায় এবং যিনি পরিবর্তন করেছেন তাকে জানায়।
ধাপগুলো একটি কনফিগারেশন ফাইলে লেখা থাকে, যা কোডের সাথেই থাকে। যেমন GitHub Actions-এ এটি রিপোজিটরির .github/workflows ফোল্ডারে একটি YAML ফাইল।
Continuous delivery বনাম continuous deployment
“CD” শব্দটি দ্ব্যর্থক, এবং মানুষ দুই অর্থেই ব্যবহার করে:
| Continuous delivery | Continuous deployment | |
|---|---|---|
| টেস্ট স্বয়ংক্রিয়ভাবে চলে | হ্যাঁ | হ্যাঁ |
| রিলিজ স্বয়ংক্রিয়ভাবে প্যাকেজ হয় | হ্যাঁ | হ্যাঁ |
| স্বয়ংক্রিয়ভাবে লাইভ হয় | না — একজন মানুষ “release” চাপে | হ্যাঁ — প্রতিটি পাস করা পরিবর্তন প্রকাশিত হয় |
| যেখানে ভালো | বেশিরভাগ ছোট দল, পেইড ব্যবহারকারীর অ্যাপ | ভালো টেস্ট কভারেজ ও মনিটরিং থাকা দল |
Continuous deployment শুধু তখনই ভালো কাজ করে যখন টেস্ট ভালো হয়। যদি আপনার টেস্ট চেকআউট না ঢাকে, continuous deployment খুশিমনে একটি ভাঙা চেকআউট প্রকাশ করে দেবে।
একটি বাস্তব উদাহরণ: পাইপলাইনসহ একটি বুকিং অ্যাপ
ধরুন আপনার একটি সেলুন বুকিং অ্যাপ আছে, এবং এর কোড একটি GitHub রিপোজিটরিতে। আপনি একটি AI বিল্ডারকে বললেন: “প্রথমবারের গ্রাহকদের জন্য ১০% ছাড় যোগ করো।”
- পরিবর্তনটি একটি নতুন ব্রাঞ্চে পুশ হয় এবং একটি pull request খোলা হয়।
- পাইপলাইন শুরু হয়। এটি প্যাকেজ ইনস্টল করে ও অ্যাপ বিল্ড করে — এটি পাস করে।
- এটি টেস্ট চালায়। একটি টেস্ট, “একজন ফেরত আসা গ্রাহক পূর্ণ দাম দেয়”, ব্যর্থ হয়: ছাড়টি সবার ওপর প্রয়োগ হচ্ছে।
- Pull request-এ একটি লাল ক্রস দেখায়। পরিবর্তনটি মার্জ করা যায় না।
- আপনি AI-কে ঠিক করতে বলেন। এটি একটি সংশোধন পুশ করে; পাইপলাইন আবার চলে এবং সবকিছু পাস করে।
- পরিবর্তনটি মার্জ হয়। পাইপলাইন এটি একটি staging environment-এ deploy করে, যেখানে আপনি একটি টেস্ট বুকিং দেন।
- আপনি অনুমোদন দেন, এবং এটি প্রোডাকশনে deploy হয়।
পাইপলাইন ছাড়া, ধাপ ৩-এ যা ঘটত তা হতো আপনার গ্রাহকদের পকেটে।
মূল শব্দ
| শব্দ | অর্থ |
|---|---|
| Pipeline | প্রতিটি পরিবর্তনে চলা স্বয়ংক্রিয় ধাপের ক্রম। |
| Build | সোর্স কোডকে চালানোর উপযোগী কিছুতে রূপান্তর। |
| Automated test | কোড যা করা উচিত তা অন্য কোড ঠিক করছে কি না তা যাচাই করে এমন কোড। |
| Pull request (PR) | একটি প্রস্তাবিত পরিবর্তন, যা মার্জ হওয়ার আগে অন্যরা (এবং পাইপলাইন) পর্যালোচনা করে। দেখুন GitHub কী। |
| Branch | কাজের একটি আলাদা লাইন, যাতে অসম্পূর্ণ কাজ মূল কোডকে প্রভাবিত না করে। |
| Staging | প্রোডাকশনের মতো একটি ব্যক্তিগত কপি, যেখানে ব্যবহারকারীরা দেখার আগে পরিবর্তন যাচাই করা হয়। |
| Production | লাইভ অ্যাপ, যা আপনার ব্যবহারকারীরা ব্যবহার করেন। |
| Rollback | রিলিজ ভুল হলে আগের কাজ করা ভার্সনে ফিরে যাওয়া। |
| Green / red build | একটি পাইপলাইন চলা, যা পাস / ব্যর্থ হয়েছে। |
সাধারণ ভুল ধারণা
- “CI/CD মানে আমার অ্যাপ টেস্ট হয়েছে।” পাইপলাইন শুধু আপনার যে টেস্ট আছে তাই চালায়। টেস্ট না থাকলে CI শুধু প্রমাণ করে অ্যাপ বিল্ড হয়। আপনার AI-কে গুরুত্বপূর্ণ ফ্লোগুলোর জন্য টেস্ট লিখতে বলুন।
- “CI/CD শুধু বড় কোম্পানির জন্য।” GitHub Actions-এর মতো হোস্টেড টুল একটি ছোট কনফিগারেশন ফাইল দিয়ে সেটআপ হয়, এবং ছোট দলও এগুলো নিয়মিত ব্যবহার করে। পরিশ্রম টুলের নয়, টেস্টের।
- “স্বয়ংক্রিয় ডিপ্লয় মানে কেউ কিছু যাচাই করে না।” ভালো পাইপলাইন যাচাই যোগ করে, সরায় না। অনেক দল প্রোডাকশনের আগে একটি মানুষের অনুমোদন ধাপ রাখে।
- “পাইপলাইন সবুজ হলে অ্যাপ কাজ করে।” এর মানে স্বয়ংক্রিয় যাচাইগুলো পাস করেছে। তবু আপনার নিজের পরিবর্তন চেষ্টা করা উচিত, আদর্শভাবে প্রিভিউ বা staging-এ।
- “CI/CD ব্যাকআপের বিকল্প।” নয়। একটি খারাপ ডেটাবেস মাইগ্রেশন যা টেস্ট পাস করে তবুও আসল ডেটার ক্ষতি করতে পারে। ব্যাকআপ ও রোলব্যাকের উপায় রাখুন।
আপনার AI বিল্ডারকে কী জিজ্ঞেস করবেন
- “সাইন-আপ, লগইন ও চেকআউটের জন্য স্বয়ংক্রিয় টেস্ট লেখো, এবং কীভাবে চালাতে হয় দেখাও।”
- “একটি GitHub Actions ওয়ার্কফ্লো সেট করো, যা প্রতিটি pull request-এ ডিপেন্ডেন্সি ইনস্টল করে, অ্যাপ বিল্ড করে ও টেস্ট চালায়।”
- “পাইপলাইনে একটি টাইপ চেক ও একটি linter যোগ করো, এবং ত্রুটিতে ব্যর্থ হতে দাও।”
- “পাইপলাইনের প্রতিটি ধাপ সহজ ভাষায় ব্যাখ্যা করো।”
- “deploy মাঝপথে ব্যর্থ হলে কী হয়? আমি কীভাবে রোলব্যাক করব?”
- “নিশ্চিত করো রিপোজিটরিতে বা পাইপলাইন লগে কোনো সিক্রেট হার্ড-কোড বা প্রিন্ট হচ্ছে না।”
আপনার অ্যাপে API কী থাকলে পাইপলাইনেরও সেগুলো দরকার — CI টুলে এনক্রিপ্ট করা সিক্রেট হিসেবে, কনফিগারেশন ফাইলে কখনও নয়। দেখুন এনভায়রনমেন্ট ভেরিয়েবল ও সিক্রেট।
CI/CD ও Mythex
Mythex আপনার জন্য একটি CI পাইপলাইন চালায় না, তবে নিজের উপায়ে একই কিছু প্রয়োজন পূরণ করে:
- Checkpoints। এজেন্টের প্রতিটি সফল টার্নের পর Mythex একটি git checkpoint সংরক্ষণ করে, এবং Revert to this point কোনো পরিবর্তন ভুল হলে প্রজেক্টকে ফিরিয়ে আনে। দেখুন Chat।
- App Testing।
/testটাইপ করলে এজেন্ট আপনার লাইভ প্রিভিউতে একজন ব্যবহারকারীর মতো ক্লিক করে এবং ভাঙা ফ্লো রিপোর্ট করে — প্রতিটি প্রকাশের আগে কাজে আসে। দেখুন App Testing। - প্রকাশ একটি সচেতন ধাপ। পরিবর্তনগুলো আগে ব্যক্তিগত প্রিভিউতে দেখা যায়; আপনার পাবলিক অ্যাপ শুধু আবার প্রকাশ করলে আপডেট হয় — continuous deployment-এর চেয়ে continuous delivery-র কাছাকাছি।
- GitHub সিঙ্ক (Pro)। প্রজেক্টকে একটি GitHub রিপোজিটরিতে সিঙ্ক করলে আপনি প্রতিটি পুশে টেস্ট চালাতে আপনার নিজের GitHub Actions ওয়ার্কফ্লো যোগ করতে পারেন। দেখুন GitHub ও এক্সপোর্ট।
লাইভ যাওয়ার আগে হাতে কী পরীক্ষা করবেন তার একটি চেকলিস্টের জন্য দেখুন লঞ্চের আগে অ্যাপ কীভাবে টেস্ট করবেন, এবং ভার্সন কন্ট্রোলের সাথে কাজ করার জন্য AI-তৈরি অ্যাপে Git কীভাবে ব্যবহার করবেন।
প্রশ্নোত্তর
CI/CD-এর পুরো নাম কী?
CI মানে continuous integration: প্রতিটি কোড পরিবর্তন ঘন ঘন মিশিয়ে স্বয়ংক্রিয়ভাবে বিল্ড ও পরীক্ষা করা হয়। CD মানে continuous delivery বা continuous deployment: যেসব পরিবর্তন পরীক্ষায় পাস করে, সেগুলো প্রকাশের জন্য স্বয়ংক্রিয়ভাবে প্রস্তুত (delivery) বা কোনো ম্যানুয়াল ধাপ ছাড়াই ব্যবহারকারীর কাছে প্রকাশ (deployment) করা হয়।
Continuous delivery ও continuous deployment-এর মধ্যে পার্থক্য কী?
Continuous delivery-তে প্রতিটি পাস করা পরিবর্তন প্রকাশের জন্য প্রস্তুত থাকে, কিন্তু কখন লাইভ করা হবে তা একজন মানুষ ঠিক করে। Continuous deployment-এ প্রতিটি পাস করা পরিবর্তন স্বয়ংক্রিয়ভাবে লাইভ হয়, কোনো মানুষের অনুমোদন ছাড়াই।
AI দিয়ে বানানো ছোট অ্যাপে কি CI/CD দরকার?
প্রথম দিন থেকেই নয়। হাতে কয়েকজন ব্যবহারকারীর একটি ছোট অ্যাপ প্রিভিউতে টেস্ট করে নিজে প্রকাশ করেই চলতে পারে। CI/CD-এর মূল্য তখন বোঝা যায় যখন একাধিক মানুষ কোড বদলায়, আসল গ্রাহক অ্যাপের ওপর নির্ভর করে, বা যা আগে কাজ করত তা বারবার ভাঙে।
CI/CD-র জন্য কোন টুল ব্যবহার করা হয়?
সাধারণগুলোর মধ্যে আছে GitHub Actions, GitLab CI/CD, CircleCI ও Jenkins, পাশাপাশি হোস্টিং প্ল্যাটফর্মের নিজস্ব ডিপ্লয় পাইপলাইন। সবাই একই মৌলিক কাজ করে: কোড বদলালে স্বয়ংক্রিয়ভাবে ধাপগুলোর একটি তালিকা চালায়।