2.10 সফটওয়্যার কনফিগারেশন ব্যবস্থাপনা

পরিচিতি ও প্রেরণা

সফটওয়্যার কনফিগারেশন ব্যবস্থাপনা (SCM) হলো একটি সফটওয়্যার সিস্টেমের উপাদান শনাক্ত করা, কীভাবে তারা বদলায় তা নিয়ন্ত্রণ করা, প্রতিটি পরিবর্তনের অবস্থা লিপিবদ্ধ করা এবং যাচাই করার শৃঙ্খলা যে আপনি যা গড়েছেন ও সরবরাহ করেছেন তা আপনার অভিপ্রায়ের সঙ্গে মেলে। এটি এমন প্রশ্নের উত্তর দেয় যা শুনতে সরল কিন্তু বড় পরিসরে কঠিন হয়: এই রিলিজে ঠিক কী আছে, তা সেখানে কীভাবে এল, এবং কে অনুমোদন করেছেন? SWEBOK SCM-কে মৌলিক জ্ঞান-ক্ষেত্র হিসেবে দেখে একটি স্পষ্ট কারণে: প্রতিটি অন্য প্রকৌশল কার্যকলাপের বিপরীতে কাজ করার জন্য একটি স্থিতিশীল, জানা কনফিগারেশন দরকার।

বড় দলে SCM হলো সেই সংযোগী কলা, যা হাজারো চলমান অংশকে সুসংহত রাখে। সোর্স কোড, লাইব্রেরি, কনটেইনার ইমেজ, অবকাঠামো সংজ্ঞা, কনফিগারেশন ডেটা, ডকুমেন্টেশন ও টেস্ট সামগ্রী সবই নিজস্ব ঘড়িতে বদলায়, আর একটি সরবরাহ করা সিস্টেম হলো সেগুলোর নির্দিষ্ট সংস্করণের একটি নির্দিষ্ট সংমিশ্রণ। সুচিন্তিত কনফিগারেশন ব্যবস্থাপনা ছাড়া সেই সংমিশ্রণ অজানা এবং পুনরুৎপাদন করা যায় না। আপনি একটি অতীতের রিলিজ পুনর্গঠন করতে পারেন না, কোনো ত্রুটিকে তা ঘটানো পরিবর্তনে অনুসরণ করতে পারেন না, বা প্রোডাকশনে কী চলছে তা আত্মবিশ্বাসের সঙ্গে বলতে পারেন না।

এন্টারপ্রাইজ ও সরকারি পরিবেশ ঝুঁকি বাড়ায়। নিয়ন্ত্রিত ও সরকারি-খাতের কর্মসূচিকে দেখাতে হয় পরিবর্তন অনুমোদিত, পর্যালোচিত ও লিপিবদ্ধ ছিল; একটি সরবরাহ করা বিল্ড অনুমোদিত প্রয়োজনীয়তা ও সোর্সে অনুসরণযোগ্য; এবং অনিয়ন্ত্রিতভাবে কিছুই সিস্টেমে ঢোকেনি। এখানে SCM প্রকৌশল ব্যবস্থার মতোই প্রমাণ ব্যবস্থা। ভার্সন কন্ট্রোল (অধ্যায় 2.6) সোর্স ইতিহাস পরিচালনা করে; SCM পুরো কনফিগারেশন এবং যে নিয়ন্ত্রিত প্রক্রিয়ায় তা বদলায় তা নিয়ন্ত্রণ করে। এটি অবকাঠামো-অ্যাজ-কোড (অধ্যায় 8.2), সরবরাহ পাইপলাইন (অধ্যায় 8.1) এবং অডিট ও নিশ্চয়তার (অধ্যায় 10.2) সঙ্গে ঘনিষ্ঠভাবে যুক্ত।

মূল নীতিসমূহ

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

সুপারিশ

SCM প্রক্রিয়া সংজ্ঞায়িত করুন এবং মালিকানা বরাদ্দ করুন

একটি SCM পরিকল্পনা লিখুন যা বলে কনফিগারেশন নিয়ন্ত্রণের অধীনে কী আছে, আইটেম কীভাবে শনাক্ত হয়, পরিবর্তন কীভাবে প্রস্তাবিত ও অনুমোদিত হয়, এবং অবস্থা কীভাবে লিপিবদ্ধ ও নিরীক্ষিত হয়। স্পষ্ট মালিকানা বরাদ্দ করুন, যেমন একজন কনফিগারেশন ম্যানেজার বা জবাবদিহিযোগ্য দল, যাতে SCM সবার কাজ এবং তাই কারও নয় না হয়। প্রক্রিয়া ঝুঁকির সঙ্গে মেলান: একটি ছোট অভ্যন্তরীণ টুলে হালকা নিয়ন্ত্রণ দরকার, আর একটি নিরাপত্তা-সংকটপূর্ণ বা নিয়ন্ত্রিত সিস্টেমে আনুষ্ঠানিক বোর্ড ও নথি লাগে। পরিকল্পনাটি IEEE 828-এর মতো স্বীকৃত মানে নোঙর করুন, যাতে নিরীক্ষক ও অংশীদাররা তা অনুসরণ করতে পারেন।

কনফিগারেশন আইটেম শনাক্ত করুন এবং ভিত্তিরেখা প্রতিষ্ঠা করুন

