পাঠ ৩৪ · ৫৭-এর মধ্যে · মডিউল ৮
Home / Courses / Cloud Computing & DevOps / ডেলিভারি বনাম ডিপ্লয়মেন্ট

Continuous Delivery বনাম Continuous Deployment

Continuous Delivery vs Continuous Deployment
৭ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • Continuous Delivery ও Continuous Deployment উভয়ই কীভাবে CI-এর উপর ভিত্তি করে তৈরি
  • দুটোর মধ্যে সঠিক পার্থক্য — মানুষের অনুমোদন গেট আছে না নেই
  • কোন পরিস্থিতিতে কোনটি বেছে নেওয়া উচিত (ব্যবসায়িক ঝুঁকি বনাম টেস্টিং পরিপক্বতা)
  • Python দিয়ে দুটো মোড সিমুলেট করা এবং একই বিল্ড রেজাল্টের উপর ভিন্ন আউটকাম দেখা

১ · CI-এর পরে কী — একটি সাধারণ প্রশ্ন

L33-এ আমরা দেখেছি একটি পরিবর্তন লিন্ট, টেস্ট ও বিল্ড স্টেজ পাস করলে CI সফল বলে গণ্য হয়। কিন্তু CI পাস করা মানেই কি সাথে সাথে ব্যবহারকারীরা এই পরিবর্তন দেখবেন? এখানেই Continuous Delivery ও Continuous Deployment-এর পার্থক্য আসে — দুটোই CI-এর সম্প্রসারণ, কিন্তু "স্বয়ংক্রিয়ভাবে কতদূর যাওয়া হবে" তার উত্তর ভিন্ন।

২ · Continuous Delivery — মানুষের একটি চূড়ান্ত গেট

Continuous DeliveryCD (Delivery)CI পাস করা প্রতিটি পরিবর্তন স্বয়ংক্রিয়ভাবে রিলিজের জন্য প্রস্তুত হয়ে যায়, কিন্তু প্রোডাকশনে প্রকৃত ডিপ্লয় করার সিদ্ধান্ত একজন মানুষ নেন। -এ CI পাস করা প্রতিটি পরিবর্তন স্বয়ংক্রিয়ভাবে বিল্ড, টেস্ট ও প্যাকেজ হয়ে যেকোনো সময় রিলিজ করার জন্য প্রস্তুত থাকে — কিন্তু আসলে প্রোডাকশনে ঠেলে দেওয়ার সিদ্ধান্তটা একজন মানুষ নেন (একটি ম্যানুয়াল "go" বাটন চাপার মতো)। যেসব ক্ষেত্রে ডিপ্লয়মেন্টের সাথে ব্যবসায়িক ঝুঁকি জড়িত (যেমন একটি নির্দিষ্ট সময়ে রিলিজ করতে হবে, বা কমপ্লায়েন্স সাইন-অফ প্রয়োজন), সেখানে এই প্যাটার্ন সাধারণ।

৩ · Continuous Deployment — সম্পূর্ণ স্বয়ংক্রিয়

Continuous DeploymentCD (Deployment)সব স্বয়ংক্রিয় চেক পাস করা প্রতিটি পরিবর্তন কোনো মানুষের হস্তক্ষেপ ছাড়াই সরাসরি প্রোডাকশনে ডিপ্লয় হয়ে যায়। আরও একধাপ এগিয়ে যায় — সব স্বয়ংক্রিয় চেক পাস করা প্রতিটি পরিবর্তন কোনো মানুষের হস্তক্ষেপ ছাড়াই সরাসরি প্রোডাকশনে ডিপ্লয় হয়ে যায়। এর জন্য প্রয়োজন স্বয়ংক্রিয় টেস্টিং, মনিটরিং (M10) ও রোলব্যাক সক্ষমতার (M8/L37) উপর অত্যন্ত উচ্চ আস্থা — কারণ কোনো মানুষ শেষবারের মতো পরিবর্তনটি দেখে অনুমোদন দিচ্ছেন না, বাস্তব ব্যবহারকারীরাই প্রথম "পরীক্ষক" হয়ে যেতে পারেন যদি স্বয়ংক্রিয় চেকগুলো কোনো সমস্যা ধরতে ব্যর্থ হয়।

দুটোই CI-এর উপর নির্ভরশীল, একটির মধ্যে অন্যটি অন্তর্ভুক্ত নয়

