কুবারনেটিস প্রজেক্ট সাম্প্রতিক তিনটি পর্যন্ত ছোট রিলিজের জন্য রিলিজ শাখা বজায় রাখে।
(1.31, 1.30, 1.29).
কুবারনেটিস 1.19 এবং নতুন ভার্সন
আনুমানিক 1 বছরের প্যাচ সাপোর্ট পায়(patch support)
কুবারনেটিস 1.18 এবং তার বেশি বয়সীরা প্রায় 9 মাস প্যাচ সাপোর্ট (patch support) পেয়েছে।
কুবারনেটিস সংস্করণ x.y.z হিসাবে প্রকাশ করা হয়,
যেখানে x হল মুখ্য সংস্করণ, y হল গৌণ সংস্করণ এবং z হল প্যাচ ভার্সন (patch version),
যা শব্দার্থিক সংস্করণ পরিভাষা অনুসরণ করে হয়।
কুবারনেটিস প্রতিটি উপাদানের জন্য বাইনারি পাঠায় সেইসাথে একটি ক্লাস্টারের সাথে বুটস্ট্র্যাপ বা
ইন্টারঅ্যাক্ট (interact) করার জন্য ক্লায়েন্ট অ্যাপ্লিকেশনগুলোর একটি আদর্শ সেটও পাঠায়। এপিআই
সার্ভারের মতো উপাদানগুলো একটি ক্লাস্টারের ভিতরে কন্টেইনার ইমেজগুলোর মধ্যে চলতে সক্ষম।
সেই উপাদানগুলো অফিসিয়াল রিলিজ প্রক্রিয়ার অংশ হিসাবে কন্টেইনার ইমেজেও পাঠানো হয়।
সমস্ত বাইনারি এবং সেইসাথে কন্টেইনার ইমেজ একাধিক অপারেটিং সিস্টেমের পাশাপাশি
একাধিক হার্ডওয়্যার আর্কিটেকচারের জন্য উপলব্ধ (available)।
আপনি অ্যাপ্লিকেশন স্থাপন(deploy) করতে, ক্লাস্টার রিসোর্স পরিদর্শন ও পরিচালনা করতে এবং লগ দেখতে kubectl
ব্যবহার করতে পারেন। kubectl অপারেশনগুলোর একটি সম্পূর্ণ তালিকা সহ আরও তথ্যের জন্য,
kubectl রেফারেন্স ডকুমেন্টেশন দেখুন।
kubectl বিভিন্ন লিনাক্স প্ল্যাটফর্ম, ম্যাকওস এবং উইন্ডোজে ইনস্টলযোগ্য।
নীচে আপনার পছন্দের অপারেটিং সিস্টেম খুঁজুন।
সমস্ত কুবারনেটিস কন্টেইনার ছবি registry.k8s.io
কন্টেইনার ইমেজ রেজিস্ট্রিতে স্থাপন করা হয় ।
কন্টেইনার ইমেজ
সাপোর্টেড আর্কিটেকচার
registry.k8s.io/kube-apiserver:v1.30.0
amd64, arm, arm64, ppc64le, s390x
registry.k8s.io/kube-controller-manager:v1.30.0
amd64, arm, arm64, ppc64le, s390x
registry.k8s.io/kube-proxy:v1.30.0
amd64, arm, arm64, ppc64le, s390x
registry.k8s.io/kube-scheduler:v1.30.0
amd64, arm, arm64, ppc64le, s390x
registry.k8s.io/conformance:v1.30.0
amd64, arm, arm64, ppc64le, s390x
কন্টেইনার ইমেজ আর্কিটেকচার
সমস্ত কন্টেইনার ইমেজ একাধিক আর্কিটেকচারের জন্য উপলব্ধ, যেখানে কন্টেইনার
রানটাইম অন্তর্নিহিত প্ল্যাটফর্মের উপর ভিত্তি করে সঠিকটি বেছে নেওয়া উচিত।
কন্টেইনার ইমেজ নামের প্রত্যয়যোগ একটি ডেডিকেটেড আর্কিটেকচারও নেওয়া সম্ভব,
উদাহরণস্বরূপ
registry.k8s.io/kube-apiserver-arm64:v1.30.0।
কন্টেইনার ইমেজ স্বাক্ষর
ফিচার স্টেট:কুবারনেটিস v1.26 [beta]
কুবারনেটিস 1.30 এর জন্য,
কন্টেইনার ইমেজগুলো sigstore স্বাক্ষর
ব্যবহার করে স্বাক্ষরিত হয়:
বিঃদ্রঃ:
কন্টেইনার ইমেজ sigstore স্বাক্ষর বর্তমানে বিভিন্ন ভৌগলিক অবস্থানের মধ্যে মেলে না।
এই সমস্যা সম্পর্কে আরও তথ্য সংশ্লিষ্ট GitHub issue
তে পাওয়া যাবে।
কুবারনেটিস প্রজেক্ট SPDX 2.3 ফরম্যাটে স্বাক্ষরিত
কুবারনেটিস কন্টেইনার ইমেজের একটি তালিকা প্রকাশ করে।
আপনি এই তালিকাটি আনতে ব্যবহার করতে পারেন:
আপনি যদি একটি নির্দিষ্ট আর্কিটেকচারের জন্য একটি কন্টেইনার ইমেজ নেন,
তাহলে একক-আর্কিটেকচার ইমেজটি মাল্টি-আর্কিটেকচার ম্যানিফেস্ট তালিকার মতোই সাইন ইন করা হয়।
বাইনারি
আপনি চেঞ্জলগ ফাইলগুলিতে কুবারনেটিস উপাদান (এবং তাদের চেকসাম) ডাউনলোড করার লিঙ্কগুলি খুঁজে পেতে পারেন।
বিকল্পভাবে, ভার্সন এবং আর্কিটেকচার দ্বারা ফিল্টার করতে downloadkubernetes.com ব্যবহার করুন।
আপনি নীচে v1.30 কুবারনেটিস উপাদান (তাদের চেকসাম সহ) ডাউনলোড করার লিঙ্কগুলি খুঁজে পেতে পারেন।
পুরানো সাপোর্টেড ভার্সনগুলির জন্য ডাউনলোডগুলি অ্যাক্সেস করতে, সংশ্লিষ্ট ডকুমেন্টেশন দেখুন৷
পুরানো ভার্সন এর জন্য লিঙ্ক বা downloadkubernetes.com ব্যবহার করুন।
বিঃদ্রঃ:
v1.30 কুবারনেটিস উপাদানগুলির (এবং তাদের চেকসাম) এর পুরানো প্যাচ ভার্সনগুলি ডাউনলোড করতে,
অনুগ্রহ করে চেঞ্জলগ ফাইলটি দেখুন।
এই কনটেন্ট স্বয়ংক্রিয়ভাবে তৈরি এবং লিঙ্কগুলি কাজ নাও করতে পারে৷ ডকুমেন্টটির সোর্স অবস্থিত এখানে.
মাইলস্টোন রিলিজের জন্য টার্গেটিং এনহ্যান্সমেন্টস, ইস্যু এবং PR
এই ডকুমেন্টটি ফোকাস করা কুবারনেটিস ডেভেলপার এবং কন্ট্রিবিউটরদের জন্য যাদের
একটি এনহ্যান্সমেন্ট, ইস্যু, অথবা পুল রিকুয়েস্ট তৈরি করতে হয় যা লক্ষ্য করে একটি নির্দিষ্ট
মাইলফলক।
ওয়ার্কফ্লো এবং ইন্টারেকশন সম্পর্কিত তথ্য নীচে বর্ণিত হয়েছে।
একটি এনহ্যান্সমেন্ট, ইস্যু, অথবা পুল রিকুয়েস্ট (PR) এর ওনার হিসেবে, এটি আপনার
দায়িত্ব রিলিজ মাইলস্টোন রিকোয়ারমেন্ট পূরণ হয়েছে নিশ্চিত করা। অটোমেশন এবং
রিলিজ টিম আপনার সাথে যোগাযোগ করবে যদি আপডেট প্রয়োজন হয়, কিন্তু
নিষ্ক্রিয়তার ফলে আপনার কাজ মাইলস্টোন থেকে সরে যেতে পারে। অতিরিক্ত
রিকোয়ারমেন্ট প্রয়োজন যখন লক্ষ্য মাইলস্টোন একটি পূর্ববর্তী রিলিজ (আরও
তথ্যের জন্য চেরি পিক প্রোসেস দেখ)
TL;DR
আপনি যদি আপনার PR মার্জ করাতে চান তার জন্য নিম্নলিখিত প্রয়োজনীয় লেবেল এবং
মাইলস্টোনগুলো প্রয়োজন, এখানে Prow /commands দ্বারা প্রতিনিধিত্ব করা হয়েছে যেগুলি যোগ করা লাগবে:
পূর্বে, মাইলস্টোন-লক্ষ্যযুক্ত পুল রিকুয়েস্টের জন্য
একটি সংস্থায়িত গিটহাব ইস্যু খোলা প্রয়োজন ছিল, কিন্তু এটি আর প্রয়োজন নয়
ফিচার বা এনহ্যান্সমেন্ট হলো ইফেক্টিভ গিটহাব ইস্যু বা KEPs যা পরবর্তী
পুল রিকুয়েস্টের পথে পরিচালিত হয়।
সাধারণ লেবেলিং প্রক্রিয়াটি আর্টিফ্যাক্ট টাইপ জুড়ে সামঞ্জস্যপূর্ণ হওয়া উচিত।
সংজ্ঞা
ইস্যু ওনার: সৃষ্টিকারক, অ্যাসাইনিজ, এবং ইস্যুটি রিলিজ
মাইলস্টোনে সরবরাহ করা ব্যবহারকারী।
রিলিজ টিম: প্রতিটি Kubernetes রিলিজে একটি দল আছে যারা বর্ণিত প্রজেক্ট ম্যানেজমেন্টের
কাজ করে এখানে।
যে কোনো প্রদত্ত রিলিজের সাথে সংশ্লিষ্ট দলের যোগাযোগের তথ্য পাওয়া যাবে
এখানে.
রিলিজ ব্রাঞ্চ: Git ব্রাঞ্চ release-X.Y তৈরি করা হয়েছে vX.Y মাইলস্টোনের জন্য।
vX.Y-rc.0 রিলিজের সময় তৈরি করা হয়েছে এবং রিলিজের পর
প্রায় ১২ মাস ধরে vX.Y.Z প্যাচ রিলিজের সাথে রক্ষণাবেক্ষণ করা হয়েছে।
দ্রষ্টব্য: রিলিজ 1.19 এবং পরবর্তী ভার্সন 1 বছরের প্যাচ রিলিজ সাপোর্ট পায়, এবং
রিলিজ 1.18 এবং তার আগে 9 মাসের প্যাচ রিলিজ সাপোর্ট পেয়েছে।
রিলিজ সাইকেল
কুবারনেটিস রিলিজ বর্তমানে প্রতি বছর প্রায় তিনবার হয়।
রিলিজ প্রক্রিয়াটিকে তিনটি প্রধান পর্যায় হিসাবে বিবেচনা করা যেতে পারে:
এনহ্যান্সমেন্ট ডেফিনেশন
ইমপ্লিমেন্টেশন
স্ট্যাবিলাইজেশন
কিন্তু বাস্তবে, এটি একটি ওপেন সোর্স এবং অ্যাজাইল(agile) প্রকল্প, ফিচার পরিকল্পনা
এবং বাস্তবায়ন সব সময়ে ঘটছে। প্রজেক্ট স্কেল এবং বিশ্বব্যাপী
ডিস্ট্রিবিউটেড ডেভেলপার বেস এর ফলে, এটি গুরুত্বপূর্ণ যে প্রজেক্টের গতি যেনো
ট্রেইলিং স্টেবিলাইজেশন ফেজ এর উপর নির্ভর না করে এবং বরং ক্রমাগত ইন্টিগ্রেশন টেস্টিং চলমান থাকে
যা নিশ্চিত করে যে প্রকল্পটি সর্বদা স্থিতিশীল যাতে একজন ডেভেলপার কোন নির্দিষ্ট কমিটে কোন সমস্যা
তৈরি করেছে তা চিহ্নিত করা যেতে পারে।
বছর ধরে চলমান ফিচার নির্ধারণের সাথে, কিছু আইটেম একটি নির্দিষ্ট রিলিজের
লক্ষ্য হিসেবে উঠে আসবে। এনহ্যান্সমেন্ট ফ্রিজ
রিলিজ সাইকেলের ~৪ সপ্তাহের মধ্যে শুরু হয়। এই মুহুর্তে সমস্ত উদ্দেশ্যমূলক ফিচার কাজকে
রিলিজ টিমের সাথে একযোগে এনহ্যান্সমেন্ট লিড
প্রদত্ত রিলিজ উপযুক্ত পরিকল্পনা নিদর্শনে সংজ্ঞায়িত করা হয়েছে ।
এনহ্যান্সমেন্ট ফ্রিজের পরে, PR এবং ইস্যুগুলোর মাইলস্টোন ট্র্যাক করা গুরুত্বপূর্ণ।
মাইলস্টোন থাকা আইটেমগুলি সম্পূর্ণ করার জন্য একটি পাঞ্চডাউন তালিকা হিসাবে ব্যবহৃত হয়
রিলিজের জন্য। ইস্যুতে, মাইলস্টোন অবশ্যই সঠিকভাবে প্রয়োগ করতে হবে, triage মাধ্যমে
SIG, যাতে রিলিজ টিম বাগ এবং এনহ্যান্সমন্ট ট্র্যাক করতে পারে (যেকোন
এনহ্যান্সমেন্ট-সম্পর্কিত ইস্যুর একটি মাইলস্টোন প্রয়োজন)।
PR এ স্বয়ংক্রিয়ভাবে মাইলফলক বরাদ্দ করতে সাহায্য করার জন্য কিছু অটোমেশন
রয়েছে৷
এই অটোমেশনটি বর্তমানে নিম্নলিখিত রিপোতে প্রযোজ্য:
kubernetes/enhancements
kubernetes/kubernetes
kubernetes/release
kubernetes/sig-release
kubernetes/test-infra
তৈরি করার সময়, master ব্রাঞ্চের বিপরীতে PR গুলোর মানুষের দেওয়া নির্দেশনা প্রয়োজন কোন
মাইলস্টোন টার্গেট করতে হবে তার জন্য। একবার মার্জ হলে,
master ব্রাঞ্চের বিপরীতে তৈরি করা PR গুলোয় মাইলস্টোন় স্বয়ংক্রিয়ভাবে প্রয়োগ করা হয় তাই সেই সময় থেকে
ওই PR এর মাইলস্টোনে মানুষের ব্যবস্থাপনা কম প্রয়োজনীয়। রিলিজ ব্রাঞ্চ এর বিপরীতে তৈরি PR এ,
মাইলস্টোন সংক্রিয়ভাবে প্রয়োগ হয় তাই মানুষবিহীন
ব্যবস্থাপনা মাইলস্টোনের জন্য সবসময় প্রয়োজন।
অন্য কোনো প্রচেষ্টা যা রিলিজ টিমের দ্বারা ট্র্যাক করা উচিত যা কোনো
অটোমেশন আম্ব্রেলার অধীনে নেই তাতে একটি মাইলফলক প্রয়োগ করা উচিত।
ইমপ্লিমেন্টেশন এবং বাগ ফিক্সিং পুরো সাইকেল জুড়ে চলেছে, কিন্তু শেষ হয়
কোড-ফ্রিজ সময়কালে।
কোড ফ্রিজ শুরু হয় ~১২ সপ্তাহে এবং পরবর্তী ~২ সপ্তাহ পর্যন্ত চলে।
এই সময়ে রিলিজ কোডবেসে শুধুমাত্র গুরুত্বপূর্ণ বাগ ফিক্স গ্রহণ করা
হয়।
Code Freeze এর পরে এবং রিলিজের পূর্বে প্রায় দুই সপ্তাহের সময় রয়েছে, যা রিলিজ পূর্বে
সমস্ত অবশিষ্ট গুরুত্বপূর্ণ সমস্যাগুলি সমাধান করা আবশ্যক।
এটি ডকুমেন্টেশন চূড়ান্ত করার জন্য সময় দেয়।
যখন কোড বেস স্টেবল হয়, তখন মাস্টার ব্রাঞ্চটি সাধারণ উন্নতির জন্য পুনরায় খোলা হয়
এবং পরবর্তী রিলিজের মাইলস্টোনে কাজ সেখানে শুরু করা হয়।
বর্তমান রিলিজের জন্য অবশিষ্ট যেকোনো সংশোধন মাস্টার থেকে রিলিজ ব্রাঞ্চে চেরি-পিক করা হয়।
রিলিজ ব্রাঞ্চ থেকে রিলিজ তৈরি করা হয়।
প্রত্যেকটি রিলিজ একটি বৃহৎ কুবারনেটিস লাইফসাইকের অংশ:
মাইলস্টোন থেকে আইটেম অপসারণ
মাইলস্টোন আইটেম যোগ করার প্রক্রিযার অধিক দূরে যাওয়ার আগে,
দয়া করে লক্ষ্য করুন:
রিলিজ টিম এর সদস্যরা মাইলস্টোন থেকে ইস্যু সরাতে পারে
যদি তারা অথবা যদি দায়িত্বশীল SIG মনে করে যে সমস্যাটি বাস্তবে রিলিজ ব্লক
করছে না এবং সম্ভবত সময়ের মধ্যে সমাধান হবে
না।
রিলিজ দলের সদস্যরা নিম্নলিখিত কারণে অথবা এর সমান কারণে মাইলস্টোন থেকে
PR-গুলি সরাতে পারেন:
PR সম্ভবত অস্থিতিশীল এবং ব্লকিং সমস্যা সমাধানের প্রয়োজন
নেই
নতুন PR, লেট ফিচার PR এবং এনহ্যান্সমেন্ট প্রক্রিয়ার
অথবা এক্সেপশন প্রক্রিয়া এর মধ্যে যায় নি
পিআর এর মালিকানা নিতে এবং এটির সাথে কোন ফলো-আপ সমস্যা সমাধান করতে
ইচ্ছুক কোন দায়িত্বশীল SIG নেই
PR সঠিকভাবে লেবেল করা হয় না
PR-এ কাজ দৃশ্যত থেমে গেছে এবং ডেলিভারির তারিখ অনিশ্চিত বা দেরি হবে
রিলিজ টিমের সদস্যরা লেবেলিং এবং SIG দের সাথে যোগাযোগে সাহায্য
করবে,PR কে শ্রেণীবদ্ধ করা জমাদানকারীর দায়িত্ব এবং
প্রাসঙ্গিক SIG হতে সাহায্য নিশ্চিত করা যেনো PR দ্বারা কোনো ব্রেক হলে
ধ্রুত সমাধানের গ্যারেন্টি দেওয়া হবে।
যেখানে অতিরিক্ত পদক্ষেপ প্রয়োজন, রিলিজ দল নিম্নলিখিত
চ্যানেলের মাধ্যমে মানুষ থেকে মানুষে এস্ক্যালেশনের চেষ্টা করবে:
ইস্যু প্রকারের উপযুক্ত SIG দল এবং SIG সদস্যদের উল্লিখিত করে
GitHub-এ মন্তব্য করুন।
ঐচ্ছিকভাবে সরাসরি SIG নেতৃত্ব বা অন্যান্য SIG সদস্যদের সম্বোধন করে
SIG এর স্ল্যাক চ্যানেলে বার্তা পাঠানো।
কমিউনিটি সিগ লিস্ট থেকে স্ল্যাকচ্যানেল এবং SIG নেতৃত্বের সাথে
বুটস্ট্র্যাপ করা হয়েছে
ঐচ্ছিকভাবে সরাসরি "@" হ্যান্ডেল দ্বারা SIG নেতৃত্ব বা অন্যদের উল্লেখ করে
মাইলস্টোনে একটি আইটেম সংযোজন
মাইলস্টোন রক্ষণাবেক্ষণকারী
milestone-maintainers এর সদস্যদের
GitHub টিম দ্বারা GitHub আর্টিফ্যাক্টগুলিতে রিলিজ মাইলস্টোন নির্দিষ্ট করার
দায়িত্ব দেওয়া হয়েছে।
এই গ্রুপটি SIG রিলিজের দ্বারা রক্ষণাবেক্ষণ করা হয়েছে
এবং বিভিন্ন SIG-এর নেতৃত্বের প্রতিনিধিত্ব রয়েছে।
ফিচার সংযোজন
ফিচার পরিকল্পনা এবং সংজ্ঞা আজ অনেক রূপ নেয়, কিন্তু একটি সাধারণ উদাহরণ
হতে পারে একটি KEP-এ বর্ণিত কাজের একটি বড় অংশ, GitHub-এ সংশ্লিষ্ট
টাস্ক সমস্যা সহ। যখন পরিকল্পনাটি একটি বাস্তবায়নযোগ্য অবস্থায় পৌঁছেছে এবং কাজ চলছে,
তখন বর্ধন বা এর অংশগুলিকে GitHub সমস্যা তৈরি করে এবং Prow
"/milestone" কমান্ড দিয়ে চিহ্নিত করে একটি আসন্ন মাইলফলকের জন্য লক্ষ্য করা হয়।
রিলিজ চক্রের প্রথম ~4 সপ্তাহের জন্য, রিলিজ টিমের এনহ্যান্সমেন্ট
লিড সমস্ত প্রয়োজনীয় পরিকল্পনা নিদর্শনগুলি ক্যাপচার করতে GitHub, Slack এবং SIG
মিটিংয়ের মাধ্যমে SIG এবং ফিচার মালিকদের সাথে যোগাযোগ করবে।
আপনার যদি আসন্ন রিলিজের মাইলস্টোন লক্ষ্য করার জন্য একটি এনহ্যান্সমেন্ট থাকে, তাহলে
আপনার SIG নেতৃত্বের সাথে এবং সেই রিলিজের এনহ্যান্সমেন্ট লিডের সাথে কথা
বলুন।
ইস্যু সংযোজন
ইস্যুগুলোকে Prow "/milestone" কমান্ডের মাধ্যমে একটি মাইলস্টোন লক্ষ্য করে চিহ্নিত করা হয়েছে৷
রিলিজ টিমের বাগ Triage লিড
এবং সামগ্রিক কমিউনিটি আগত সমস্যাগুলি দেখে এবং সেগুলিকে Triage করে
ইস্যু Triage.
এর অবদানকারী নির্দেশিকা বিভাগে বর্ণিত হয়েছে।
মাইলস্টোনের সাথে সমস্যাগুলি চিহ্নিত করা কমিউনিটি একটি সমস্যা কখন পর্যবেক্ষণ করা হয়েছিল
এবং কখন কমিউনিটি মনে করে এটির সমাধান করা উচিত সে সম্পর্কে আরও ভাল দৃশ্যমানতা
প্রদান করে। কোড ফ্রিজ চলাকালীন, একটি PR মার্জ করার জন্য একটি
মাইলফলক সেট করতে হবে৷
PR-এর জন্য ওপেন ইস্যুর আর প্রয়োজন নেই, কিন্তু ওপেন ইস্যু
এবং সংশ্লিষ্ট PR-এর সিঙ্ক্রোনাইজড লেবেল থাকা উচিত। উদাহরণস্বরূপ, একটি উচ্চ অগ্রাধিকারের বাগ ইস্যু
এর সাথে যুক্ত PR মার্জ নাও হতে পারে যদি PR শুধুমাত্র নিম্ন অগ্রাধিকার হিসাবে
চিহ্নিত করা হয়।
PR সংযোজন
PR গুলোকে Prow "/milestone" কমান্ডের মাধ্যমে একটি মাইলফলককে লক্ষ্য করে চিহ্নিত করা হয়েছে।
উপরে বর্ণিত কোড ফ্রিজের সময় এটি একটি ব্লকিং প্রয়োজনীয়তা।
SIG মালিকের লেবেল SIG কে সংজ্ঞায়িত করে যার দিকে আমরা অগ্রসর হই যদি একটি মাইলস্টোন সমস্যা স্থবির হয়
বা অতিরিক্ত মনোযোগের প্রয়োজন হয়। যদি বৃদ্ধির পরে কোন আপডেট না থাকে, তাহলে সমস্যাটি মাইলফলক থেকে
স্বয়ংক্রিয়ভাবে সরানো হতে পারে।
এগুলি Prow "/sig" কমান্ডের সাথে যোগ করা হয়। যেমন SIG স্টোরেজ দায়ী লেবেল
যোগ করতে, /sig storage দিয়ে মন্তব্য করুন।
প্রাইওরিটি লেবেল
অগ্রাধিকার লেবেলগুলি ইস্যুগুলির রিলিস মাইলস্টোন থেকে বের হতে প্রারম্ভিক
এস্ক্যালেশন পথ নির্ধারণে ব্যবহৃত হয়। তারা এটা নির্ধারণ করতে ব্যবহৃত হয়
যে ইস্যুর সমাধানের উপরে রিলিস ব্লক করা উচিত কি না।
priority/critical-urgent: কখনই স্বয়ংক্রিয়ভাবে রিলিজ মাইলস্টোন থেকে
সরে যাবেন না; সব উপলভ্য চ্যানেলের মাধ্যমে ক্রমাগত অবদানকারী এবং SIG-এর কাছে
এগিয়ে যান।
একটি রিলিজ ব্লকিং সমস্যা হিসাবে বিবেচিত।
কোড ফ্রিজ চলাকালীন ইস্যু মালিকদের কাছ থেকে দৈনিক আপডেটের প্রয়োজন।
একটি প্যাচ রিলিজ প্রয়োজন হবে যদি অনাবিষ্কৃত কিছু মাইনর রিলিজের পর
থেকে যায়।
priority/important-soon: ইস্যু মালিক এবং SIG মালিকের কাছে এগিয়ে যান; বেশ
কয়েকটি অসফল বৃদ্ধি প্রচেষ্টার পরে মাইলফলক থেকে সরে যান।
একটি রিলিজ ব্লকিং সমস্যা হিসাবে বিবেচনা করা হয় না
একটি প্যাচ রিলিজ প্রয়োজন হবে না
4 দিনের গ্রেস পিরিয়ডের পরে কোড ফ্রিজে স্বয়ংক্রিয়ভাবে রিলিজের
মাইলফলক থেকে সরে যাবে
priority/important-longterm: ইস্যু মালিকদের কাছে এগিয়ে যান; 1 বার প্রচেষ্টার পরে মাইলফলক
থেকে সরে যান।
এমনকি priority/important-soon এর চেয়ে কম জরুরি/সমালোচনা
priority/important-soon এর চেয়ে বেশি আক্রমনাত্মকভাবে মাইলফলক থেকে সরে গেছে
ইস্যু/PR লেবেল
ইস্যুর ধরন ব্যবহার করা হয় সময়ের সাথে রিলিজের বিভিন্ন পরিবর্তন সনাক্ত
করার জন্য। যা রিলিজ টিমকে ভালো ধারণা দেয়
একটি দ্রুত রিলিজ কেডেন্সে কোন ইস্যু গুলো হারিয়ে যাচ্ছে
তা সম্পর্কে।
রিলিজ টার্গেট করা সমস্যাগুলির জন্য, পুল অনুরোধ সহ, নিম্নলিখিত একটি
সমস্যা ধরনের লেবেল সেট করা আবশ্যক:
kind/api-change: একটি API যোগ করে, অপসারণ করে বা পরিবর্তন করে।
kind/bug: একটি নতুন আবিষ্কৃত বাগ সংশোধন করে।
kind/cleanup: টেস্ট যোগ করা, রিফ্যাক্টরিং, পুরানো বাগ ঠিক করা।
kind/design: ডিজাইনের সাথে সম্পর্কিত।
kind/documentation: ডকুমেন্টেশন যোগ করে।
kind/failing-test: CI টেস্ট কেস ধারাবাহিকভাবে ব্যর্থ হয়।
kind/feature: নতুন ফিচার।
kind/flake: CI টেস্ট কেস মাঝে মাঝে ব্যর্থতা দেখাচ্ছে।
3 - প্যাচ রিলিজ
কুবারনেটিস প্যাচ রিলিজের সময়সূচি এবং দলের যোগাযোগ তথ্য।
আমাদের সাধারণ প্যাচ রিলিজ ক্যাডেন্সের মাসিক। এটা
সাধারণত একটু দ্রুত (1 থেকে 2 সপ্তাহ) হলেও, যখন একটি 1.X মাইনর
রিলিজের পরে প্যাচ রিলিজের প্রথমটি হয়। গুরুত্বপূর্ণ বাগ সংশোধন আরও
সাধারণ ক্যাডেন্সের বাইরে একটি আগামী রিলিজ সৃষ্টি করতে পারে। আমরা
এছাড়াও লক্ষ্য করি যে প্রধান ছুটির সময়ে রিলিজ করা হবে না।
দয়া করে আমাদেরকে একটি কার্য দিন দিন - আমরা ভিন্ন টাইমজোন অনুযায়ী থাকতে পারি!
রিলিজের মধ্যে দলটি প্রতি সপ্তাহের ভিতরে আসা চেরি পিক অনুরোধগুলি দেখছে।
দলটি চেরি পিক অনুরোধকারীদের সাথে GitHub PR, SIG চ্যানেল (স্ল্যাকে)
এবং স্ল্যাকের email
মাধ্যমে যোগাযোগ করবে, এবং যদি পিআরে কোনো
প্রশ্ন থাকে।
চেরি পিক গুলির জন্য গিটহাবে পার্শ্ববর্তী লেবেলসহ (উদাহরণস্বরূপ
approved, lgtm, release-note) এবং চেরি পিকের শেষকার পূর্বে CI টেস্ট পাস করতে হবে।
এটা সাধারণত লক্ষ্য করা হয় লক্ষ্য রিলিজের দুই দিন পূর্বে, তবে এটা আরও হতে পারে।
পিআরের প্রস্তুতি যে পরিপ্রেক্ষিতে তা অনেক ভাল, কারণ আমাদের যখন
চেরি পিক আপনার চেরি পিক মানচিত্রে মারার পূর্বে CI সিগনাল পেতে
সময় লাগে।
চেরি পিক PR গুলো, যেগুলো মার্জ মানদন্ড মিস করবে, সেগুলো অনুসরণ এবং ট্রাক করা হবে
পরবর্তী প্যাঁচ রিলিজ এর জন্য ।
সাপোর্ট পিরিয়ড
বার্ষিক সাপোর্ট KEP অনুসারে, কুবারনেটিস কমিউনিটি
প্রায় চৌদ্দ (১৪) মাসের জন্য সক্রিয় প্যাচ রিলিজ সিরিজের
সমর্থন করবে।
এই সময়সীমার প্রথম বারো মাসগুলি স্ট্যান্ডার্ড পিরিয়ড হিসাবে
গণ্য হবে।
দুই মাসের মেইন্টেনেন্স মোডে অবস্থানের সময়সীমার দায়িত্ব মোডে রিলিজ
ম্যানেজাররা অতিরিক্ত মেইন্টেনেন্স রিলিজ কাটতে পারেন যাতে নিম্নলিখিত সমস্যাগুলি সমাধান করা যায়:
CVEs (সিকিউরিটি সংজ্ঞায়িত পরিষদের পরামর্শে)
ডিপেন্ডেন্সি সমস্যাগুলি (বেস ইমেজ আপডেট সহ)
গুরুত্বপূর্ণ কোর কম্পোনেন্ট সমস্যাগুলি
দুই মাসের মেইন্টেনেন্স মোড সময়সীমার শেষে, প্যাচ রিলিজ সিরিজটি EOL (end of life)
হিসাবে গণ্য হবে এবং সম্পর্কিত ব্রাঞ্চে চেরি পিক
শীঘ্রই পরে বন্ধ করা হবে
মনে রাখবেন যে, রক্ষণাবেক্ষণ মোড এবং EOL লক্ষ্যের জন্য মাসের 28 তারিখ বেছে নেওয়া হয়েছিল
সরলতার জন্য (প্রতি মাসে এটি আছে)।
আগামী মাসিক রিলিজ
বাগ ফিক্সের গুরুত্বের সাথে সময়সীমা পরিবর্তন করতে পারে, তবে আমরা সহজে পরিকল্পনা করতে
নিম্নলিখিত মাসিক রিলিজ পয়েন্টগুলির লক্ষ্য করব। অপরিকল্পিত,
গুরুত্বপূর্ণ রিলিজগুলি এদের মধ্যেও ঘটতে পারে।
মাসিক প্যাচ রিলিজ
Cherry Pick সময়সীমা
টার্গেট তারিখ
জানুয়ারি 2024
2024-08-09
2024-08-14
জানুয়ারি 2024
2024-09-06
2024-09-10
জানুয়ারি 2024
2024-10-11
2024-10-15
সক্রিয় শাখাগুলির জন্য বিস্তারিত রিলিজ ইতিহাস
1.30
পরবর্তী প্যাচ রিলিজ হয় 1.30.4.
1.30 enters maintenance mode on and End of Life is on .
প্যাচ রিলিজ
Cherry Pick সময়সীমা
টার্গেট তারিখ
বিঃদ্রঃ
1.30.3
2024-07-12
2024-07-16
1.30.2
2024-06-07
2024-06-11
1.30.1
2024-05-10
2024-05-15
1.30.0
2024-04-17
1.29
পরবর্তী প্যাচ রিলিজ হয় 1.29.8.
1.29 enters maintenance mode on and End of Life is on .
প্যাচ রিলিজ
Cherry Pick সময়সীমা
টার্গেট তারিখ
বিঃদ্রঃ
1.29.7
2024-07-12
2024-07-16
1.29.6
2024-06-07
2024-06-11
1.29.5
2024-05-10
2024-05-14
1.29.4
2024-04-12
2024-04-16
1.29.3
2024-03-08
2024-03-12
1.29.2
2024-02-09
2024-02-14
1.29.1
2024-01-12
2024-01-17
1.29.0
2023-12-13
1.28
পরবর্তী প্যাচ রিলিজ হয় 1.28.13.
1.28 enters maintenance mode on and End of Life is on .
কুবারনেটিসের বিভিন্ন উপাদানগুলির মধ্যে সর্বাধিক ভার্সন skew সাপোর্টেড।
এই ডকুমেন্টটি কুবারনেটিসের বিভিন্ন উপাদানগুলির মধ্যে সর্বাধিক ভার্সন skew সাপোর্টেড বর্ণনা করে।
নির্দিষ্ট ক্লাস্টার সরঞ্জামগুলি ভার্সন skew অতিরিক্ত সীমাবদ্ধতা স্থাপন করতে পারে৷
সাপোর্টেড ভার্সনগুলি
কুবারনেটিস ভার্সন x.y.z হিসাবে প্রকাশ করা হয়,
যেখানে x হল মুখ্য ভার্সন, y হল গৌণ ভার্সন এবং z হল প্যাচ ভার্সন (patch version),
যা শব্দার্থিক ভার্সন পরিভাষা অনুসরণ করে হয়। অতিরিক্ত তথ্যসমূহের জন্য, দেখুন
কুবারনেটিস রিলিজ ভার্সন।
কুবারনেটিস প্রজেক্ট সাম্প্রতিক তিনটি পর্যন্ত ছোট রিলিজের জন্য রিলিজ শাখা বজায় রাখে
(1.31, 1.30, 1.29)।
কুবারনেটিস 1.19 এবং নতুন ভার্সন আনুমানিক 1 বছরের প্যাচ সাপোর্ট পায়(patch support)
কুবারনেটিস 1.18 এবং তার বেশি বয়সীরা প্রায় 9 মাস প্যাচ সাপোর্ট (patch support) পেয়েছে।
প্রযোজ্য সংশোধন, নিরাপত্তা সংশোধন সহ, তীব্রতা এবং সম্ভাব্যতার উপর নির্ভর করে,
সেই তিনটি রিলিজ শাখায় ব্যাকপোর্ট করা যেতে পারে। প্যাচ রিলিজগুলি এই শাখাগুলি থেকে একটি
নিয়মিত ক্যাডেন্স এ কাটা হয়, এবং প্রয়োজনে অতিরিক্ত জরুরী রিলিজগুলি।
অন্যান্য kube-apiserver ইন্সট্যান্সগুলি 1.30 এবং 1.29 এ সাপোর্টেড
kubelet
kubelet নতুন হওয়া উচিত নয় kube-apiserver এর চেয়ে।
kubelet তিনটি ছোট ভার্সন পর্যন্ত পুরানো হতে পারে kube-apiserver এর চেয়ে (kubelet < 1.25 শুধুমাত্র দুটি ছোট ভার্সন পর্যন্ত পুরানো হতে পারে kube-apiserver এর চেয়ে).
উদাহরণ:
kube-apiserver1.30 এ আছে
kubelet1.30, 1.29,
1.28, এবং 1.27 সাপোর্টেড
বিঃদ্রঃ:
If version skew exists between kube-apiserver instances in an HA cluster, this narrows the allowed kubelet versions.
উদাহরণ:
kube-apiserver ইন্সট্যান্সগুলিতে 1.30 এবং 1.29 আছে
kubelet1.29, 1.28,
এবং 1.27 এ সাপোর্টেড (1.30 সাপোর্টেড নয় কারণ
এটি ভার্সন 1.29 -এ kube-apiserver ইন্সট্যান্সের চেয়ে নতুন হবে)
kube-proxy
kube-proxy নতুন হওয়া উচিত নয় kube-apiserver এর চেয়ে।
kube-proxy তিনটি ছোট ভার্সন পর্যন্ত পুরানো হতে পারে kube-apiserver এর চেয়ে
(kube-proxy < 1.25 শুধুমাত্র দুটি ছোট ভার্সন পর্যন্ত পুরানো হতে পারে kube-apiserver) এর চেয়ে।
kube-proxy তিনটি ছোট ভার্সন পর্যন্ত পুরানো বা নতুন হতে পারে kubelet ইন্সট্যান্সের(instance) থেকে
পাশাপাশি এটি চলে (kube-proxy < 1.25 শুধুমাত্র দুটি ছোট ভার্সন পর্যন্ত পুরানো বা নতুন হতে পারে
kubelet ইন্সট্যান্সের থেকে পাশাপাশি এটি চলে )।
উদাহরণ:
kube-apiserver1.30 এ আছে
kube-proxy তে 1.30, 1.29,
1.28, এবং 1.27 এ সাপোর্টেড
বিঃদ্রঃ:
If version skew exists between kube-apiserver instances in an HA cluster, this narrows the allowed kube-proxy versions.
উদাহরণ:
kube-apiserver ইন্সট্যান্সে 1.30 এবং 1.29 আছে
kube-proxy1.29, 1.28,
এবং 1.27 এ সাপোর্টেড (1.30 সাপোর্টেড নয় কারণ
এটি ভার্সন 1.29 -এ kube-apiserver ইন্সট্যান্সের চেয়ে নতুন হবে)
kube-controller-manager, kube-scheduler, and cloud-controller-manager
kube-controller-manager, kube-scheduler, এবং cloud-controller-manager নতুন হওয়া উচিত নয়
kube-apiserver থেকে ইন্সট্যান্সগুলির সাথে তারা যোগাযোগ করে। তারা kube-apiserver ক্ষুদ্র ভার্সনের সাথে মিলবে বলে আশা করা হচ্ছে,
কিন্তু একটি ছোট ভার্সন পর্যন্ত পুরানো হতে পারে (লাইভ আপগ্রেডের অনুমতি দেওয়ার জন্য)।
উদাহরণ:
kube-apiserver1.30 এ আছে
kube-controller-manager, kube-scheduler, এবং cloud-controller-manager সাপোর্টেড আছে
1.30 এবং 1.29
বিঃদ্রঃ:
If version skew exists between kube-apiserver instances in an HA cluster, and these components
can communicate with any kube-apiserver instance in the cluster (for example, via a load balancer),
this narrows the allowed versions of these components.
উদাহরণ:
kube-apiserver ইন্সট্যান্সে 1.30 এবং 1.29 আছে
kube-controller-manager, kube-scheduler, এবং cloud-controller-manager একটি লোড ব্যালেন্সারের সাথে যোগাযোগ করে
যে কোনো kube-apiserver ইন্সট্যান্সে রুট করতে পারে
kube-controller-manager, kube-scheduler, এবং cloud-controller-manager সাপোর্টেড আছে
1.29 (1.30 সাপোর্টেড নয়
কারণ এটি 1.29 ভার্সনে নতুন হবে kube-apiserver ইন্সট্যান্সের চেয়ে নতুন হবে)
kubectl
kubectl একটি ছোট ভার্সন (পুরানো বা নতুন) kube-apiserver এর মধ্যে সাপোর্টেড।
উদাহরণ:
kube-apiserver আছে 1.30
kubectl সাপোর্টেড আছে 1.31, 1.30,
এবং 1.29
বিঃদ্রঃ:
If version skew exists between kube-apiserver instances in an HA cluster, this narrows the supported kubectl versions.
উদাহরণ:
kube-apiserver ইন্সট্যান্সে আছে 1.30 এবং 1.29
kubectl সাপোর্টেড আছে 1.30 এবং 1.29
(অন্যান্য ভার্সনগুলি kube-apiserver উপাদানগুলির একটি থেকে একের বেশি ছোটখাট ভার্সন হবে )
সাপোর্টেড উপাদান আপগ্রেড অর্ডার
উপাদানগুলির মধ্যে সাপোর্টেড ভার্সনের স্কুটির প্রভাব রয়েছে যে ক্রম
অনুসারে উপাদানগুলিকে আপগ্রেড করতে হবে৷ এই বিভাগটি
1.29 ভার্সন থেকে 1.30 ভার্সনে একটি বিদ্যমান
ক্লাস্টার রূপান্তর করতে উপাদানগুলিকে আপগ্রেড করতে হবে তা বর্ণনা করে৷
ঐচ্ছিকভাবে, আপগ্রেড করার প্রস্তুতির সময়, কুবারনেটিস প্রজেক্ট সুপারিশ করে যে
আপনি আপগ্রেড করার সময় যতটা সম্ভব রিগ্রেশন এবং বাগ ফিক্স থেকে উপকৃত হতে
নিম্নলিখিতগুলি করুন:
নিশ্চিত করুন যে উপাদানগুলি আপনার বর্তমান ছোট ভার্সনের সবচেয়ে সাম্প্রতিক প্যাচ
ভার্সনে রয়েছে৷
ক্ষুদ্র লক্ষ্য ভার্সনের সবচেয়ে সাম্প্রতিক প্যাচ ভার্সনে উপাদান আপগ্রেড
করুন।
উদাহরণস্বরূপ, আপনি যদি 1.29 ভার্সন চালাচ্ছেন,
তাহলে নিশ্চিত করুন যে আপনি সাম্প্রতিক প্যাচ ভার্সনে আছেন৷ তারপর, 1.30-এর সবচেয়ে
সাম্প্রতিক প্যাচ ভার্সনে আপগ্রেড করুন৷
kube-apiserver
পূর্বশর্তসমূহ:
একটি একক-ইন্সট্যান্স ক্লাস্টারে, বিদ্যমান kube-apiserver ইন্সট্যান্স হল 1.29
একটি HA ক্লাস্টারে, সমস্ত kube-apiserver ইন্সট্যান্সগুলি 1.29 বা
1.30 এ থাকে (এটি প্রাচীনতম এবং নতুন kube-apiserver ইন্সট্যান্সের মধ্যে সর্বাধিক 1 টি ছোট ভার্সন নিশ্চিত করে )
এই সার্ভারের সাথে যোগাযোগকারী কুব-কন্ট্রোলার-ম্যানেজার, কুব-শিডিউলার এবং ক্লাউড-কন্ট্রোলার-ম্যানেজার
ইনস্ট্যান্সগুলি 1.29 ভার্সনে রয়েছে
(এটি নিশ্চিত করে যে তারা বিদ্যমান API সার্ভার ভার্সনের চেয়ে নতুন নয় ,এবং এর মধ্যে রয়েছে নতুন API সার্ভার ভার্সনের 1টি ছোট ভার্সন)
সমস্ত নোডের kubelet ইনস্ট্যান্সগুলি 1.29 or 1.28 ভার্সনে রয়েছে
(এটি নিশ্চিত করে যে তারা বিদ্যমান API সার্ভার ভার্সনের চেয়ে নতুন নয় ,এবং নতুন API সার্ভার ভার্সনের 2টি ছোট ভার্সনের মধ্যে রয়েছে)
নিবন্ধিত ভর্তির ওয়েবহুকগুলি নতুন কুবে-এপিসার্ভার ইনস্ট্যান্স যে ডেটা পাঠাবে তা পরিচালনা করতে সক্ষম:
ValidatingWebhookConfiguration এবং MutatingWebhookConfiguration অবজেক্ট অন্তর্ভুক্ত করার জন্য আপডেট করা হয়েছে
REST রিসোর্সের যেকোন নতুন ভার্সন 1.30 এ যোগ করা হয়েছে
(বা ব্যবহার করুন matchPolicy: Equivalent option v1.15+ এ সহজলভ্য)
ওয়েবহুকগুলি REST সংস্থানগুলির যে কোনও নতুন ভার্সন পরিচালনা করতে সক্ষম যা তাদের কাছে পাঠানো হবে,
এবং 1.30-এ বিদ্যমান ভার্সনগুলিতে যে কোনও নতুন ক্ষেত্র যুক্ত করা হবে।
kube-apiserver আপগ্রেড করুন 1.30
বিঃদ্রঃ:
Project policies for API deprecation and
API change guidelines
require kube-apiserver to not skip minor versions when upgrading, even in single-instance clusters.
kube-controller-manager, kube-scheduler, and cloud-controller-manager
পূর্বশর্তসমূহ:
kube-apiserver ইনস্ট্যান্সগুলির সাথে এই উপাদানগুলি 1.30 -এ যোগাযোগ করে
(HA ক্লাস্টারে যেখানে এই কন্ট্রোল প্লেন উপাদানগুলি ক্লাস্টারের যেকোনো kube-apiserver ইনস্ট্যান্সের সাথে যোগাযোগ
করতে পারে, এই উপাদানগুলি আপগ্রেড করার আগে সমস্ত kube-apiserver ইনস্ট্যান্সগুলি আপগ্রেড করা আবশ্যক)
1.30 থেকে আপগ্রেড করুন kube-controller-manager, kube-scheduler, এবং
cloud-controller-manager । kube-controller-manager, kube-scheduler,
cloud-controller-manager এর মধ্যে কোনো প্রয়োজনীয় আপগ্রেড অর্ডার নেই।
আপনি যে কোনো ক্রমে এই উপাদান আপগ্রেড করতে পারেন, বা
এমনকি একই সাথে।
kubelet
পূর্বশর্তসমূহ:
যে kube-apiserver ইনস্ট্যান্স kubelet এর সাথে যোগাযোগ করে তা 1.30-এ।
ঐচ্ছিকভাবে kubelet ইনস্ট্যান্সগুলিকে 1.30 তে আপগ্রেড করুন (অথবা সেগুলি
1.29, 1.28, বা 1.27 এ ছেড়ে দেওয়া যেতে পারে)
বিঃদ্রঃ:
Before performing a minor version kubelet upgrade, drain pods from that node.
In-place minor version kubelet upgrades are not supported.
সতর্কতা:
Running a cluster with kubelet instances that are persistently three minor versions behind
kube-apiserver means they must be upgraded before the control plane can be upgraded.
kube-proxy
পূর্বশর্তসমূহ:
যে kube-apiserver ইনস্ট্যান্স kube-proxy এর সাথে যোগাযোগ করে তা 1.30-এ।
ঐচ্ছিকভাবে kube-proxy ইনস্ট্যান্সগুলিকে 1.30 তে আপগ্রেড করুন
(অথবা সেগুলি 1.29, 1.28,
বা 1.27 এ ছেড়ে দেওয়া যেতে পারে)
সতর্কতা:
Running a cluster with kube-proxy instances that are persistently three minor versions behind
kube-apiserver means they must be upgraded before the control plane can be upgraded.
5 - নোটস
কুবারনেটিস রিলিজ নোটস।
আপনার কুবারনেটিস সংস্করণের সাথে মেলে এমন চেঞ্জলগ (Changelog)
পড়ার মাধ্যমে রিলিজ নোট পাওয়া যাবে। 1.30-এর চেঞ্জলগ দেখুন
গিটহাব ।
বিকল্পভাবে, রিলিজ নোটস অনলাইনে অনুসন্ধান এবং ফিল্টার করা যেতে পারে: relnotes.k8s.io।
1.30-এর জন্য ফিল্টার করা রিলিজ নোটগুলো দেখুন
relnotes.k8s.io।
6 - রিলিজ ম্যানেজারস
"রিলিজ ম্যানেজাররা" হল একটি সার্বিক শব্দ যা কুবারনেটিসের সেই অবদানকারীদের
নির্দেশ করে, যারা রিলিজ ব্রাঞ্চগুলি বজায় রাখা এবং SIG Release দ্বারা
সরবরাহিত টুলগুলি ব্যবহার করে রিলিজ তৈরি করার দায়িত্বে থাকে।
কিছু রিলিজ সম্পর্কিত তথ্য ইম্বার্গোর অধীনে রয়েছে এবং আমরা তারা সেট করার জন্য নীতি নির্ধারণ করেছি।
অধিক তথ্যের জন্য দয়া করে
নিরাপত্তা ইম্বার্গো নীতি
দেখুন।
হ্যান্ডবুক
লক্ষ্যস্থান: প্যাচ রিলিজ টীম এবং শাখা ম্যানেজার হ্যান্ডবুকগুলি পরের তারিখে ডিডুপ্লিকেট করা হবে।
নোট: ডকুমেন্টেশনে প্যাচ রিলিজ টিম এবং ব্রাঞ্চ ম্যানেজমেন্ট ভূমিকা সম্পর্কে
উল্লেখ থাকতে পারে। এই দুই ভূমিকা রিলিজ ম্যানেজার ভূমিকায় একীভূত
করা হয়েছে।
মিনিমাম প্রয়োজনীয়তা রিলিজ ম্যানেজার এবং রিলিজ ম্যানেজার অ্যাসোসিয়েটগুলির জন্য নিম্নলিখিত:
বেসিক ইউনিক্স কমান্ডের পরিচিতি এবং শেল স্ক্রিপ্ট ডিবাগ করতে পারা।
git এবং সম্পর্কিত git কমান্ড লাইন ইনভোকেশন এর মাধ্যমে
ব্রাঞ্চ সোর্স কোড ওয়ার্কফ্লো পরিচিতি।
গুগল ক্লাউডের সাধারণ জ্ঞান (ক্লাউড বিল্ড এবং ক্লাউড স্টোরেজ)।
সাহায্য চাওয়া এবং স্পষ্টভাবে যোগাযোগের জন্য উন্মুক্ত।
রিলিজ ম্যানেজার হতে চাইলে, প্রথমে কাউকে রিলিজ ম্যানেজার অ্যাসোসিয়েট হিসেবে কাজ করতে হবে।
অ্যাসোসিয়েটরা কয়েকটি চক্র জুড়ে রিলিজের উপর সক্রিয়ভাবে কাজ করে রিলিজ
ম্যানেজারে পদোন্নতি পায়:
নেতৃত্ব দেওয়ার ইচ্ছা প্রদর্শন করা
রিলিজ ম্যানেজারদের সাথে ট্যাগ-টিম করে প্যাচগুলিতে কাজ করা,
শেষ পর্যন্ত স্বাধীনভাবে একটি রিলিজ কাটা যায় ।
রিলিজের একটি সীমাবদ্ধ কার্যকারিতা থাকার কারণে, আমরা ইমেজ প্রচার
এবং অন্যান্য কোর রিলিজ ইঞ্জিনিয়ারিং কাজের উল্লেখযোগ্য অবদানকেও মূল্যায়ন করি ।
অ্যাসোসিয়েটদের কাজ কিভাবে হচ্ছে তা জিজ্ঞাসাবাদ করা, উন্নতির প্রস্তাবনা দেওয়া,
ফিডব্যাক সংগ্রহ করা এবং পরিবর্তন চালনা করা
নির্ভরযোগ্য এবং দ্রুত সাড়া দেওয়া ।
এমন উন্নত কাজে নিজেকে নিযুক্ত করা যা সম্পন্ন করতে রিলিজ
ম্যানেজার-স্তরের অ্যাক্সেস এবং সুবিধার প্রয়োজন ।
রিলিজ ম্যানেজার অ্যাসোসিয়েটস
রিলিজ ম্যানেজার অ্যাসোসিয়েটরা হলেন রিলিজ ম্যানেজারদের শিক্ষানবিশ, যাদের আগে রিলিজ ম্যানেজার শ্যাডো হিসেবে পরিচিত করা হতো। তাদের
দায়িত্ব হল:
প্যাচ রিলিজের কাজ, চেরি পিক রিভিউ
k/release আপডেট করা: নির্ভরশীলতা আপডেট করা এবং সোর্স
কোডবেজে অভ্যস্ত হওয়া
ডকুমেন্টেশনে অবদান রাখা: হ্যান্ডবুকগুলি মেনটেইন করা, নিশ্চিত করা
যে রিলিজ প্রক্রিয়াগুলি ডকুমেন্টেড হয়েছে
একজন রিলিজ ম্যানেজারের সাহায্যে: রিলিজ টিমের সাথে রিলিজ
চক্রের সময় কাজ করা এবং কুবেরনেটস রিলিজ কাটা
অগ্রাধিকার এবং যোগাযোগে সাহায্যের সুযোগ খুঁজে বের করা
প্যাচ রিলিজ সম্পর্কে প্রাক-ঘোষণা এবং আপডেট পাঠানো
ক্যালেন্ডার আপডেট করা, রিলিজের তারিখ এবং মাইলস্টোনগুলির সাথে সাহায্য করা
রিলিজ চক্রের টাইমলাইন থেকে
Buddy প্রোগ্রামের মাধ্যমে, নতুন অবদানকারীদের অনবোর্ডিং করা এবং
তাদের সাথে কাজের জুটি বাঁধা
অবদানকারীরা নিম্নলিখিত দেখানোর মাধ্যমে অ্যাসোসিয়েট হতে পারেন:
নিয়মিত অংশগ্রহণ, যার মধ্যে ৬-১২ মাসের সক্রিয় রিলিজ
ইঞ্জিনিয়ারিং-সম্পর্কিত কাজ অন্তর্ভুক্ত
একটি রিলিজ চক্রে রিলিজ টিমে একজন টেকনিকাল
লিড হিসেবে ভূমিকা পালনের অভিজ্ঞতা
SIG রিলিজ সামগ্রিকভাবে কীভাবে কাজ করে তা বোঝার জন্য এই
অভিজ্ঞতাটি একটি শক্ত ভিত্তিরেখা প্রদান করে—যার মধ্যে প্রযুক্তিগত দক্ষতা,
যোগাযোগ/রেস্পন্সিভনেস এবং নির্ভরযোগ্যতা সম্পর্কিত আমাদের প্রত্যাশাগুলি অন্তর্ভুক্ত
k/release আইটেমগুলিতে কাজ করা যা Testgrid এর সাথে আমাদের ইন্টার্যাকশন এর
উন্নত করে, লাইব্রেরি পরিষ্কার করা ইত্যাদি কাজে অবদান রাখা
এই প্রচেষ্টাগুলি রিলিজ ম্যানেজারদের এবং অ্যাসোসিয়েটদের সাথে
ইন্টার্যাক্ট করা এবং জুটি বাঁধা প্রয়োজন
SIG রিলিজ লিডস
SIG রিলিজ চেয়ারস এবং টেকনিকাল লিডস দায়ী আছেন:
SIG রিলিজের গভর্নেন্সের জন্য
রিলিজ ম্যানেজার এবং অ্যাসোসিয়েটদের জন্য জ্ঞান বিনিময় সেশন নেতৃত্ব দান
নেতৃত্ব এবং অগ্রাধিকার নির্ধারণে কোচিং প্রদান
তাদের এখানে স্পষ্টভাবে উল্লেখ করা হয়েছে কারণ তারা প্রতিটি ভূমিকার
জন্য বিভিন্ন যোগাযোগ চ্যানেল এবং অনুমতি গ্রুপ (GitHub টিমস, GCP অ্যাক্সেস)
এর মালিক। এই হিসাবে, তারা অত্যন্ত অধিকারপ্রাপ্ত কমিউনিটি সদস্য এবং কিছু ব্যক্তিগত
যোগাযোগের জন্য সচেতন, যা কখনো কখনো কুবারনেটিস নিরাপত্তা প্রকাশনার সাথে সম্পর্কিত
হতে পারে।