সিস্টেমের আচরণ নির্ধারণকারী কনফিগারেশন আইটেম তালিকাভুক্ত করুন: সোর্স, নির্ভরতা, বিল্ড স্ক্রিপ্ট, কনটেইনার ইমেজ, অবকাঠামো সংজ্ঞা, কনফিগারেশন ডেটা, স্কিমা এবং মূল নথি। প্রতিটিকে একটি স্থিতিশীল শনাক্তকারী ও ভার্সনিং পরিকল্পনা দিন। অর্থপূর্ণ বিন্দুতে ভিত্তিরেখা ঠিক করুন (একটি রিলিজ করা সংস্করণ, একটি অনুমোদিত প্রয়োজনীয়তার সেট, একটি সনদপ্রাপ্ত বিল্ড), যাতে বদলানোর ও ফিরে যাওয়ার একটি সম্মত রেফারেন্স থাকে। ভিত্তিরেখা অপরিবর্তনীয়: একবার ঘোষণা করলে আপনি তা সম্পাদনা করেন না। কেবল পরিবর্তন প্রক্রিয়ার মাধ্যমে তৈরি নতুন ভিত্তিরেখা দিয়ে তা প্রতিস্থাপন করেন।

সংজ্ঞায়িত প্রক্রিয়া ও উপযুক্ত বোর্ডের মাধ্যমে পরিবর্তন নিয়ন্ত্রণ করুন

নিয়ন্ত্রিত আইটেমের পরিবর্তন একটি সংজ্ঞায়িত পথে পাঠান: প্রস্তাব, প্রভাব মূল্যায়ন, অনুমোদন, বাস্তবায়ন ও যাচাই। উচ্চ-ঝুঁকির আইটেমের জন্য একটি পরিবর্তন নিয়ন্ত্রণ বোর্ড (CCB) ব্যবহার করুন, যা একটি পরিবর্তন অনুমোদনের আগে খরচ, ঝুঁকি ও সময়সূচি ওজন করে। বোর্ডের আকার ঠিক করুন: রুটিন কোড পরিবর্তনের জন্য একটি হালকা স্বয়ংক্রিয় গেট, আর ভিত্তিরেখা, ইন্টারফেস বা নিয়ন্ত্রিত আচরণ ছোঁয়া পরিবর্তনের জন্য একটি আনুষ্ঠানিক আন্তঃ-কার্যক্ষেত্র CCB। প্রতিটি সিদ্ধান্ত ও তার পেছনের যুক্তি লিপিবদ্ধ করুন, এবং গুরুত্বপূর্ণ কনফিগারেশন সিদ্ধান্ত সিদ্ধান্তের নথির (অধ্যায় 1.6) সঙ্গে যুক্ত করুন যাতে যুক্তি টিকে থাকে।

কনফিগারেশন অবস্থা হিসাব রক্ষণাবেক্ষণ করুন

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

কনফিগারেশন অডিট পরিচালনা করুন

নির্দিষ্ট সূচিতে দুটি জিনিস যাচাই করুন। একটি কার্যকরী কনফিগারেশন অডিট নিশ্চিত করে কনফিগারেশন তার প্রয়োজনীয়তা যেভাবে নির্দিষ্ট করে সেভাবে কাজ করে। একটি ভৌত কনফিগারেশন অডিট নিশ্চিত করে সরবরাহ করা সামগ্রী লিপিবদ্ধ কনফিগারেশনের সঙ্গে মেলে: বিল্ড লিপিবদ্ধ সোর্স ও নির্ভরতা থেকে এসেছে এবং এতে অহিসাবি কিছু নেই। যতটা পারেন স্বয়ংক্রিয় করুন: পুনরুৎপাদনযোগ্য বিল্ড, সামগ্রীর চেকসাম, সফটওয়্যার বিল অফ ম্যাটেরিয়ালস (SBOM) ও উৎস প্রত্যয়ন অডিটকে হাতে-করা পরিদর্শন থেকে নিরন্তর পরীক্ষায় রূপ দেয়।

রিলিজ ও সরবরাহকে নিয়ন্ত্রিত ঘটনা হিসেবে পরিচালনা করুন

রিলিজকে একটি পুনরাবৃত্তিযোগ্য প্রক্রিয়ায় সরবরাহ করা নির্দিষ্ট, শনাক্তকৃত ভিত্তিরেখা হিসেবে দেখুন। আপনার রিলিজ সুস্পষ্টভাবে ভার্সন করুন, ঠিক কী অন্তর্ভুক্ত তা বর্ণনা করা একটি ম্যানিফেস্ট বা বিল অফ ম্যাটেরিয়ালস তৈরি করুন, এবং রিলিজ থেকে সোর্স সংশোধন থেকে ডিপ্লয় করা সামগ্রীতে ম্যাপিং লিপিবদ্ধ করুন। রিলিজ করা সামগ্রী স্বাক্ষর ও চেকসাম করুন, যাতে পরবর্তী যে কেউ তার অখণ্ডতা যাচাই করতে পারেন। রিলিজ ব্যবস্থাপনা সরবরাহ পাইপলাইনের (অধ্যায় 8.1) সঙ্গে বাঁধুন, যাতে পরিবেশগুলোর মধ্য দিয়ে উন্নীত হওয়া নিজেই নিয়ন্ত্রিত, লিপিবদ্ধ ও ফেরানো-যায় হয়।

