Kubernetes ته د غوښتنلیکونو جوړولو او رسولو لپاره زموږ د خلاصې سرچینې GitOps CLI افادیت دی. لکه څنګه چې ژمنه شوې وه، werf ته د نویو ځانګړتیاوو د اضافه کولو او د دودیزو تګلارو بیاکتنې پیل په نښه کړ. اوس موږ خوښ یو چې د خوشې کولو v1.1 وړاندې کړو، کوم چې په پرمختګ کې یو لوی ګام او د راتلونکي لپاره بنسټ دی راټولونکی werf. نسخه اوس مهال په کې شتون لري .
د خوشې کولو اساس د مرحلې ذخیره کولو نوی جوړښت دی او د دواړو راټولونکو کار اصلاح کول (د سټیپل او ډاکرفیل لپاره). د ذخیره کولو نوی جوړښت په ورته کوربه کې د ډیری کوربه او موازي مجلسونو څخه د توزیع شوي مجلسونو پلي کولو امکان خلاصوي.
د کار اصلاح کول د مرحلې لاسلیکونو محاسبه کولو مرحله کې د غیر ضروري حسابونو څخه خلاصول او د فایل چیکسمونو محاسبه کولو میکانیزمونو ته ډیر مؤثره بدلول شامل دي. دا اصلاح د werf په کارولو سره د پروژې جوړولو اوسط وخت کموي. او بې کاره جوړونه، کله چې ټول مرحلې په زیرمه کې شتون ولري مرحلې - ذخیره کول، اوس واقعیا ګړندي دي. په ډیری مواردو کې، د جوړونې بیا پیل کول به د 1 ثانیو څخه لږ وخت ونیسي! دا د ټیمونو د کار په پروسه کې د مرحلو تصدیق کولو پروسیجرونو باندې هم پلي کیږي. werf deploy и werf run.
همدارنګه په دې خپرونه کې، د منځپانګې په واسطه د انځورونو د نښه کولو ستراتیژي ښکاره شوه - د منځپانګې پر بنسټ نښه کول، کوم چې اوس د ډیفالټ لخوا فعال شوی او یوازینی وړاندیز شوی.
راځئ چې په werf v1.1 کې کلیدي نوښتونو ته نږدې کتنه وکړو، او په ورته وخت کې د راتلونکي لپاره د پالنونو په اړه تاسو ته ووایو.
په werf v1.1 کې څه بدلون راغلی؟
د کیچ څخه د مرحلو غوره کولو لپاره د نوي پړاو نومونې بڼه او الګوریتم
د نوي پړاو نوم نسل قاعده. اوس هر پړاو جوړونه د ځانګړي مرحلې نوم رامینځته کوي ، کوم چې له 2 برخو څخه جوړ دی: یو لاسلیک (لکه څنګه چې دا په v1.0 کې و) او یو ځانګړی لنډمهاله پیژندونکی.
د مثال په توګه، د بشپړ مرحلې عکس نوم ممکن داسې ښکاري:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
یا په عمومي توګه:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
دلته:
-
SIGNATUREد مرحلې لاسلیک دی ، کوم چې د مرحلې مینځپانګې پیژندونکي استازیتوب کوي او په Git کې د ترمیم تاریخ پورې اړه لري چې د دې مینځپانګې لامل شوی؛ -
TIMESTAMP_MILLISECیو تضمین شوی ځانګړی عکس پیژندونکی دی چې د نوي عکس جوړولو په وخت کې رامینځته کیږي.
د کیچ څخه د مرحلو غوره کولو لپاره الګوریتم د Git ژمنو اړیکو چیک کولو پراساس دی:
- Werf د یوې ټاکلې مرحلې لاسلیک محاسبه کوي.
- В مرحلې - ذخیره کول د ورکړل شوي لاسلیک لپاره ممکن څو مرحلې وي. Werf ټول هغه مرحلې غوره کوي چې د لاسلیک سره سمون لري.
- که اوسنی مرحله د Git سره تړلې وي (git-archive، د ګیټ پیچونو سره دودیز مرحله:
install,beforeSetup,setup; یا git-latest-patch)، بیا werf یوازې هغه مرحلې غوره کوي چې د ژمنې سره تړاو لري چې د اوسني ژمنې لرغونی دی (د کوم لپاره چې جوړونه ویل کیږي). - د پاتې مناسبو مرحلو څخه، یو غوره شوی - د جوړولو نیټې له مخې ترټولو زوړ.
د مختلف Git څانګو لپاره مرحله کولی شي ورته لاسلیک ولري. مګر werf به د مختلف څانګو سره تړلې کیچ د دې څانګو ترمینځ د کارولو مخه ونیسي ، حتی که لاسلیکونه هم ورته وي.
.
د مرحلې ذخیره کې مرحلو رامینځته کولو او خوندي کولو لپاره نوی الګوریتم
که چیرې، کله چې د زیرمې څخه مرحلې غوره کړئ، werf مناسب مرحله ونه موندل، نو بیا د نوي پړاو د راټولولو پروسه پیل کیږي.
په یاد ولرئ چې ډیری پروسې (په یو یا ډیرو میزبانونو کې) کولی شي په ورته وخت کې د ورته مرحلې جوړول پیل کړي. Werf د خوشبین بلاک کولو الګوریتم کاروي مرحلې - ذخیره کول د تازه راټول شوي عکس د خوندي کولو په وخت کې مرحلې - ذخیره کول. په دې توګه، کله چې د نوي مرحلې جوړونه چمتو وي، werf بلاکونه مرحلې - ذخیره کول او هلته یو تازه راټول شوی عکس خوندي کوي یوازې هغه وخت چې مناسب عکس شتون نلري (د لاسلیک او نورو پیرامیټونو په واسطه - د کیچ څخه د مرحلو غوره کولو لپاره نوی الګوریتم وګورئ).
یو تازه راټول شوی عکس د یو ځانګړي پیژندونکي لخوا تضمین شوی TIMESTAMP_MILLISEC (د مرحلې د نومولو نوې بڼه وګورئ). په صورت کې مرحلې - ذخیره کول یو مناسب عکس به وموندل شي، ویرف به تازه ترتیب شوی عکس رد کړي او د کیچ څخه به عکس وکاروي.
په بل عبارت: د عکس جوړولو پای ته رسیدو لومړۍ پروسه (تر ټولو ګړندۍ) به دا حق ترلاسه کړي چې دا په مرحلو کې ذخیره کړي (او بیا دا یو واحد عکس دی چې د ټولو ودانیو لپاره به کارول کیږي). د جوړیدو ورو پروسه به هیڅکله د اوسني مرحلې د جوړونې پایلو خوندي کولو او راتلونکي جوړونې ته حرکت کولو څخه ګړندۍ پروسه بنده نه کړي.
.
د ډاکرفایل جوړونکي فعالیت ښه شوی
په اوس وخت کې، د ډاکر فایل څخه جوړ شوي عکس لپاره د مرحلو پایپ لاین یو مرحلې لري - dockerfile. کله چې د لاسلیک محاسبه کول، د فایلونو چک سم محاسبه کیږي context، کوم چې به د مجلس پرمهال وکارول شي. د دې پرمختګ څخه دمخه، werf په تکراري توګه د ټولو فایلونو له لارې وګرځید او د هرې فایل د شرایطو او حالت لنډیز کولو سره یې چکسم ترلاسه کړ. د v1.1 سره پیل کول، werf کولی شي د ګیټ ذخیره کې ذخیره شوي حساب شوي چکسمونه وکاروي.
د الګوریتم پر بنسټ ولاړ دی . الګوریتم د حساب ریکارډونه په پام کې نیسي .dockerignore او یوازې د اړتیا په وخت کې د فایل ونې په تکراري ډول تیریږي. په دې توګه، موږ د فایل سیسټم لوستلو، او د اندازې په اړه د الګوریتم انحصار له مینځه وړل. context د پام وړ نه دی.
الګوریتم هم نه تعقیب شوي فایلونه ګوري او که اړتیا وي، دوی په چیکسم کې په پام کې نیسي.
د فایلونو واردولو پر مهال ښه فعالیت
د werf v1.1 نسخې د rsync سرور کاروي کله چې . پخوا، واردول د کوربه سیسټم څخه د ډایرکټر ماونټ په کارولو سره په دوه مرحلو کې ترسره کیدل.
په macOS کې د وارداتو فعالیت نور د ډاکر حجمونو لخوا محدود ندي ، او واردات د لینکس او وینډوز په څیر په ورته وخت کې بشپړیږي.
د منځپانګې پر بنسټ نښه کول
Werf v1.1 د عکس مینځپانګې لخوا د تش په نامه ټاګ کولو ملاتړ کوي - د منځپانګې پر بنسټ نښه کول. د پایله شوي ډاکر عکسونو ټاګونه د دې عکسونو مینځپانګې پورې اړه لري.
کله چې کمانډ چلوي werf publish --tags-by-stages-signature او یا werf ci-env --tagging-strategy=stages-signature د تش په نامه عکسونه خپاره کړل مرحله لاسلیک انځور هر عکس د دې عکس د مرحلو د خپل لاسلیک سره نښه شوی ، کوم چې د ورته مقرراتو سره سم محاسبه کیږي د هرې مرحلې منظم لاسلیک په جلا توګه ، مګر د عکس عمومي پیژندونکی دی.
د عکس مرحلو لاسلیک پدې پورې اړه لري:
- د دې انځور منځپانګه؛
- د Git بدلونونو تاریخ چې د دې مینځپانګې لامل شوی.
د Git ذخیره تل د ډمي ژمنې لري چې د عکس فایلونو مینځپانګې نه بدلوي. د مثال په توګه ، یوازې د نظرونو سره ژمنې کوي یا ژمنې ضمیمه کوي ، یا ژمنه کوي چې په Git کې هغه فایلونه بدلوي چې عکس ته به وارد نه شي.
کله چې د مینځپانګې پراساس ټګینګ وکاروئ ، د عکس نوم کې بدلونونو له امله په کوبرنیټس کې د غوښتنلیک پوډونو غیر ضروري بیا پیل کولو ستونزې حل کیږي ، حتی که د عکس مینځپانګه بدله شوې نه وي. په هرصورت ، دا یو له هغه دلیلونو څخه دی چې په یو واحد Git ذخیره کې د یو غوښتنلیک ډیری مایکرو خدماتو ذخیره کولو مخه نیسي.
همچنان ، د مینځپانګې پراساس ټګینګ د Git څانګو کې د ټاګ کولو په پرتله خورا د باور وړ ټاګ کولو میتود دی ، ځکه چې د پایلو عکسونو مینځپانګه په هغه ترتیب پورې اړه نلري چې د ورته څانګې ډیری ژمنې راټولولو لپاره د CI سیسټم کې پایپ لاینونه اجرا کیږي.
مهم: له اوس څخه پیل مرحلې - لاسلیک دی یوازینی وړاندیز شوی د نښه کولو ستراتیژي. دا به په کمانډ کې د ډیفالټ لخوا کارول کیږي werf ci-env (مګر که تاسو په ښکاره ډول د مختلف ټاګ کولو سکیم مشخص نه کړئ).
. یوه جلا خپرونه به هم دې خصوصیت ته وقف شي. تازه شوی (اپریل 3): مقاله له توضیحاتو سره .
د ننوتلو کچه
کارونکي اوس فرصت لري چې محصول کنټرول کړي، د ننوتلو کچه تنظیم کړي او د ډیبګ کولو معلوماتو سره کار وکړي. اختیارونه اضافه کړل --log-quiet, --log-verbose, --log-debug.
په ډیفالټ کې، محصول لږترلږه معلومات لري:
کله چې د فعل محصول کاروئ (--log-verbose) تاسو کولی شئ وګورئ چې werf څنګه کار کوي:
تفصيلي محصول (--log-debug)، د werf debugging معلوماتو سربیره، د کارول شوي کتابتونونو لاګونه هم لري. د مثال په توګه ، تاسو کولی شئ وګورئ چې د ډاکر راجسټری سره څنګه تعامل رامینځته کیږي ، او هغه ځایونه هم ثبت کړئ چیرې چې د پام وړ وخت مصرف شوی وي:
راتلونکي پلانونه
پاملرنه وکړئ! لاندې تشریح شوي اختیارونه په نښه شوي v1.1 په دې نسخه کې به شتون ولري، ډیری یې په نږدې راتلونکي کې. تازه معلومات به د اتوماتیک تازه معلوماتو له لارې راشي . دا ځانګړتیاوې د v1.1 دندو باثباته برخه اغیزه نه کوي؛ د دوی بڼه به په موجوده تشکیلاتو کې د لاسي کارونکي مداخلې ته اړتیا ونلري.
د مختلف ډاکر راجسټری پلي کولو لپاره بشپړ ملاتړ (نوی)
- نسخه: v1.1
- نیټې: مارچ
هدف د کارونکي لپاره دی چې د werf کارولو پرمهال پرته له کوم محدودیت څخه دودیز تطبیق وکاروي.
اوس مهال، موږ د حلونو لاندې سیټ په ګوته کړي چې موږ یې د بشپړ ملاتړ تضمین کوو:
- ډیفالټ (کتابتون/رجسټری)*،
- AWS ECR
- Azure*,
- د ډاکر مرکز
- GCR*,
- د GitHub کڅوړې
- د GitLab راجستر *،
- بندر*,
- کوی.
هغه حلونه چې اوس مهال د werf لخوا په بشپړ ډول ملاتړ کیږي د ستوري سره نښه شوي. د نورو لپاره ملاتړ شتون لري، مګر د محدودیتونو سره.
دوه اصلي ستونزې په ګوته کیدی شي:
- ځینې حلونه د ډاکر راجسټري API په کارولو سره د ټاګ لرې کولو ملاتړ نه کوي ، د کاروونکو مخه نیسي د werf اتوماتیک پاکولو کارولو څخه. دا د AWS ECR، Docker Hub، او GitHub کڅوړو لپاره ریښتیا ده.
- ځینې حلونه د تش په نامه نیسټ شوي ذخیره (Docker Hub، GitHub Packages او Quay) ملاتړ نه کوي، مګر کاروونکي باید دا په لاسي ډول د UI یا API (AWS ECR) په کارولو سره رامینځته کړي.
موږ دا او نورې ستونزې د حل اصلي APIs په کارولو سره حل کوو. پدې دنده کې د هر یو لپاره د ازموینو سره د werf عملیاتو بشپړ دورې پوښل هم شامل دي.
توزیع شوي انځور جوړونه (↑)
- نسخه: v1.2 v1.1 (د دې خصوصیت پلي کولو لومړیتوب ډیر شوی)
- نیټې: مارچ - اپریل
په اوس وخت کې، werf v1.0 او v1.1 یوازې په یو وقف شوي کوربه کې کارول کیدی شي د عکسونو جوړولو او خپرولو عملیات او کوبرنیټس ته د غوښتنلیک ځای پرځای کولو لپاره.
د werf د توزیع شوي کار امکانات خلاصولو لپاره، کله چې په کوبرنیټس کې د غوښتنلیکونو جوړول او ځای په ځای کول په څو خپلسري میزبانونو کې پیل کیږي او دا کوربه د جوړونو (موقتي چلونکو) ترمنځ خپل حالت نه خوندي کوي، ویرف ته اړتیا ده چې د کارولو وړتیا پلي کړي. د ډاکر راجسټری د مرحلې پلورنځي په توګه.
پخوا، کله چې د ویرف پروژه لاهم د ډپ په نوم یادیږي، دا ورته فرصت درلود. په هرصورت، موږ د یو شمیر مسلو سره مخ شوي یو چې باید په پام کې ونیول شي کله چې په werf کې د دې فعالیت پلي کول.
تبصره. دا ځانګړتیا د راټولونکي ته اړتیا نلري چې د کوبرنیټس پوډونو دننه کار وکړي، ځکه د دې کولو لپاره ، تاسو اړتیا لرئ په محلي ډاکر سرور باندې له انحصار څخه ځان خلاص کړئ (د کوبرنیټس پوډ کې ځایی ډاکر سرور ته لاسرسی شتون نلري ، ځکه چې پروسه پخپله په کانټینر کې روانه ده ، او ویرف نه ملاتړ کوي او نه به یې ملاتړ وکړي. په شبکه کې د ډاکر سرور سره کار کول). د Kubernetes چلولو لپاره ملاتړ به په جلا توګه پلي شي.
د GitHub عملونو لپاره رسمي ملاتړ (نوی)
- نسخه: v1.1
- نیټې: مارچ
د werf اسناد شامل دي (برخې ماخذ и الرښوونه)، په بیله بیا د werf سره کار کولو لپاره رسمي GitHub عمل.
سربیره پردې ، دا به ویرف ته اجازه ورکړي چې په لنډمهاله منډو کار وکړي.
د CI سیسټم سره د کارونکي متقابل عمل میکانیکونه به د غوښتنلیکونو رامینځته کولو / رول کولو لپاره ځینې کړنې پیل کولو لپاره د پل غوښتنلیکونو کې د لیبلونو ایښودلو پراساس وي.
د werf (↓) سره د غوښتنلیکونو ځایی پراختیا او پلي کول
- نسخه: v1.1
- نیټې: جنوري - فبروري اپریل
اصلي هدف دا دی چې په محلي او تولید کې د غوښتنلیکونو ځای په ځای کولو لپاره یو واحد متحد ترتیب ترلاسه کړي، پرته له پیچلو کړنو پرته، د بکس څخه بهر.
werf هم اړین دی چې یو عملیاتي حالت ولري په کوم کې چې دا به د غوښتنلیک کوډ ایډیټ کولو لپاره اسانه وي او سمدلاسه د ډیبګ کولو لپاره د روان غوښتنلیک څخه فیډبیک ترلاسه کړي.
د پاکولو نوی الګوریتم (نوی)
- نسخه: v1.1
- نیټې: اپریل
په کړنلارې کې د werf v1.1 اوسنۍ نسخه کې cleanup د مینځپانګې پراساس ټګ کولو سکیم لپاره د عکسونو پاکولو لپاره هیڅ شرایط شتون نلري - دا عکسونه به راټول شي.
همچنان ، د werf اوسنۍ نسخه (v1.0 او v1.1) د ټاګ کولو سکیمونو لاندې خپاره شوي عکسونو لپاره د پاکولو مختلف پالیسۍ کاروي: Git برانچ ، Git ټاګ یا Git ژمن.
په Git کې د ژمنو تاریخ پراساس د عکسونو پاکولو لپاره نوی الګوریتم ، د ټولو ټاګ کولو سکیمونو لپاره متحد شوی ، اختراع شوی:
- د هر git HEAD (څانګو او ټاګونو) لپاره د N1 خورا وروستي ژمنو سره تړلي د N2 څخه ډیر عکسونه مه ساتئ.
- د هر ګیټ هیډ (څانګو او ټاګونو) لپاره د N1 خورا وروستي ژمنو سره تړلي د N2 مرحلې عکسونو څخه ډیر مه ذخیره کړئ.
- ټول هغه عکسونه ذخیره کړئ کوم چې د هر Kubernetes کلستر سرچینو کې کارول کیږي (د ترتیب فایل ټول کیوب شرایط او د نوم ځایونه سکین شوي؛ تاسو کولی شئ دا چلند د ځانګړي اختیارونو سره محدود کړئ).
- ټول هغه عکسونه ذخیره کړئ چې د سرچینې په ترتیب کې کارول کیږي د هیلم ریلیزونو کې خوندي شوي.
- یو عکس حذف کیدی شي که چیرې دا د git څخه د هیڅ HEAD سره تړاو نلري (د مثال په توګه ، ځکه چې ورته HEAD پخپله حذف شوی و) او د کبرنیټس کلستر او هیلم ریلیزونو کې په هیڅ ډول څرګندونو کې نه کارول کیږي.
موازي انځور جوړونه (↓)
- نسخه: v1.1
- نیټې: جنوري - فبروري اپریل *
د werf اوسنی نسخه هغه انځورونه او آثار راټولوي چې په کې تشریح شوي werf.yamlپه ترتیب سره. دا اړینه ده چې د عکسونو او هنري اثارو د خپلواکو مرحلو راټولولو پروسه موازي کړي ، او همدارنګه اسانه او معلوماتي محصول چمتو کړي.
* یادونه: وروستۍ نیټه د توزیع شوي مجلس پلي کولو لپاره د لومړیتوب د زیاتوالي له امله لیږدول شوې ، کوم چې به د افقی اندازه کولو نور وړتیاوې اضافه کړي ، په بیله بیا د GitHub عملونو سره د ویرف کارول. موازي مجلس د اصلاح کولو راتلونکی ګام دی، د یوې پروژې راټولولو پر مهال عمودی توزیع چمتو کوي.
هیلم 3 ته لیږد (↓)
- نسخه: v1.2
- نیټې: فبروري - مارچ می*
نوي کوډبیس ته مهاجرت شامل دي او د موجوده تاسیساتو د مهاجرت لپاره ثابت، اسانه لار.
* یادونه: هیلم 3 ته بدلول به په ویرف کې د پام وړ ځانګړتیاوې ونه اضافه کړي، ځکه چې د هیلم 3 ټولې کلیدي ځانګړتیاوې (3-طریقه یوځای کول او هیڅ ټیلر نه) دمخه په ویرف کې پلي شوي. سربیره پردې، werf لري سربیره پردې چې اشاره شوې. په هرصورت، دا لیږد زموږ په پلانونو کې پاتې دی او پلي کیږي.
Jsonnet د Kubernetes تشکیلاتو تشریح کولو لپاره (↓)
- نسخه: v1.2
- نیټې: جنوري - فبروري اپریل - می
Werf به د Jsonnet ب formatه کې د Kubernetes لپاره د تشکیلاتو توضیحاتو ملاتړ وکړي. په ورته وخت کې، werf به د هیلم سره مطابقت ولري او د توضیحي بڼه انتخاب به وي.
دلیل یې دا دی چې د ګو ټیمپلیټونه، د ډیری خلکو په وینا، د ننوتلو لوړ خنډ لري، او د دې ټیمپلیټونو کوډ پوهیدل هم زیان لري.
د نورو Kubernetes ترتیب کولو توضیحي سیسټمونو معرفي کولو امکان هم په پام کې نیول کیږي (د مثال په توګه، Kustomize).
د Kubernetes دننه کار کول (↓)
- نسخه: v1.2
- نیټې: اپریل - می می - جون
هدف: ډاډ ترلاسه کړئ چې عکسونه جوړ شوي او غوښتنلیک په کوبرنیټس کې د چلونکو په کارولو سره سپارل شوی. هغوی. نوي عکسونه په مستقیم ډول د Kubernetes پوډونو څخه جوړ ، خپاره ، پاک او ځای په ځای کیدی شي.
د دې وړتیا پلي کولو لپاره ، تاسو باید لومړی د توزیع شوي عکسونو رامینځته کولو وړتیا ولرئ (پورته ټکی وګورئ).
دا د ډاکر سرور پرته د جوړونکي عملیاتي حالت لپاره ملاتړ ته هم اړتیا لري (د مثال په توګه د کانیکو په څیر جوړ یا په کاروونکي ځای کې جوړ کړئ).
Werf به نه یوازې د Dockerfile سره په کوبرنیټس کې د ودانولو ملاتړ وکړي ، بلکه د دې سټیپل بلډر سره به د ډیریدونکي بیارغونې او ځواب وړ سره.
د خلاص پرمختګ په لور یو ګام
موږ له خپلې ټولنې سره مینه لرو(, ) او موږ غواړو ډیر او ډیر خلک د ویرف په ښه کولو کې مرسته وکړي، په هغه لوري پوه شي چې موږ یې حرکت کوو، او په پراختیا کې برخه اخلي.
په دې وروستیو کې پریکړه شوې وه چې بدل شي زموږ د ټیم کاري بهیر څرګندولو لپاره. اوس تاسو کولی شئ په لاندې برخو کې سمدستي پلانونه او اوسني کارونه وګورئ:
- ;
- ;
- ;
- .
د مسلو سره ډیر کار شوی دی:
- غیرمنطقي کسان لرې کړل.
- شته یې په کافي اندازه او توضیحاتو سره په یوه واحد شکل کې راوړل کیږي.
- د نظرونو او وړاندیزونو سره نوې مسلې اضافه شوي.
څنګه v1.1 نسخه فعال کړئ
نسخه اوس مهال په کې شتون لري (په چینلونو کې باثباته и ډبرينه ریلیزونه به د ثبات په صورت کې څرګند شي، په هرصورت ea پخپله لا دمخه د کارولو لپاره کافي مستحکم دی ، ځکه د چینلونو له لارې تیر شو الفا и بيټا). فعال شوی په لاندې ډول:
source $(multiwerf use 1.1 ea)
werf COMMAND ...پایلې
د سټیپیل او ډاکرفایل جوړونکو لپاره د نوي مرحلې ذخیره کولو جوړښت او د جوړونکي اصلاح کول په ویرف کې د توزیع شوي او موازي ودانیو پلي کولو امکان خلاصوي. دا ب featuresې به ډیر ژر په ورته v1.1 ریلیز کې څرګند شي او د اتوماتیک تازه کولو میکانیزم له لارې به په اوتومات ډول شتون ولري (د کاروونکو لپاره ).
پدې خپرونه کې، د عکس مینځپانګې پراساس د ټاګ کولو ستراتیژي اضافه شوې - د منځپانګې پر بنسټ نښه کول، کوم چې د ډیفالټ ستراتیژۍ بدل شوی. د اصلي کمانډ لاګ هم بیا کار شوی دی: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
بل مهم ګام د ویشل شوي مجلسونو اضافه کول دي. توزیع شوي جوړونه د v1.0 راهیسې د موازي ودانیو په پرتله لوړ لومړیتوب ګرځیدلی ځکه چې دوی werf ته ډیر ارزښت اضافه کوي: د جوړونکو عمودی اندازه کول او په مختلف CI/CD سیسټمونو کې د لنډمهاله جوړونکو لپاره ملاتړ ، او همدارنګه د GitHub کړنو لپاره د رسمي ملاتړ کولو وړتیا. . له همدې امله، د موازي غونډو لپاره د پلي کولو نیټه بدله شوه. په هرصورت، موږ کار کوو چې دواړه امکانات ژر تر ژره پلي کړو.
خبرونه تعقیب کړئ! او له موږ سره لیدنه مه هیروئ د یوې مسلې رامینځته کولو لپاره ، یو موجود ومومئ او پلس اضافه کړئ ، PR رامینځته کړئ ، یا په ساده ډول د پروژې پرمختګ وګورئ.
PS
زموږ په بلاګ کې هم ولولئ:
- «»
- «»
- په ویرف کې د نوښتونو په اړه د یادښتونو لړۍ:
- «»
- «»
- «»
- «".
سرچینه: www.habr.com