Continuous Delivery ও Continuous Deployment উভয়েরই ভিত্তি একই — একটি শক্তিশালী, বিশ্বাসযোগ্য CI পাইপলাইন (L33)। পার্থক্যটা শুধু CI পাস করার পরে কী ঘটে তাতে — একটিতে মানুষ চূড়ান্ত সিদ্ধান্ত নেয়, অন্যটিতে সিস্টেম নিজেই নেয়। কোনোটিই "ভুল" নয় — নির্বাচন নির্ভর করে টিমের টেস্টিং পরিপক্বতা ও ব্যবসায়িক ঝুঁকির সহনশীলতার উপর।

Python
# Continuous Delivery বনাম Continuous Deployment — একই build_result, দুই ভিন্ন মোড

def deploy_to_production(build_result):
    print(f"  → প্রোডাকশনে ডিপ্লয় হচ্ছে: ভার্সন {build_result['version']}")
    return f"DEPLOYED:{build_result['version']}"


def deliver(build_result, mode):
    print(f"[{mode}] বিল্ড {build_result['version']} সফলভাবে প্যাকেজড হয়েছে, রিলিজের জন্য প্রস্তুত")

    if mode == "delivery":
        print("  → মানুষের চূড়ান্ত অনুমোদনের অপেক্ষায় (Continuous Delivery)")
        return "AWAITING_MANUAL_APPROVAL"

    elif mode == "deployment":
        print("  → কোনো মানুষের হস্তক্ষেপ ছাড়াই সরাসরি ডিপ্লয় (Continuous Deployment)")
        return deploy_to_production(build_result)

    else:
        raise ValueError(f"অজানা মোড: {mode}")


# CI (L33) পাস করা একটি বিল্ডের ফলাফল — উভয় মোডেই একই ইনপুট ব্যবহার করা হচ্ছে
build_result = {"version": "v2.4.1", "all_tests_passed": True}

print("===== মোড: Continuous Delivery =====")
outcome_delivery = deliver(build_result, mode="delivery")
print("চূড়ান্ত ফলাফল:", outcome_delivery)

print("\n===== মোড: Continuous Deployment =====")
outcome_deployment = deliver(build_result, mode="deployment")
print("চূড়ান্ত ফলাফল:", outcome_deployment)

    
লক্ষ্য করুন deliver() ফাংশনটি একদম একই build_result নিয়ে দুটো সম্পূর্ণ ভিন্ন আউটকাম দেয় — শুধুমাত্র mode প্যারামিটারের উপর ভিত্তি করে। এটাই মূল কথা — কোড/বিল্ড একই থাকে, শুধু "শেষ ধাপে যাওয়ার" সিদ্ধান্ত-প্রক্রিয়া ভিন্ন।

৪ · কোনটি বেছে নেবেন

Continuous Delivery সাধারণত ভালো যেখানে ব্যবসায়িক প্রেক্ষাপট (নির্দিষ্ট রিলিজ উইন্ডো, রেগুলেটরি সাইন-অফ, বা টিম এখনো তার স্বয়ংক্রিয় টেস্ট স্যুটের উপর পূর্ণ আস্থা তৈরি করছে) মানুষের একটি চূড়ান্ত চেক দাবি করে। Continuous Deployment সবচেয়ে ভালো কাজ করে যখন টিমের একটি পরিপক্ব, ব্যাপক টেস্ট স্যুট আছে, শক্তিশালী মনিটরিং/অ্যালার্টিং (M10) আছে, এবং দ্রুত রোলব্যাক করার সক্ষমতা (M8/L37) আছে — তখন ঘনঘন, ছোট, স্বয়ংক্রিয় রিলিজের গতি একটি বড় প্রতিযোগিতামূলক সুবিধা হয়ে ওঠে।

মূল কথা · Key takeaway

Continuous Delivery ও Continuous Deployment উভয়েই CI-কে ভিত্তি করে গড়ে ওঠে — একটিতে মানুষ চূড়ান্ত "go" দেন, অন্যটিতে পুরো প্রক্রিয়া স্বয়ংক্রিয়। L35 এই দুই মোডের পেছনের সম্পূর্ণ পাইপলাইন ডিজাইন — কোন স্টেজ কোন ক্রমে চলে, এবং কীভাবে সেগুলো দ্রুততর করা যায় — বিস্তারিত দেখাবে।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি ব্যাংকিং অ্যাপ্লিকেশন টিম কেন প্রায়ই Continuous Deployment-এর বদলে Continuous Delivery বেছে নিতে পারে?