SCM টুলিং বেছে নিন ও একীভূত করুন

কেবল শৃঙ্খলার ওপর ভরসা না করে শনাক্তকরণ, নিয়ন্ত্রণ, হিসাব ও অডিট স্বয়ংক্রিয় করা টুলের ওপর ঝুঁকুন: সোর্সের জন্য ভার্সন কন্ট্রোল, বাইনারির জন্য সামগ্রী ও ইমেজ রেজিস্ট্রি, বিল্ডের জন্য অপরিবর্তনীয় পাইপলাইন, পরিবেশের জন্য অবকাঠামো-অ্যাজ-কোড, এবং উৎসের জন্য নির্ভরতা ও SBOM টুলিং। এগুলো এমনভাবে যুক্ত করুন যাতে একটি একক পরিবর্তন কমিট থেকে ডিপ্লয় করা রিলিজ পর্যন্ত অনুসরণযোগ্যভাবে প্রবাহিত হয়। আপনি যা চান তা হলো এমন টুলচেইন, যেখানে কনফিগারেশন নথি কাজ করার উপজাত, আলাদা করণিকের কাজ নয়।

ট্রেড-অফ: সুবিধা ও অসুবিধা

পছন্দ	সুবিধা	অসুবিধা
আনুষ্ঠানিক পরিবর্তন নিয়ন্ত্রণ বোর্ড	শক্ত অনুমোদন ও অডিট ট্রেইল; পরিবর্তনের আগে ঝুঁকি ওজন করা	ধীর থ্রুপুট; রুটিন পরিবর্তনে প্রয়োগ করলে বাড়তি বোঝা
হালকা স্বয়ংক্রিয় গেট	দ্রুত প্রবাহ; কম বাড়তি বোঝা; বহু পরিবর্তনে বড় হয়	উচ্চ-ঝুঁকির ভিত্তিরেখার জন্য দুর্বল; কম বিবেচনা
কঠোর অপরিবর্তনীয় ভিত্তিরেখা	পুনরুৎপাদনযোগ্য, নিরীক্ষণযোগ্য রেফারেন্স বিন্দু	শৃঙ্খলা ও টুলিং লাগে; অতিব্যবহারে ঘর্ষণ
স্বয়ংক্রিয় অবস্থা হিসাব	নির্ভুল, সদা-হালনাগাদ নথি; অডিট-প্রস্তুত	অগ্রিম টুলিং ও ইন্টিগ্রেশন বিনিয়োগ
হাতে-করা কনফিগারেশন নথি	শুরু করা সরল; টুলিং লাগে না	বাস্তবতা থেকে সরে যায়; বড় পরিসরে ও অডিটে ব্যর্থ

কেন্দ্রীয় ট্রেড-অফ নিয়ন্ত্রণ বনাম প্রবাহ। ভারী পরিবর্তন নিয়ন্ত্রণ শক্ত নিশ্চয়তা দেয় কিন্তু সরবরাহ ধীর করে। হালকা নিয়ন্ত্রণ দ্রুত প্রবাহিত হয় কিন্তু অনুসরণযোগ্যতা দুর্বল করে। উত্তর বৈশ্বিকভাবে একটি বাছা নয়; তা হলো ঝুঁকি অনুযায়ী নিয়ন্ত্রণ স্তরবদ্ধ করা: রুটিন পরিবর্তন দ্রুত গেটের মাধ্যমে স্বয়ংক্রিয় করুন, এবং আনুষ্ঠানিক বোর্ড ও অপরিবর্তনীয় ভিত্তিরেখা রাখুন সেই আইটেমের জন্য, যেখানে অনুমোদন ও নিরীক্ষণযোগ্যতা সত্যিই গুরুত্বপূর্ণ। দ্বিতীয় ট্রেড-অফ অগ্রিম টুলিং বিনিয়োগ বনাম চলমান করণিকের খরচ ও অডিট ঝুঁকি। স্বয়ংক্রিয় হিসাব সেট করতে বেশি খরচ হয়, কিন্তু চালাতে অনেক কম।

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

1. আমাদের কনফিগারেশন-আইটেম তালিকায় ঠিক কী থাকা উচিত, এবং নতুন কিছু দেখা দিলে সিদ্ধান্তের মালিক কে? SCM কাজ করে কেবল তখনই যখন নিয়ন্ত্রিত আইটেমের তালিকা আসলে আচরণ নির্ধারণকারী জিনিসের সেটের সঙ্গে মেলে, আর বড় সিস্টেমে সেই সেট বেশিরভাগ দল যা ভাবে তার চেয়ে বড়: সোর্স, নির্ভরতা, বিল্ড স্ক্রিপ্ট, কনটেইনার ইমেজ, অবকাঠামো সংজ্ঞা, স্কিমা, ফিচার ফ্ল্যাগ এবং কনফিগারেশন ডেটা যা নিঃশব্দে সফটওয়্যার কী করে তা বদলায়। কেউ তালিকার মালিক না হলে তা সেকেলে হয়, এবং প্রোডাকশনে আপনাকে নামিয়ে দেওয়া আইটেমটি সেটিই হয় যা নিয়ন্ত্রণ করার কথা কেউ ভাবেনি। সভায় আপনার বর্তমান তালিকা আনুন এবং তাতে অনুপস্থিত আচরণ-নির্ধারক আইটেম খুঁজুন। একজন জবাবদিহিযোগ্য মালিক (একজন কনফিগারেশন ম্যানেজার বা নামধারী দল) নিযুক্ত করুন, যাতে নতুন আইটেম যোগ আকস্মিক নয়, সুচিন্তিত সিদ্ধান্ত হয়, কারণ যে SCM সবার কাজ তা কারও কাজ নয়।

