বিল্ড ভাঙ্গুন: এটি কী, কারণ এবং প্রকল্পে কীভাবে এড়াবেন

ডেভেলপমেন্টে বিল্ড ভাঙ্গার অর্থ কী

বিল্ড ভাঙ্গা হল এমন একটি পরিস্থিতি যেখানে পরিবর্তন আনার পর প্রকল্প বিল্ড হওয়া বন্ধ করে দেয়। CI/CD-এর প্রসঙ্গে, এর অর্থ বিল্ড পাইপলাইন ব্যর্থ হয় এবং কোনো আর্টিফ্যাক্ট তৈরি হয় না।

মোবাইল এবং ওয়েব ডেভেলপমেন্টের জগতে, বিল্ড হল সোর্স কোডকে একটি এক্সিকিউটেবল ফাইল বা প্যাকেজে অনুবাদ করার প্রক্রিয়া। Android-এর জন্য, এটি Gradle-এর মাধ্যমে APK বা AAB তৈরি করা; iOS-এর জন্য, Xcode-এর মাধ্যমে কম্পাইল করা; ওয়েব প্রকল্পের জন্য, Webpack বা Vite-এর মাধ্যমে বান্ডল করা। আপনি এই যেকোনো পর্যায়ে বিল্ড ভাঙতে পারেন।

আধুনিক সংস্করণ নিয়ন্ত্রণ ব্যবস্থা এবং CI/CD টুল যেমন Jenkins, GitHub Actions এবং GitLab CI স্বয়ংক্রিয়ভাবে ভাঙা বিল্ড সনাক্ত করে এবং টিমকে জানায়। বেশিরভাগ প্রকল্পে একটি নিয়ম আছে: যদি বিল্ড ভাঙা থাকে, তবে বিল্ড ঠিক না হওয়া পর্যন্ত অন্যান্য সমস্ত কাজের অগ্রাধিকার কমিয়ে দেওয়া হয়।

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // এই লাইনটি বিল্ড ভেঙে দেয়
    val number: Int = "not a number"
}

এই উদাহরণে, Int টাইপের একটি ভেরিয়েবলে স্ট্রিং অ্যাসাইন করলে কম্পাইলেশন ত্রুটি হয়। টাইপ মিসম্যাচ স্ট্যাটিক্যালি টাইপ করা ভাষাগুলিতে বিল্ড ভাঙার সবচেয়ে সাধারণ কারণগুলির মধ্যে একটি।

বিল্ড ব্যর্থতার প্রধান কারণ

বেশ কয়েকটি বিভাগের ত্রুটি রয়েছে যা ভাঙা বিল্ডের কারণ হয়। 2024 সালের GitLab বিশ্লেষণ অনুযায়ী, কারণগুলির বিতরণ নিম্নরূপ।

সবচেয়ে কপট বিভাগ হল নির্ভরতা সমস্যা। একটি মডিউলে লাইব্রেরি আপডেট করলে পাশের মডিউলে বিল্ড ভেঙে যেতে পারে যদি API বা পদ্ধতির আচরণ পরিবর্তিত হয়।

অন্যদিকে, সিনট্যাক্স ত্রুটিগুলি দ্রুত সনাক্ত করা যায় — কম্পাইলার সঠিক লাইন এবং ত্রুটির ধরন নির্দেশ করে। এই কারণেই স্ট্যাটিক্যালি টাইপ করা ভাষাগুলিকে বিল্ড স্থিতিশীলতার ক্ষেত্রে ডায়নামিক্যালি টাইপ করা ভাষাগুলির তুলনায় বেশি নির্ভরযোগ্য বলে মনে করা হয়।

ভাঙা বিল্ড টিমকে কীভাবে প্রভাবিত করে

ভাঙা বিল্ড সরাসরি টিমের উত্পাদনশীলতাকে প্রভাবিত করে। যখন বিল্ড ব্যর্থ হয়, ডেভেলপাররা রিপোজিটরি থেকে প্রকল্পের সর্বশেষ সংস্করণ পেতে পারেন না, এবং CI পাইপলাইন পরবর্তী সমস্ত পরিবর্তনের জন্য ব্লক হয়ে যায়।

Atlassian-এর 2023 সালের একটি গবেষণায় দেখা গেছে যে প্রকল্পগুলি যেখানে বিল্ড চার ঘন্টার বেশি ভাঙা থাকে তারা টিমের উত্পাদনশীল সময়ের গড়ে 25% হারায়। ডেভেলপাররা তাদের কাজ সম্পূর্ণ করার পরিবর্তে সমস্যা নির্ণয়ে মনোযোগ দিতে বাধ্য হন।

