جس کا ہم (اور نہ صرف ہم) طویل عرصے سے انتظار کر رہے تھے وہ ہوا: ، ایپلی کیشنز بنانے اور انہیں Kubernetes تک پہنچانے کے لیے ہماری اوپن سورس یوٹیلیٹی، اب 3 طرفہ انضمام پیچ کا استعمال کرتے ہوئے تبدیلیاں لاگو کرنے کی حمایت کرتی ہے! اس کے علاوہ، ان وسائل کو دوبارہ تعمیر کیے بغیر ہیلم ریلیز میں موجودہ K8s وسائل کو اپنانا ممکن ہے۔
اگر یہ بہت مختصر ہے، تو ہم ڈال دیتے ہیں۔ WERF_THREE_WAY_MERGE=enabled - ہمیں تعیناتی ملتی ہے "جیسا کہ میں kubectl apply"، موجودہ ہیلم 2 تنصیبات کے ساتھ مطابقت رکھتا ہے اور اس سے بھی کچھ زیادہ۔
لیکن آئیے اس تھیوری کے ساتھ شروع کرتے ہیں: 3 طرفہ انضمام کے پیچ بالکل کیا ہیں، لوگ ان کو بنانے کا طریقہ کیسے لے کر آئے، اور وہ کبرنیٹس پر مبنی انفراسٹرکچر کے ساتھ CI/CD کے عمل میں کیوں اہم ہیں؟ اور اس کے بعد، آئیے دیکھتے ہیں کہ 3-way-merge کیا ہے werf میں، کون سے طریقوں کو بطور ڈیفالٹ استعمال کیا جاتا ہے اور اس کا انتظام کیسے کیا جاتا ہے۔
3 طرفہ انضمام پیچ کیا ہے؟
تو، آئیے YAML میں بیان کردہ وسائل کو کبرنیٹس میں شامل کرنے کے کام کے ساتھ شروع کریں۔
وسائل کے ساتھ کام کرنے کے لیے، Kubernetes API درج ذیل بنیادی آپریشنز پیش کرتا ہے: تخلیق، پیچ، تبدیل اور حذف۔ یہ فرض کیا جاتا ہے کہ ان کی مدد سے کلسٹر میں وسائل کا ایک آسان مسلسل رول آؤٹ تعمیر کرنا ضروری ہے۔ کیسے؟
kubectl کے ضروری احکامات
Kubernetes میں اشیاء کو منظم کرنے کا پہلا نقطہ نظر ان اشیاء کو بنانے، ان میں ترمیم کرنے اور حذف کرنے کے لیے kubectl ضروری کمانڈز کا استعمال کرنا ہے۔ سیدھے الفاظ میں:
- ٹیم
kubectl runآپ تعیناتی یا جاب چلا سکتے ہیں:kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE - ٹیم
kubectl scale- نقل کی تعداد کو تبدیل کریں:kubectl scale --replicas=3 deployment/mysql - وغیرہ
یہ نقطہ نظر پہلی نظر میں آسان لگ سکتا ہے. تاہم مسائل ہیں:
- یہ مشکل ہے خودکار.
- جیسا کہ ترتیب کی عکاسی Git میں؟ کلسٹر میں ہونے والی تبدیلیوں کا جائزہ کیسے لیا جائے؟
- فراہم کرنے کا طریقہ تولیدی صلاحیت دوبارہ شروع کرنے پر کنفیگریشنز؟
- ...
یہ واضح ہے کہ یہ نقطہ نظر ایپلیکیشن اور انفراسٹرکچر کو بطور کوڈ (IaC؛ یا حتیٰ کہ ایک زیادہ جدید آپشن کے طور پر، Kubernetes ماحولیاتی نظام میں مقبولیت حاصل کرنا)۔ لہذا، ان احکامات کو kubectl میں مزید ترقی نہیں ملی۔
آپریشنز بنائیں، حاصل کریں، تبدیل کریں اور حذف کریں۔
پرائمری کے ساتھ تخلیق یہ آسان ہے: مینی فیسٹ کو آپریشن میں بھیجیں۔ create kube api اور وسیلہ بنایا گیا ہے۔ مینی فیسٹ کی YAML نمائندگی کو Git میں اسٹور کیا جا سکتا ہے اور کمانڈ کا استعمال کرتے ہوئے تخلیق کیا جا سکتا ہے۔ kubectl create -f manifest.yaml.
С ہٹانا بھی آسان: ایک ہی کو تبدیل کریں۔ manifest.yaml گٹ سے ٹیم تک kubectl delete -f manifest.yaml.
آپریشن replace آپ کو وسائل کو دوبارہ بنائے بغیر، وسائل کی ترتیب کو مکمل طور پر ایک نئے سے تبدیل کرنے کی اجازت دیتا ہے۔ اس کا مطلب یہ ہے کہ وسائل میں تبدیلی کرنے سے پہلے، آپریشن کے ساتھ موجودہ ورژن سے استفسار کرنا منطقی ہے۔ get، اسے تبدیل کریں اور اسے آپریشن کے ساتھ اپ ڈیٹ کریں۔ replace. kube apiserver بلٹ ان ہے۔ اور، اگر سرجری کے بعد get اعتراض بدل گیا ہے، پھر آپریشن replace یہ کام نہیں کرے گا.
گٹ میں کنفیگریشن کو اسٹور کرنے اور اسے تبدیل کرکے اپ ڈیٹ کرنے کے لیے، آپ کو آپریشن کرنا ہوگا۔ get، ہمیں جو موصول ہوا ہے اس کے ساتھ گٹ سے تشکیل کو ضم کریں، اور عمل کریں۔ replace. پہلے سے طے شدہ طور پر، kubectl صرف آپ کو کمانڈ استعمال کرنے کی اجازت دیتا ہے۔ kubectl replace -f manifest.yamlجہاں manifest.yaml - پہلے سے مکمل طور پر تیار (ہمارے معاملے میں، ضم شدہ) مینی فیسٹ جسے انسٹال کرنے کی ضرورت ہے۔ یہ پتہ چلتا ہے کہ صارف کو انضمام کے مینی فیسٹ کو نافذ کرنے کی ضرورت ہے، اور یہ کوئی معمولی بات نہیں ہے...
یہ بات بھی قابل غور ہے کہ اگرچہ manifest.yaml اور Git میں محفوظ ہے، ہم پہلے سے نہیں جان سکتے کہ آیا کوئی چیز بنانا یا اسے اپ ڈیٹ کرنا ضروری ہے - یہ صارف سافٹ ویئر کے ذریعے کرنا چاہیے۔
کل: کیا ہم ایک مسلسل رول آؤٹ بنا سکتے ہیں؟ صرف تخلیق، تبدیل اور حذف کا استعمال کرتے ہوئے، اس بات کو یقینی بناتے ہوئے کہ بنیادی ڈھانچے کی ترتیب گٹ میں کوڈ اور آسان CI/CD کے ساتھ محفوظ ہے؟
اصولی طور پر، ہم اس کے لیے... آپ کو انضمام کے عمل کو لاگو کرنے کی ضرورت ہوگی۔ منشور اور کسی قسم کا پابند کہ:
- کلسٹر میں کسی چیز کی موجودگی کو چیک کرتا ہے،
- ابتدائی وسائل کی تخلیق انجام دیتا ہے،
- اسے اپ ڈیٹ یا حذف کرتا ہے۔
اپ ڈیٹ کرتے وقت، براہ کرم نوٹ کریں۔ وسائل تبدیل ہو سکتے ہیں۔ آخری سے get اور خود بخود پرامید لاکنگ کے معاملے کو سنبھال لیں - بار بار اپ ڈیٹ کرنے کی کوشش کریں۔
تاہم، جب kube-apiserver وسائل کو اپ ڈیٹ کرنے کا ایک اور طریقہ پیش کرتا ہے تو وہیل کو دوبارہ کیوں ایجاد کیا جائے: آپریشن patch، جو صارف کو بیان کردہ کچھ مسائل سے نجات دلاتا ہے؟
پیچ
اب ہم پیچ کی طرف آتے ہیں۔
Kubernetes میں موجود اشیاء میں تبدیلیاں لاگو کرنے کا بنیادی طریقہ پیچ ہیں۔ آپریشن patch یہ اس طرح کام کرتا ہے:
- kube-apiserver صارف کو JSON فارم میں ایک پیچ بھیجنے اور آبجیکٹ کی وضاحت کرنے کی ضرورت ہے،
- اور apiserver خود آبجیکٹ کی موجودہ حالت سے نمٹے گا اور اسے مطلوبہ شکل میں لے آئے گا۔
اس معاملے میں پرامید لاکنگ کی ضرورت نہیں ہے۔ یہ آپریشن بدلنے سے زیادہ اعلانیہ ہے، حالانکہ شروع میں یہ اس کے برعکس لگتا ہے۔
اس طرح:
- ایک آپریشن کا استعمال کرتے ہوئے
createہم گٹ سے مینی فیسٹ کے مطابق ایک آبجیکٹ بناتے ہیں، - مدد کے ساتھ
delete- اگر اعتراض کی مزید ضرورت نہیں ہے تو حذف کریں، - مدد کے ساتھ
patch- ہم آبجیکٹ کو تبدیل کرتے ہیں، اسے گٹ میں بیان کردہ شکل میں لاتے ہیں۔
تاہم، ایسا کرنے کے لئے، آپ کو بنانے کی ضرورت ہے درست پیچ!
ہیلم 2: 2-وی-مرج میں پیچ کیسے کام کرتے ہیں۔
جب آپ پہلی بار ریلیز انسٹال کرتے ہیں تو ہیلم آپریشن کرتا ہے۔ create چارٹ وسائل کے لیے۔
ہر وسائل کے لیے ہیلم ریلیز کو اپ ڈیٹ کرتے وقت:
- پچھلے چارٹ اور موجودہ چارٹ ورژن کے وسائل کے ورژن کے درمیان پیچ پر غور کرتا ہے،
- اس پیچ کو لاگو کرتا ہے.
ہم اس پیچ کو کال کریں گے۔ 2 طرفہ انضمام پیچکیونکہ اس کی تخلیق میں 2 منشور شامل ہیں:
- پچھلے ریلیز سے ظاہر کردہ وسائل،
- وسائل موجودہ وسائل سے ظاہر ہوتا ہے۔
آپریشن کو ہٹاتے وقت delete kube apiserver میں ان وسائل کے لیے کہا جاتا ہے جن کا اعلان پچھلی ریلیز میں کیا گیا تھا، لیکن موجودہ میں اعلان نہیں کیا گیا تھا۔
2 طرفہ انضمام پیچ کے نقطہ نظر میں ایک مسئلہ ہے: یہ اس کی طرف جاتا ہے۔ کلسٹر میں وسائل کی حقیقی حالت اور گٹ میں مینی فیسٹ کے ساتھ ہم آہنگی سے باہر.
ایک مثال کے ساتھ مسئلہ کی وضاحت
- گٹ میں، ایک چارٹ ایک مینی فیسٹ کو اسٹور کرتا ہے جس میں فیلڈ
imageتعیناتی کے معاملاتubuntu:18.04. - صارف کے ذریعے
kubectl editمیں اس فیلڈ کی قدر کو تبدیل کر دیا۔ubuntu:19.04. - ہیلم چارٹ کو دوبارہ تعینات کرتے وقت ایک پیچ پیدا نہیں کرتاکیونکہ میدان
imageریلیز کے پچھلے ورژن میں اور موجودہ چارٹ میں ایک جیسے ہیں۔ - دوبارہ تعیناتی کے بعد
imageرہتا ہےubuntu:19.04، اگرچہ چارٹ کہتا ہے۔ubuntu:18.04.
ہم نے غیر مطابقت پذیری حاصل کی اور اعلانیہ کھو دیا.
مطابقت پذیر وسیلہ کیا ہے؟
عام طور پر مکمل چلنے والے کلسٹر میں ریسورس مینی فیسٹ اور گٹ سے مینی فیسٹ کے درمیان میچ حاصل کرنا ناممکن ہے۔ کیونکہ ایک حقیقی مینی فیسٹ میں سروس کی تشریحات/لیبلز، اضافی کنٹینرز اور دیگر ڈیٹا ہوسکتے ہیں جو کچھ کنٹرولرز کے ذریعہ متحرک طور پر وسائل سے شامل اور ہٹائے جاتے ہیں۔ ہم اس ڈیٹا کو گٹ میں نہیں رکھ سکتے اور نہ ہی چاہتے ہیں۔ تاہم، ہم چاہتے ہیں کہ وہ فیلڈز جو ہم نے Git میں واضح طور پر بیان کیے ہیں وہ رول آؤٹ پر مناسب قدروں کو اختیار کریں۔
یہ اتنا عام نکلا۔ مطابقت پذیر وسائل کا اصول: کسی وسائل کو رول آؤٹ کرتے وقت، آپ صرف ان فیلڈز کو تبدیل یا حذف کر سکتے ہیں جو Git کے مینی فیسٹ میں واضح طور پر بیان کیے گئے ہیں (یا پچھلے ورژن میں بیان کیے گئے تھے اور اب حذف کر دیے گئے ہیں)۔
3 طرفہ انضمام پیچ
اہم خیال : ہم چل رہے کلسٹر سے مینی فیسٹ کے موجودہ ورژن کو مدنظر رکھتے ہوئے Git سے مینی فیسٹ کے آخری اپلائیڈ ورژن اور Git سے مینی فیسٹ کے ٹارگٹ ورژن کے درمیان ایک پیچ تیار کرتے ہیں۔ نتیجے میں آنے والے پیچ کو مطابقت پذیر وسائل کے اصول کی تعمیل کرنی چاہیے:
- ٹارگٹ ورژن میں شامل کیے گئے نئے فیلڈز ایک پیچ کا استعمال کرتے ہوئے شامل کیے جاتے ہیں۔
- پچھلے اپلائیڈ ورژن میں پہلے سے موجود فیلڈز اور ٹارگٹ ورژن میں موجود نہیں ایک پیچ کا استعمال کرتے ہوئے ری سیٹ کیے جاتے ہیں۔
- آبجیکٹ کے موجودہ ورژن میں فیلڈز جو مینی فیسٹ کے ٹارگٹ ورژن سے مختلف ہیں پیچ کا استعمال کرتے ہوئے اپ ڈیٹ کیے جاتے ہیں۔
یہ اس اصول پر ہے کہ یہ پیچ پیدا کرتا ہے۔ kubectl apply:
- مینی فیسٹ کا آخری اطلاق شدہ ورژن خود آبجیکٹ کی تشریح میں محفوظ ہوتا ہے،
- ہدف - مخصوص YAML فائل سے لیا گیا،
- موجودہ ایک چلنے والے کلسٹر سے ہے۔
اب جب کہ ہم نے تھیوری کو ترتیب دے دیا ہے، اب وقت آگیا ہے کہ آپ کو بتائیں کہ ہم نے ورف میں کیا کیا۔
werf میں تبدیلیوں کا اطلاق کرنا
اس سے پہلے، ہیلم 2 کی طرح werf، 2 طرفہ مرج پیچ استعمال کرتا تھا۔
مرمت پیچ
ایک نئی قسم کے پیچ پر سوئچ کرنے کے لیے - 3-طریقہ مرج - پہلا قدم جسے ہم نے متعارف کرایا نام نہاد مرمت کے پیچ.
تعینات کرتے وقت، ایک معیاری 2 طرفہ انضمام کا پیچ استعمال کیا جاتا ہے، لیکن werf اضافی طور پر ایک ایسا پیچ تیار کرتا ہے جو وسائل کی اصل حالت کو Git میں لکھے ہوئے کے ساتھ ہم آہنگ کرے گا (اس طرح کا پیچ اوپر بیان کردہ اسی مطابقت پذیر وسائل کے اصول کا استعمال کرتے ہوئے بنایا گیا ہے) .
اگر غیر مطابقت پذیری واقع ہوتی ہے، تعیناتی کے اختتام پر صارف کو متعلقہ پیغام اور ایک پیچ کے ساتھ ایک انتباہ موصول ہوتا ہے جسے وسائل کو مطابقت پذیر شکل میں لانے کے لیے لاگو کرنا ضروری ہے۔ یہ پیچ ایک خاص تشریح میں بھی درج ہے۔ werf.io/repair-patch. یہ فرض کیا جاتا ہے کہ صارف کے ہاتھ خود اس پیچ کو لاگو کرے گا: werf اسے بالکل بھی لاگو نہیں کرے گا۔
مرمت کے پیچ تیار کرنا ایک عارضی اقدام ہے جو آپ کو 3 طرفہ انضمام کے اصول کی بنیاد پر پیچ کی تخلیق کی جانچ کرنے کی اجازت دیتا ہے، لیکن خود بخود ان پیچ کو لاگو نہیں کرتے ہیں۔ اس وقت، یہ آپریٹنگ موڈ بطور ڈیفالٹ فعال ہے۔
صرف نئی ریلیز کے لیے 3 طرفہ ضم کرنے والا پیچ
1 دسمبر 2019 سے، werf کے بیٹا اور الفا ورژن شروع ہو رہے ہیں۔ پہلے سے طے شدہ تبدیلیوں کو لاگو کرنے کے لیے مکمل 3 طرفہ انضمام کے پیچ استعمال کریں جو صرف werf کے ذریعے شروع کی گئی نئی ہیلم ریلیزز پر لاگو ہوں۔ موجودہ ریلیزز 2-way-merge + مرمت کے پیچ اپروچ کو استعمال کرتی رہیں گی۔
اس آپریٹنگ موڈ کو سیٹنگ کے ذریعے واضح طور پر فعال کیا جا سکتا ہے۔ WERF_THREE_WAY_MERGE_MODE=onlyNewReleases ابھی.
نوٹ: یہ فیچر کئی ریلیزز پر werf میں نمودار ہوا: الفا چینل میں یہ ورژن کے ساتھ تیار ہو گیا۔ ، اور بیٹا چینل میں - کے ساتھ .
تمام ریلیز کے لیے 3 طرفہ ضم کرنے والا پیچ
15 دسمبر 2019 سے، werf کے بیٹا اور الفا ورژن تمام ریلیز میں تبدیلیاں لاگو کرنے کے لیے بطور ڈیفالٹ مکمل 3 طرفہ انضمام پیچ استعمال کرنا شروع کر دیتے ہیں۔
اس آپریٹنگ موڈ کو سیٹنگ کے ذریعے واضح طور پر فعال کیا جا سکتا ہے۔ WERF_THREE_WAY_MERGE_MODE=enabled ابھی.
ریسورس آٹو اسکیلنگ کے ساتھ کیا کرنا ہے؟
Kubernetes میں آٹو اسکیلنگ کی 2 قسمیں ہیں: HPA (افقی) اور VPA (عمودی)۔
افقی خود بخود نقل کی تعداد کا انتخاب کرتا ہے، عمودی - وسائل کی تعداد۔ ریسورس مینی فیسٹ میں نقل کی تعداد اور وسائل کی ضروریات دونوں کی وضاحت کی گئی ہے (ریسورس مینی فیسٹ دیکھیں)۔ spec.replicas یا spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и ).
مسئلہ: اگر کوئی صارف کسی چارٹ میں کسی وسائل کو ترتیب دیتا ہے تاکہ وہ وسائل کے لیے کچھ قدریں متعین کرے یا اس وسیلے کے لیے نقلیں اور آٹو اسکیلرز کو فعال کیا جائے، تو ہر تعیناتی کے ساتھ werf ان اقدار کو چارٹ مینی فیسٹ میں لکھی گئی چیزوں پر دوبارہ ترتیب دے گا۔ .
مسئلے کے دو حل ہیں۔ شروع کرنے کے لیے، یہ بہتر ہے کہ چارٹ مینی فیسٹ میں خودکار پیمانے پر قدروں کو واضح طور پر بیان کرنے سے گریز کریں۔ اگر یہ اختیار کسی وجہ سے موزوں نہیں ہے (مثال کے طور پر، کیونکہ ابتدائی وسائل کی حدیں اور چارٹ میں نقل کی تعداد مقرر کرنا آسان ہے)، تو werf درج ذیل تشریحات پیش کرتا ہے:
-
werf.io/set-replicas-only-on-creation=true -
werf.io/set-resources-only-on-creation=true
اگر اس طرح کی تشریح موجود ہے تو، werf ہر تعیناتی پر متعلقہ اقدار کو دوبارہ ترتیب نہیں دے گا، لیکن انہیں صرف اس وقت ترتیب دے گا جب وسائل ابتدائی طور پر بنائے جائیں گے۔
مزید تفصیلات کے لیے، پراجیکٹ کی دستاویزات دیکھیں и .
3-طرفہ انضمام پیچ کے استعمال سے منع کریں۔
صارف فی الحال ماحولیاتی متغیر کا استعمال کرتے ہوئے werf میں نئے پیچ کے استعمال پر پابندی لگا سکتا ہے۔ WERF_THREE_WAY_MERGE_MODE=disabled. تاہم، شروع یکم مارچ 1 سے اس پابندی کا اطلاق نہیں ہوگا۔ اور یہ صرف 3 طرفہ مرج پیچ استعمال کرنا ممکن ہوگا۔
werf میں وسائل کو اپنانا
3-طرفہ انضمام پیچ کے ساتھ تبدیلیوں کو لاگو کرنے کے طریقہ کار میں مہارت حاصل کرنے سے ہمیں فوری طور پر اس خصوصیت کو لاگو کرنے کی اجازت ملتی ہے جیسے ہیلم ریلیز میں کلسٹر میں موجود وسائل کو اپنانا۔
ہیلم 2 میں ایک مسئلہ ہے: آپ چارٹ مینی فیسٹس میں کوئی ایسا وسیلہ شامل نہیں کر سکتے جو اس وسیلہ کو شروع سے دوبارہ بنائے بغیر پہلے سے موجود ہے (دیکھیں۔ , )۔ ہم نے ویرف کو رہائی کے لیے موجودہ وسائل کو قبول کرنا سکھایا۔ ایسا کرنے کے لیے، آپ کو چلنے والے کلسٹر سے وسائل کے موجودہ ورژن پر ایک تشریح انسٹال کرنے کی ضرورت ہے (مثال کے طور پر، استعمال کرتے ہوئے kubectl edit):
"werf.io/allow-adoption-by-release": RELEASE_NAMEاب وسائل کو چارٹ میں بیان کرنے کی ضرورت ہے اور اگلی بار جب werf مناسب نام کے ساتھ ریلیز تعینات کرے گا، تو موجودہ وسائل کو اس ریلیز میں قبول کر لیا جائے گا اور اس کے کنٹرول میں رہے گا۔ مزید برآں، ریلیز کے لیے وسائل کو قبول کرنے کے عمل میں، werf وسائل کی موجودہ حالت کو چل رہے کلسٹر سے چارٹ میں بیان کردہ ریاست تک لے آئے گا، اسی 3 طرفہ انضمام کے پیچ اور مطابقت پذیر وسائل کے اصول کا استعمال کرتے ہوئے۔
نوٹ: ترتیب WERF_THREE_WAY_MERGE_MODE وسائل کو اپنانے پر اثر انداز نہیں ہوتا ہے - اپنانے کی صورت میں، ایک 3 طرفہ انضمام پیچ ہمیشہ استعمال کیا جاتا ہے۔
تفصیلات - میں .
نتائج اور مستقبل کے منصوبے
مجھے امید ہے کہ اس مضمون کے بعد یہ واضح ہو گیا ہے کہ 3 طرفہ انضمام کے پیچ کیا ہیں اور وہ ان پر کیوں آئے ہیں۔ werf پروجیکٹ کی ترقی کے عملی نقطہ نظر سے، ان کا نفاذ ہیلم جیسی تعیناتی کو بہتر بنانے کی جانب ایک اور قدم تھا۔ اب آپ کنفیگریشن سنکرونائزیشن کے مسائل کے بارے میں بھول سکتے ہیں جو اکثر ہیلم 2 استعمال کرتے وقت پیدا ہوتے ہیں۔
ہیلم جیسی تعیناتیوں کے ساتھ اب بھی کچھ مسائل اور چیلنجز ہیں، جیسے کہ گو ٹیمپلیٹس کا استعمال، جن کو ہم حل کرتے رہیں گے۔
وسائل کو اپ ڈیٹ کرنے کے طریقوں اور اپنانے کے بارے میں بھی معلومات یہاں پر مل سکتی ہیں۔ .
ہیلم 3
خصوصی توجہ کے لائق دوسرے دن ہیلم کا ایک نیا بڑا ورژن - v3 - جو 3 طرفہ مرج پیچ بھی استعمال کرتا ہے اور ٹلر سے چھٹکارا پاتا ہے۔ ہیلم کے نئے ورژن کی ضرورت ہے۔ موجودہ تنصیبات کو نئے ریلیز اسٹوریج کی شکل میں تبدیل کرنے کے لیے۔
Werf، اس کے حصے کے لئے، فی الحال Tiller کے استعمال سے چھٹکارا حاصل کر چکا ہے، 3-way-merge پر تبدیل ہو گیا ہے اور شامل کیا گیا ہے ، جبکہ موجودہ ہیلم 2 تنصیبات کے ساتھ مطابقت رکھتا ہے (کوئی نقل مکانی اسکرپٹس کو انجام دینے کی ضرورت نہیں ہے)۔ لہذا، جب تک werf ہیلم 3 پر نہیں جاتا، werf استعمال کرنے والے Helm 3 کے مقابلے Helm 2 کے اہم فوائد سے محروم نہیں ہوتے ہیں (werf میں بھی ان کے پاس ہیں)۔
تاہم، ہیلم 3 کوڈ بیس میں werf کا سوئچ ناگزیر ہے اور مستقبل قریب میں ہو گا۔ غالباً یہ werf 1.1 یا werf 1.2 ہو گا (اس وقت، werf کا مرکزی ورژن 1.0 ہے؛ werf ورژن بنانے والے آلے کے بارے میں مزید معلومات کے لیے، دیکھیں )۔ اس وقت کے دوران ہیلم 3 کے پاس مستحکم ہونے کا وقت ہوگا۔
PS
ہمارے بلاگ پر بھی پڑھیں:
- werf میں اختراعات کے بارے میں نوٹوں کا ایک سلسلہ:
- «؛ "
- «؛ "
- «'.
- «؛ "
- «؛ "
- «'.
ماخذ: www.habr.com