2. আমরা কি প্রমাণ করতে পারি যে একটি ডিপ্লয় করা সামগ্রী আমরা যে সোর্স ও পাইপলাইন ভাবি সেখান থেকে এসেছে, এবং সেই প্রমাণ কি কারসাজিতে টিকত? পুনরুৎপাদনযোগ্যতা ও অনুসরণযোগ্যতাই SCM-এর পুরো উদ্দেশ্য, এবং প্রশ্নটির তীক্ষ্ণ রূপ হলো আপনি কি চলমান বাইনারিকে একটি নির্দিষ্ট কমিট ও বিল্ড রানের সঙ্গে দাবি নয়, প্রমাণসহ যুক্ত করতে পারেন কি না। নিয়ন্ত্রিত বা উচ্চ-মূল্যের সিস্টেমে এটি আপনার সাপ্লাই-চেইন প্রতিরক্ষাও: স্বাক্ষরিত উৎস প্রত্যয়ন, সামগ্রীর চেকসাম এবং সফটওয়্যার বিল অফ ম্যাটেরিয়ালস “আমরা মোটামুটি নিশ্চিত”-কে এমন কিছুতে পরিণত করে যা একজন নিরীক্ষক বা ঘটনা-প্রতিক্রিয়াকারী যাচাই করতে পারেন। আপনার শেষ রিলিজ আনুন এবং ডিপ্লয় করা সামগ্রী থেকে অনুমোদিত পরিবর্তন পর্যন্ত পিছিয়ে হাঁটার চেষ্টা করুন। কোনো ধাপ লিপিবদ্ধ, যাচাইযোগ্য সংযোগের বদলে হাতে-করা দাবি হলে সেটিই সেই জায়গা যেখানে আক্রমণকারী বা সৎ ভুল অলক্ষ্যে কিছু ঢুকিয়ে দিতে পারে, আর তা বন্ধ করার অর্থ পাইপলাইনে স্বাক্ষর ও উৎস জুড়ে দেওয়া, যাতে নথি সরবরাহের উপজাত হয়।

3. আজ কি কেউ একটি রিলিজ জায়গায় বসেই সম্পাদনা করতে পারেন, এবং তা আমাদের তাকে বিশ্বাস করার সামর্থ্যে কী করবে? একটি ভিত্তিরেখা কেবল অপরিবর্তনীয় হলেই কাজের: যে মুহূর্তে “রিলিজ” ঘটনার পরে সম্পাদনাযোগ্য হয়, আপনি আর তা পুনরুৎপাদন বা রেফারেন্স হিসেবে ভরসা করতে পারেন না, এবং প্রতিটি পরবর্তী অডিট প্রত্নতত্ত্বে পরিণত হয়। ক্লাসিক ব্যর্থতা হলো প্রোডাকশনে সরাসরি সম্পাদনা করা কনফিগ বা নিঃশব্দে সরানো ট্যাগ, যা ঠিক সেই শর্টকাট যা নির্দোষ মনে হয় এবং পরে রিলিজ পুনর্গঠন অসম্ভব করে। সভায় সৎ উত্তর আনুন: পরিবর্তন প্রক্রিয়া ছাড়া ডিপ্লয় করা ভিত্তিরেখা বদলানোর প্রবেশাধিকার কার আছে, এবং তা কি ঘটেছে? সমাধান হলো ভিত্তিরেখাকে সত্যিকারের অপরিবর্তনীয় করা এবং প্রতিটি পরিবর্তন প্রস্তাব, প্রভাব মূল্যায়ন, অনুমোদন ও যাচাইয়ের মধ্য দিয়ে পাঠানো, কঠোরতা স্তরবদ্ধ করে যাতে রুটিন পরিবর্তন দ্রুত স্বয়ংক্রিয় গেটের মাধ্যমে প্রবাহিত হয় আর ভিত্তিরেখা ও নিয়ন্ত্রিত পরিবর্তন বোর্ডে যায়।