আর্থিক লেনদেন-সংশ্লিষ্ট সিস্টেমে প্রায়ই রেগুলেটরি কমপ্লায়েন্স প্রয়োজন হয় যেখানে একজন দায়িত্বশীল মানুষকে প্রতিটি প্রোডাকশন পরিবর্তন পর্যালোচনা ও অনুমোদন করতে হয় — এমনকি যদি স্বয়ংক্রিয় টেস্ট স্যুট শক্তিশালীও হয়, ব্যবসায়িক/আইনি প্রেক্ষাপট একটি ম্যানুয়াল চূড়ান্ত গেট দাবি করতে পারে।

প্র ০২ Continuous Deployment বেছে নেওয়ার আগে একটি টিমের কী থাকা "আবশ্যক" বলে মনে হয়, এবং কেন?

একটি ব্যাপক, বিশ্বাসযোগ্য স্বয়ংক্রিয় টেস্ট স্যুট, শক্তিশালী মনিটরিং/অ্যালার্টিং (M10-এর সিগন্যাল), এবং দ্রুত রোলব্যাক করার সক্ষমতা — কারণ যেহেতু কোনো মানুষ শেষবারের মতো পরিবর্তনটি দেখছেন না, তাই একটি সমস্যা যদি স্বয়ংক্রিয় চেকে ধরা না পড়ে, প্রথম যে জিনিসটি সেটি ধরবে তা হলো মনিটরিং — এবং তখন দ্রুত রোলব্যাক করার সক্ষমতাই ক্ষতি সীমিত রাখার একমাত্র উপায়।

প্র ০৩ উপরের কোড সেলে deliver() ফাংশনটি "delivery" মোডে সরাসরি deploy_to_production() কল করে না কেন?

কারণ Continuous Delivery-এর সংজ্ঞা অনুযায়ী পরিবর্তনটি শুধু প্রস্তুত হয়, স্বয়ংক্রিয়ভাবে ডিপ্লয় হয় না — কোডে এটি ফুটিয়ে তোলার সবচেয়ে সৎ উপায় হলো একটি পৃথক ধাপ (এখানে "AWAITING_MANUAL_APPROVAL" রিটার্ন করা) দেখানো, যা প্রকৃতপক্ষে একজন মানুষের পরবর্তী পদক্ষেপ নেওয়ার অপেক্ষায় থাকাকে প্রতিনিধিত্ব করে।

অনুশীলন

  1. চিন্তা করুন: উপরের কোড সেলে mode="delivery" চালানোর পর ফলাফল "AWAITING_MANUAL_APPROVAL" — এই অবস্থা থেকে বাস্তবে পরিবর্তনটি প্রোডাকশনে পৌঁছাতে কী ঘটতে হবে?

    একজন মানুষ (সাধারণত একজন রিলিজ ম্যানেজার বা টিম লিড) প্রস্তুত পরিবর্তনটি পর্যালোচনা করে স্পষ্টভাবে অনুমোদন দেবেন — যেমন একটি ইউআই-তে "Deploy" বাটন চাপা, যা তখন প্রকৃতপক্ষে deploy_to_production(build_result)-এর মতো একটি কল ট্রিগার করবে।

  2. পরীক্ষা করুন: একটি নতুন ফাংশন approve_and_deploy(build_result) লিখুন যা ম্যানুয়াল অনুমোদনকে প্রতিনিধিত্ব করে — এটি একটি "অনুমোদন" মেসেজ প্রিন্ট করে তারপর deploy_to_production(build_result) কল করবে। deliver(build_result, mode="delivery") চালানোর পর এই নতুন ফাংশনটি কল করে সম্পূর্ণ Continuous Delivery ফ্লো (প্রস্তুত → অনুমোদন → ডিপ্লয়) সিমুলেট করুন।

    def approve_and_deploy(build_result): print("একজন মানুষ পরিবর্তনটি অনুমোদন করলেন"); return deploy_to_production(build_result) লিখে, প্রথমে deliver(build_result, mode="delivery") কল করে "AWAITING_MANUAL_APPROVAL" পাওয়ার পর approve_and_deploy(build_result) কল করলে দেখবেন সম্পূর্ণ ফ্লোটি — প্রস্তুত হওয়া থেকে অনুমোদন হয়ে অবশেষে ডিপ্লয় পর্যন্ত — ধাপে ধাপে ঘটছে, প্রতিটি ধাপে স্পষ্ট মানুষের সিদ্ধান্তের বিন্দুসহ।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
L33 · Continuous Integration পরিচিতি