উত্পাদনশীলতা ছাড়াও, নৈতিক পরিবেশও ক্ষতিগ্রস্ত হয়। বিল্ড ভাঙা ডেভেলপার সহকর্মীদের কাছ থেকে চাপ অনুভব করেন। সুস্থ টিমগুলিতে নিয়ম হল: ভাঙা বিল্ডের জন্য শাস্তি নয়, তবে তাৎক্ষণিক সমাধান দাবি করা। দোষমুক্ত সংস্কৃতি হল এমন একটি পদ্ধতি যেখানে ঘটনাটি কারও ভুল হিসাবে নয় বরং একটি পদ্ধতিগত সমস্যা হিসাবে বিশ্লেষণ করা হয়।

বিতরিত টিমগুলিতে, ভাঙা বিল্ড অন্য সময় অঞ্চলের সহকর্মীদের কাজ ব্লক করতে পারে। যদি ইউরোপের কোনো ডেভেলপার চলে যাওয়ার আগে বিল্ড ভেঙে দেয়, এশিয়ার টিম ফিক্সের অপেক্ষায় পুরো কার্যদিবস হারাতে পারে।

ভাঙা বিল্ড কীভাবে প্রতিরোধ করবেন

ভাঙা বিল্ড প্রতিরোধ কমিটের আগে স্থানীয় পরীক্ষা দিয়ে শুরু হয়। প্রতিটি ডেভেলপারের পরিবর্তন পুশ করার আগে পরীক্ষা এবং বিল্ড চালানো উচিত। প্রধান প্রতিরোধ পদ্ধতিগুলি বেশ কয়েকটি স্তরে বিভক্ত।

• প্রি-কমিট হুক — কমিট তৈরি করার আগে স্বয়ংক্রিয় পরীক্ষা, লিন্টার এবং ফর্ম্যাটার সহ
• স্থানীয় বিল্ড — পুশ করার আগে কম্পাইলেশন চালানো, বিশেষ করে স্ট্যাটিক্যালি টাইপ করা ভাষাগুলির জন্য
• ইউনিট পরীক্ষা — প্রাথমিক রিগ্রেশন সনাক্তকরণের জন্য পরীক্ষা দিয়ে মূল মডিউলগুলি কভার করা
• কোড পর্যালোচনা — প্রধান শাখায় মার্জ করার আগে একজন সহকর্মী দ্বারা পরিবর্তনগুলি পর্যালোচনা

দ্বিতীয় স্তর হল CI/CD পাইপলাইন কনফিগারেশন। প্রতিটি পুল রিকোয়েস্টকে মার্জ করার আগে স্বয়ংক্রিয় বিল্ড এবং পরীক্ষা পাস করতে হবে। যদি বিল্ড ব্যর্থ হয়, তবে PR ঠিক না হওয়া পর্যন্ত ব্লক থাকে। এই পদ্ধতিকে গেটেড কমিট বলা হয় এবং বেশিরভাগ আধুনিক প্রকল্পে ব্যবহৃত হয়।

তৃতীয় স্তর হল মনিটরিং এবং পরিসংখ্যান। টিমগুলি MTTR (মিন টাইম টু রিপেয়ার) মেট্রিক ট্র্যাক করে। এই সূচক যত কম, টিম তত দ্রুত ভাঙা বিল্ডে সাড়া দেয়। লক্ষ্য মান 30 মিনিটের বেশি নয়।

বিল্ড ভাঙলে কী করবেন

যখন বিল্ড ভেঙে যায়, প্রথম পদক্ষেপ হল শনাক্ত করা কোন ডেভেলপার শেষ পরিবর্তনগুলি করেছিলেন। Git টুল git bisect সরবরাহ করে, যা বাইনারি অনুসন্ধানের মাধ্যমে বিল্ড ভাঙা কমিট খুঁজে পেতে দেয়।

# জানা ভাল এবং খারাপ কমিট দিয়ে bisect শুরু করুন
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Git মাঝখানে একটি কমিট চেক করে
# বিল্ড করুন এবং পরীক্ষা করুন, তারপর চিহ্নিত করুন:
git bisect good  # if build passes
git bisect bad   # if build fails

# ~log2(n) ধাপের পর, git অপরাধী দেখায়
git bisect reset

সমস্যাযুক্ত কমিট খুঁজে পাওয়ার পর, পদক্ষেপের দুটি সম্ভাব্য পদ্ধতি রয়েছে। প্রথমটি হল git revert ব্যবহার করে পরিবর্তনগুলি প্রত্যাহার করা যদি সমাধানের সময় লাগে। এটি সবচেয়ে নিরাপদ পদ্ধতি, বিশেষ করে যখন বিল্ড পুরো টিমকে ব্লক করে।

দ্বিতীয় বিকল্প হল একটি নতুন কমিটের সাথে তাৎক্ষণিক ফিক্স। এই পদ্ধতিটি ভাল যদি সমস্যাটি স্থানীয় এবং পরিষ্কার হয়। ফিক্সের পরে, পরিবর্তনগুলি পুশ করুন এবং নিশ্চিত করুন যে বিল্ড সফল হয়েছে। যেকোনো ক্ষেত্রে, বিল্ড পুনরুদ্ধারের সময় এক ঘন্টার বেশি হওয়া উচিত নয়।