4. আমাদের কনফিগারেশন অবস্থা হিসাব কি আমাদের নথি-টুল থেকে স্বয়ংক্রিয়ভাবে তৈরি, নাকি হাতে রক্ষণাবেক্ষিত, এবং আসলে যা ডিপ্লয় হয়েছে তা থেকে তা কতটা সরে গেছে? অবস্থা হিসাব হলো সেই নথি যা আপনাকে যেকোনো মুহূর্তে উত্তর দিতে দেয় একটি রিলিজে কী আছে এবং তা কীভাবে সেখানে এসেছে, আর বড় সিস্টেমে সেই নথি বিশ্বাসযোগ্য কেবল তখনই যখন তা সমান্তরাল স্প্রেডশিটে টাইপ না হয়ে কাজ থেকে ঝরে পড়ে। বিপরীত টান হলো হাতে-রাখা রেজিস্টার শুরুতে সস্তা ও নমনীয় মনে হয়, আর তা স্বয়ংক্রিয় করার অর্থ ভার্সন কন্ট্রোল, পাইপলাইন ও সামগ্রী রেজিস্ট্রি যুক্ত করা যাতে নথি সরবরাহের উপজাত হয়। আপনি আজ যার ওপর নির্ভর করেন সেই রেজিস্টার আনুন, এলোমেলোভাবে তিনটি সাম্প্রতিক রিলিজ বাছুন, এবং যাচাই করুন লিপিবদ্ধ সংস্করণ, ভিত্তিরেখা ও প্রযুক্ত পরিবর্তন অনুরোধ টুলিং যা পাঠিয়েছে বলে তার সঙ্গে মেলে কি না। একটি এন্টারপ্রাইজ বা সরকারি কর্মসূচির জন্য বাস্তবতা থেকে ভিন্ন অবস্থা নথি গোছানোর সমস্যা নয়, ঘটার অপেক্ষায় থাকা অডিট পর্যবেক্ষণ, কারণ একটি ফাঁক ধরা নিরীক্ষক পুরো বিবরণে বিশ্বাস হারান এবং আপনাকে হাতে পুনর্গঠন করতে বলেন।

5. আমাদের পরিবর্তন নিয়ন্ত্রণ কি ঝুঁকি অনুযায়ী স্তরবদ্ধ, নাকি প্রতিটি পরিবর্তন কী ছুঁয়েছে নির্বিশেষে একই মাত্রার আনুষ্ঠানিকতা চলে? নিয়ন্ত্রণ ও প্রবাহ পরস্পরের বিপরীতে টানে: একটি আনুষ্ঠানিক পরিবর্তন নিয়ন্ত্রণ বোর্ড একটি পরিবর্তন অনুমোদনের আগে খরচ, ঝুঁকি ও সময়সূচি ওজন করে, কিন্তু রুটিন কোড বদলে সেই আনুষ্ঠানিকতা প্রয়োগ কেবল বিলম্ব যোগ করে, আর একটি ভাগ করা ভিত্তিরেখা বা নিয়ন্ত্রিত পেমেন্ট প্রবাহ দ্রুত স্বয়ংক্রিয় গেটে ঠেলে দেওয়া ঠিক যেখানে দরকার সেখানে বিবেচনা সরিয়ে দেয়। ব্যর্থতার ধরন প্রতিসম, অভিন্ন ভারীতা যা মানুষ এড়াতে শেখে, অথবা অভিন্ন শিথিলতা যা একটি উচ্চ-ঝুঁকির পরিবর্তন অপরীক্ষিত পার হতে দেয়। গত ত্রৈমাসিকের পরিবর্তনের একটি নমুনা আনুন প্রতিটি কী ছুঁয়েছে অনুযায়ী বাছা, এবং যাচাই করুন তা যে কঠোরতা পেয়েছে তা আসলে তার ঝুঁকির সঙ্গে মেলে কি না। নিয়ন্ত্রিত বা সরকারি-খাতের পরিবেশে নাম দিন কোন আইটেম শ্রেণিকে আন্তঃ-কার্যক্ষেত্র বোর্ডে পৌঁছাতে হবে এবং কোনগুলো স্বয়ংক্রিয় গেটে প্রবাহিত হতে পারে, এবং এই স্তরবিন্যাস সুস্পষ্টভাবে লিপিবদ্ধ করুন, কারণ “আমরা বিচারবুদ্ধি ব্যবহার করি” এমন নিয়ন্ত্রণ যা নিরীক্ষক বা তদারকি সংস্থা যাচাই করতে পারে না।

6. আমরা শেষ কবে একটি কার্যকরী ও একটি ভৌত কনফিগারেশন অডিট চালিয়েছি, এবং প্রমাণের কতটা পুনর্গঠনের বদলে জীবন্ত নথি হবে? একটি কার্যকরী কনফিগারেশন অডিট নিশ্চিত করে সিস্টেম তার প্রয়োজনীয়তা যেভাবে নির্দিষ্ট করে সেভাবে কাজ করে, আর একটি ভৌত কনফিগারেশন অডিট নিশ্চিত করে সরবরাহ করা সামগ্রী লিপিবদ্ধ কনফিগারেশনের সঙ্গে মেলে এবং এতে অহিসাবি কিছু নেই; এগুলো এড়ালে আপনি কখনো পরীক্ষা না করেই বিশ্বাস করছেন যে আপনার ভিত্তিরেখা ও অবস্থা হিসাব সৎ। টানাপোড়েন খরচ: হাতে-করা অডিট ধীর ও যন্ত্রণাদায়ক, আর ঠিক সেজন্যই দলগুলো তা পিছিয়ে দেয়, এবং বেরোনোর পথ হলো পুনরুৎপাদনযোগ্য বিল্ড, সামগ্রীর চেকসাম, সফটওয়্যার বিল অফ ম্যাটেরিয়ালস ও উৎস প্রত্যয়ন দিয়ে পরীক্ষা স্বয়ংক্রিয় করা, যাতে যাচাই নিরন্তর হয়। আপনার সাম্প্রতিকতম রিলিজ আনুন এবং ঘটনাস্থলেই প্রয়োজনীয়তা-থেকে-পরিবর্তন-থেকে-বিল্ড-থেকে-ডিপ্লয়মেন্ট অনুসরণ ও সামগ্রী-থেকে-সোর্স প্রমাণ তৈরির চেষ্টা করুন। এন্টারপ্রাইজ ও সরকারি কর্মসূচির জন্য এই প্রমাণ ট্রেইলই সনদ ও তদারকি দাবি করে, তাই সৎ প্রশ্ন হলো আগামীকালের অডিটের উত্তর আপনার ইতিমধ্যে থাকা নথি থেকে আসবে, নাকি এমন প্রত্নতত্ত্বের অনুশীলন থেকে যা আপনি বহন করতে পারেন না।

খাতভেদে দৃষ্টিভঙ্গি

স্টার্টআপ। SCM হালকা কিন্তু প্রকৃত রাখুন। সোর্স, অবকাঠামো সংজ্ঞা ও কনফিগ ডেটা ভার্সন কন্ট্রোলে রাখুন, এবং প্রতিটি রিলিজকে হাতে-জোড়া সামগ্রীর বদলে একটি পাইপলাইনে তৈরি ট্যাগযুক্ত বিল্ড করুন। কনফিগারেশন ম্যানেজমেন্ট বোর্ড ও আনুষ্ঠানিক ভিত্তিরেখা এড়িয়ে যান, যা আপনার আকারে অতিরিক্ত, কিন্তু কাউকে প্রোডাকশনে সরাসরি কনফিগ সম্পাদনা করতে দেবেন না, কারণ পরের মঙ্গলবার কোনো গ্রাহক ত্রুটিতে পড়লে ওই একটি শর্টকাটই রিলিজ পুনরুৎপাদন অসম্ভব করে।

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

এন্টারপ্রাইজ। সমস্যা বহু দল জুড়ে সামঞ্জস্য: একটি ভাগ করা SCM পরিকল্পনা, একটি সাধারণ কনফিগারেশন-আইটেম শ্রেণিবিন্যাস, স্তরবদ্ধ পরিবর্তন নিয়ন্ত্রণ, এবং ভার্সন কন্ট্রোল, সামগ্রী রেজিস্ট্রি ও পাইপলাইন থেকে স্বয়ংক্রিয়ভাবে তৈরি অবস্থা হিসাব। আনুষ্ঠানিক পরিবর্তন নিয়ন্ত্রণ বোর্ড ও অপরিবর্তনীয় ভিত্তিরেখা রাখুন ভাগ করা প্ল্যাটফর্ম ও নিয়ন্ত্রিত প্রবাহের জন্য, রুটিন পরিবর্তন স্বয়ংক্রিয় গেটে প্রবাহিত হতে দিন, এবং স্বাক্ষরিত উৎস ও SBOM প্রমিত করুন, যাতে যেকোনো দলের রিলিজ অনুসরণ করা যায় এবং যেকোনো নিরীক্ষক পুনর্গঠন কমিশন করার বদলে জীবন্ত নথি অনুসন্ধান করতে পারেন।

সরকার। ক্রয়-বিধি, স্বচ্ছতা ও জনগণের কাছে জবাবদিহি প্রক্রিয়াকে আকার দেয়। IEEE 828-এর মতো স্বীকৃত মানের সঙ্গে সারিবদ্ধ একটি আনুষ্ঠানিক SCM পরিকল্পনা অনুসরণ করুন, চুক্তিগত মাইলফলকে কনফিগারেশন আইটেমের ভিত্তিরেখা ঠিক করুন, এবং একটি নিয়ন্ত্রিত ভিত্তিরেখায় প্রতিটি পরিবর্তন এমন বোর্ডের মাধ্যমে পাঠান যা প্রভাব, সিদ্ধান্ত ও যুক্তি লিপিবদ্ধ করে। দাবি করুন যে সরবরাহ করা সামগ্রী নিয়ন্ত্রিত ইনপুট থেকে পুনরুৎপাদনযোগ্য, চেকসাম-করা এবং অনুমোদিত প্রয়োজনীয়তা থেকে সরবরাহ করা বিল্ড পর্যন্ত প্রান্ত থেকে প্রান্তে অনুসরণযোগ্য, কারণ সেই নথিবদ্ধ প্রমাণ ট্রেইলই সনদ, অডিট ও জনগণের তদারকি দাবি করে।

উদাহরণ

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

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

সরকার। একটি প্রতিরক্ষা কর্মসূচি IEEE 828-এর সঙ্গে সারিবদ্ধ একটি আনুষ্ঠানিক SCM পরিকল্পনা অনুসরণ করে। কনফিগারেশন আইটেম তালিকাভুক্ত ও চুক্তিগত মাইলফলকে ভিত্তিরেখা করা হয়, এবং একটি পরিবর্তন নিয়ন্ত্রণ বোর্ড একটি নিয়ন্ত্রিত ভিত্তিরেখার প্রতিটি পরিবর্তন অনুমোদন করে, প্রভাব, সিদ্ধান্ত ও যুক্তি লিপিবদ্ধ করে। কার্যকরী কনফিগারেশন অডিট নিশ্চিত করে সরবরাহ করা সিস্টেম নির্দিষ্ট প্রয়োজনীয়তা পূরণ করে, আর ভৌত কনফিগারেশন অডিট নিশ্চিত করে সরবরাহ করা সামগ্রী লিপিবদ্ধ কনফিগারেশনের সঙ্গে ঠিক মেলে। রিলিজ নিয়ন্ত্রিত ইনপুট থেকে পুনরুৎপাদনযোগ্য, চেকসাম-করা এবং প্রান্ত থেকে প্রান্তে অনুসরণযোগ্য, অনুমোদিত প্রয়োজনীয়তা থেকে পরিবর্তন অনুরোধ হয়ে সরবরাহ করা বিল্ড পর্যন্ত, ঠিক সেই প্রমাণ ট্রেইল যা সনদ ও তদারকি দাবি করে।

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

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

মালিকানার মোট খরচ স্বয়ংক্রিয়করণের পক্ষে। হাতে-করা কনফিগারেশন নথি শুরু করতে সস্তা এবং রক্ষণাবেক্ষণে ক্রমশ ব্যয়বহুল, আর যখন সবচেয়ে বেশি দরকার তখনই তা ব্যর্থ হয়, ঘটনা বা অডিটের সময়, কারণ তা বাস্তবতা থেকে সরে গেছে। স্বয়ংক্রিয় শনাক্তকরণ, হিসাব ও অডিট অগ্রিম বেশি খরচ করে কিন্তু কনফিগারেশন নথিকে সরবরাহ পাইপলাইনের প্রায়-বিনামূল্যের উপজাতে পরিণত করে। নেতৃত্বের কাছে যুক্তি দিতে SCM-কে সেই নিয়ন্ত্রণ হিসেবে উপস্থাপন করুন যা রিলিজ পুনরুৎপাদনযোগ্য ও পরিবর্তন নিরীক্ষণযোগ্য করে, এবং অপুনরুৎপাদনযোগ্য রিলিজ, দীর্ঘায়িত অডিট ও অনিয়ন্ত্রিত পরিবর্তনের বিধি-মান্যতার ঝুঁকির খরচের বিপরীতে ওজন করুন।

অ্যান্টি-প্যাটার্ন ও ফাঁদ

• গোষ্ঠীগত জ্ঞানে কনফিগারেশন: একটি রিলিজের প্রকৃত বিষয়বস্তু কেবল ইঞ্জিনিয়ারের মাথায়, কোনো নথিতে নয়।
• পরিবর্তনযোগ্য ভিত্তিরেখা: “রিলিজ” জায়গায় বসেই সম্পাদিত, তাই আর পুনরুৎপাদন বা রেফারেন্স হিসেবে বিশ্বাসযোগ্য নয়।
• অনিয়ন্ত্রিত কনফিগারেশন ডেটা: কোড ভার্সন-নিয়ন্ত্রিত কিন্তু আচরণ বদলানো কনফিগ প্রোডাকশনে তাৎক্ষণিকভাবে সম্পাদিত।
• পরিবর্তন নিয়ন্ত্রণের থিয়েটার: সবকিছুতে সিলমোহর দেওয়া বোর্ড, প্রকৃত নিরীক্ষণ ছাড়াই বিলম্ব যোগ করে।
• হাতে-করা অবস্থা হিসাব: সংস্করণের স্প্রেডশিট, যা আসলে ডিপ্লয় করা জিনিস থেকে নিঃশব্দে সরে যায়।
• অপুনরুৎপাদনযোগ্য বিল্ড: নিয়ন্ত্রিত ইনপুট থেকে পুনর্নির্মাণ করা যায় না এমন রিলিজ, ফলে অডিট ও পুনর্নির্মাণ অনুমানে পরিণত হয়।
• অনুসরণ-অযোগ্য রিলিজ: ডিপ্লয় করা সামগ্রী থেকে সোর্স সংশোধন, পরিবর্তন অনুরোধ ও অনুমোদনে কোনো ম্যাপিং নেই।

পরিপক্বতা মডেল

• স্তর ১ (সূচনা): SCM তাৎক্ষণিক ও প্রতিক্রিয়াশীল। কেবল সোর্স নিয়ন্ত্রিত; রিলিজ হাতে জোড়া; কোনো ভিত্তিরেখা নেই, কী ডিপ্লয় আছে তার নির্ভরযোগ্য নথি নেই, এবং অতীতের বিল্ড পুনরুৎপাদনের উপায় নেই।
• স্তর ২ (বিকাশ): মৌলিক চর্চা আছে কিন্তু দল ভেদে ভিন্ন। কিছু সিস্টেম কনফিগারেশন আইটেম ও পরিবর্তন প্রক্রিয়া সংজ্ঞায়িত করে এবং রিলিজ ভার্সন করে, এখানে-সেখানে ভিত্তিরেখা আছে, কিন্তু নথি আংশিক হাতে-করা এবং নিয়ন্ত্রণের কঠোরতা প্রতিষ্ঠান জুড়ে অসঙ্গত।
• স্তর ৩ (মানসম্মতকরণ): চর্চা নথিবদ্ধ ও প্রতিষ্ঠানজুড়ে বলবৎ। একটি সাধারণ কনফিগারেশন-আইটেম শ্রেণিবিন্যাস, অপরিবর্তনীয় ভিত্তিরেখা, স্তরবদ্ধ পরিবর্তন নিয়ন্ত্রণ ও অবস্থা হিসাব প্রতিষ্ঠিত এবং বহুলাংশে স্বয়ংক্রিয়; রিলিজ পুনরুৎপাদনযোগ্য ও অনুসরণযোগ্য, এবং অডিট স্মৃতির বদলে টুলিং দিয়ে সমর্থিত।
• স্তর ৪ (ব্যবস্থাপনা): SCM তথ্য দিয়ে মাপা ও নিয়ন্ত্রিত। পুনরুৎপাদনযোগ্যতার হার, প্রয়োজনীয়তা থেকে ডিপ্লয় করা সামগ্রী পর্যন্ত অনুসরণযোগ্যতার আওতা, প্রতিটি নিয়ন্ত্রণ স্তরের মধ্য দিয়ে পরিবর্তনের লিড টাইম, কনফিগারেশন-বিচ্যুতির ঘটনা ও অডিট পর্যবেক্ষণ ভিত্তিরেখা ও লক্ষ্যের বিপরীতে অনুসরণ করা হয়। বিচ্যুতি সংশোধন ট্রিগার করে, এবং প্রতিটি যাওয়া বা না-যাওয়ার সিদ্ধান্ত দাবির বদলে এই প্রমাণের ওপর দাঁড়ায়।
• স্তর ৫ (সমন্বয়): SCM নিরন্তর উন্নত এবং প্রতিষ্ঠান জুড়ে একীভূত। পুনরুৎপাদনযোগ্য বিল্ড, SBOM, উৎস প্রত্যয়ন এবং জীবন্ত অবস্থা হিসাবসহ সম্পূর্ণ স্বয়ংক্রিয় ও নিরন্তর যাচাই করা, প্রক্রিয়া সরবরাহ, নিরাপত্তা ও অডিটে বোনা, এবং ঝুঁকি ও সরবরাহের ফলাফল সরলে খাপ খাইয়ে নেয়, প্রমাণের ভিত্তিতে নিয়ন্ত্রণ অবসান ও নতুন পরিসর করে।

আলোচনার ভাবনা

• আপনি কি আজ আপনার শেষ রিলিজ নিয়ন্ত্রিত ইনপুট থেকে হুবহু পুনরুৎপাদন করতে পারেন, এবং কত সময় লাগত?
• কোন কনফিগারেশন আইটেম আচরণ নির্ধারণ করে কিন্তু আসলে নিয়ন্ত্রণের অধীনে নেই, বিশেষত কনফিগারেশন ডেটা ও অবকাঠামো?
• আপনার পরিবর্তন নিয়ন্ত্রণ কি ঝুঁকি অনুযায়ী স্তরবদ্ধ, নাকি সর্বত্র অভিন্ন বাড়তি বোঝা বা অভিন্ন শিথিলতা যোগ করে?
• আপনার কনফিগারেশন নথি কোথায় থাকে, এবং আসলে ডিপ্লয় করা জিনিস থেকে তা কতটা সরে গেছে?
• আগামীকাল অডিটে আপনি কোন প্রমাণ তৈরি করতে পারতেন, এবং তার কতটা নথির বদলে পুনর্গঠন হতো?
• পুনরুৎপাদনযোগ্য বিল্ড, SBOM ও উৎস প্রত্যয়ন আপনার অডিট স্বয়ংক্রিয়ভাবে কী যাচাই করতে পারে তা কীভাবে বদলায়?

প্রধান শিক্ষা

• SCM পুরো কনফিগারেশন নিয়ন্ত্রণ করে (কোড, নির্ভরতা, অবকাঠামো ও কনফিগ ডেটা), কেবল সোর্স নয়।
• ভিত্তিরেখা অপরিবর্তনীয় রেফারেন্স বিন্দু; পরিবর্তন তাদের বিপরীতে অনুমোদিত ও লিপিবদ্ধ হয়, প্রতিরোধ করা হয় না।
• অবস্থা হিসাব আপনাকে যেকোনো মুহূর্তে উত্তর দিতে দেবে একটি রিলিজে কী আছে এবং তা কীভাবে সেখানে এসেছে।
• অডিট যাচাই করে যে গড়া ও সরবরাহ করা জিনিস লিপিবদ্ধ কনফিগারেশন ও অনুমোদিত প্রয়োজনীয়তার সঙ্গে মেলে।
• ঝুঁকি অনুযায়ী নিয়ন্ত্রণ স্তরবদ্ধ করুন এবং শনাক্তকরণ, হিসাব ও অডিট স্বয়ংক্রিয় করুন, যাতে নথি সরবরাহের উপজাত হয়।

তথ্যসূত্র ও আরও পড়ার জন্য

• IEEE Computer Society, SWEBOK Guide (Guide to the Software Engineering Body of Knowledge), সফটওয়্যার কনফিগারেশন ব্যবস্থাপনা জ্ঞান-ক্ষেত্র
• IEEE Std 828, Standard for Configuration Management in Systems and Software Engineering
• ISO/IEC/IEEE 12207, Systems and software engineering: Software life cycle processes (কনফিগারেশন ব্যবস্থাপনা প্রক্রিয়া)
• Jez Humble ও David Farley, Continuous Delivery
• Bob Aiello ও Leslie Sachs, Configuration Management Best Practices: Practical Methods that Work in the Real World
• সফটওয়্যার সাপ্লাই-চেইন নিরাপত্তা, সফটওয়্যার বিল অফ ম্যাটেরিয়ালস (SBOM) এবং সামগ্রী উৎস বিষয়ে NIST নির্দেশিকা
• বিল্ড উৎস ও প্রত্যয়নের জন্য CNCF ও উন্মুক্ত মান (রেফারেন্স কাঠামো হিসেবে)