нь манай нээлттэй эхийн GitOps CLI хэрэгсэл юм. Амласан ёсоороо, werf-д шинэ боломжуудыг нэмж, уламжлалт хандлагыг шинэчлэх эхлэлийг тавьсан. Одоо бид v1.1 хувилбарыг танилцуулж байгаадаа баяртай байна, энэ нь хөгжлийн томоохон алхам бөгөөд ирээдүйн үндэс суурь юм цуглуулагч верф. Энэ хувилбар нь одоогоор бэлэн байна .
Энэхүү хувилбарын үндэс нь тайзны хадгалалтын шинэ архитектур, цуглуулагчийн ажлыг оновчтой болгох явдал юм (Stapel болон Dockerfile-ийн хувьд). Хадгалалтын шинэ архитектур нь олон хостоос тархсан угсралт, нэг хост дээр зэрэгцээ угсралт хийх боломжийг нээж өгдөг.
Ажлыг оновчтой болгох нь үе шатны гарын үсгийг тооцоолох үе шатанд шаардлагагүй тооцооллоос ангижрах, файлын хяналтын нийлбэрийг тооцоолох механизмыг илүү үр ашигтай болгон өөрчлөх явдал юм. Энэхүү оновчлол нь 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Энэ нь тайзны агуулгын тодорхойлогчийг илэрхийлдэг тайзны гарын үсэг бөгөөд энэ агуулгад хүргэсэн Гит дэх засварын түүхээс хамаарна; -
TIMESTAMP_MILLISECнь шинэ зураг бүтээх үед үүсдэг баталгаатай өвөрмөц дүрс танигч юм.
Кэшээс үе шатуудыг сонгох алгоритм нь Git commits-ийн харилцааг шалгахад суурилдаг.
- Werf нь тодорхой үе шатны гарын үсгийг тооцоолдог.
- В үе шатууд-хадгалалт Өгөгдсөн гарын үсэг хэд хэдэн үе шаттай байж болно. Werf нь гарын үсэгтэй тохирох бүх үе шатыг сонгодог.
- Хэрэв одоогийн үе шат нь Git-тэй холбогдсон бол (git-archive, Git засваруудтай захиалгат үе шат:
install,beforeSetup,setup; эсвэл git-latest-patch), дараа нь werf нь зөвхөн одоогийн амлалтын өвөг болох амлалттай холбоотой үе шатуудыг сонгоно (үүнийг бүтээх гэж нэрлэдэг). - Үлдсэн тохиромжтой үе шатуудаас нэгийг нь сонгосон - үүсгэсэн огноогоор хамгийн эртний нь.
Git-ийн өөр өөр салбаруудад зориулсан шат нь ижил гарын үсэгтэй байж болно. Гэхдээ werf нь гарын үсэг таарч байсан ч өөр өөр салбаруудтай холбоотой кэшийг эдгээр салбаруудын хооронд ашиглахаас сэргийлнэ.
.
Тайзны хадгалалт дахь үе шатуудыг үүсгэх, хадгалах шинэ алгоритм
Хэрэв кэшээс үе шатуудыг сонгохдоо werf тохирох үе шатыг олоогүй бол шинэ шатыг угсрах үйл явцыг эхлүүлнэ.
Олон процессууд (нэг эсвэл хэд хэдэн хост дээр) ижил үе шатыг ойролцоогоор ижил хугацаанд барьж эхлэх боломжтой гэдгийг анхаарна уу. Werf нь өөдрөг блоклох алгоритмыг ашигладаг үе шатууд-хадгалалт шинээр цуглуулсан зургийг хадгалах мөчид үе шатууд-хадгалалт. Ингэснээр шинэ үе шат бэлэн болмогц werf блокууд үе шатууд-хадгалалт Тэнд тохирох зураг байхгүй тохиолдолд л шинээр цуглуулсан зургийг хадгална (гарын үсэг болон бусад параметрүүдээр - кэшээс үе шатуудыг сонгох шинэ алгоритмыг үзнэ үү).
Шинээр угсарсан зураг нь өвөрмөц танигчтай байх баталгаатай TIMESTAMP_MILLISEC (тайзны нэрийн шинэ форматыг үзнэ үү). Оруулсан тохиолдолд үе шатууд-хадгалалт тохирох зураг олдвол werf нь шинээр эмхэтгэсэн зургийг хаяж, кэшээс зургийг ашиглана.
Өөрөөр хэлбэл, зургийг барьж дуусгах эхний үйл явц (хамгийн хурдан нь) нь түүнийг үе шаттайгаар хадгалах эрхийг авах болно (дараа нь энэ зургийг бүх бүтээхэд ашиглах болно). Удаан барих процесс нь одоогийн үе шатны бүтээн байгуулалтын үр дүнг хадгалах, дараагийн бүтээц рүү шилжихэд илүү хурдан процессыг хэзээ ч хориглохгүй.
.
Dockerfile бүтээгчийн гүйцэтгэл сайжирсан
Одоогийн байдлаар Dockerfile-ээс бүтээгдсэн зургийн үе шатуудын шугам нь нэг үе шатаас бүрдэнэ - dockerfile. Гарын үсгийг тооцоолохдоо файлуудын хяналтын нийлбэрийг тооцдог context, угсралтын явцад ашиглах болно. Энэхүү сайжруулалтыг хийхээс өмнө werf бүх файлуудыг давтаж үзэж, файл бүрийн контекст болон горимыг нэгтгэн шалгах нийлбэрийг олж авсан. V1.1-ээс эхлэн werf нь Git репозиторт хадгалагдсан тооцоолсон шалгах нийлбэрүүдийг ашиглаж болно.
Алгоритм нь дээр үндэслэсэн болно . Алгоритм нь бүртгэлийг харгалзан үздэг .dockerignore шаардлагатай үед л файлын модыг рекурсиваар дайран өнгөрдөг. Тиймээс бид файлын системийг унших, алгоритмын хэмжээнээс хамаарах хамаарлаас салсан. context ач холбогдолгүй юм.
Алгоритм нь мөн хяналтгүй файлуудыг шалгаж, шаардлагатай бол шалгах нийлбэрт харгалзан үздэг.
Файл импортлох үед гүйцэтгэл сайжирсан
Werf v1.1-ийн хувилбарууд нь rsync серверийг ашигладаг . Өмнө нь импортыг хост системээс лавлах холбох хэрэгслийг ашиглан хоёр үе шаттайгаар хийдэг байсан.
MacOS дээрх импортын гүйцэтгэл нь Docker-ийн хэмжээгээр хязгаарлагдахаа больсон бөгөөд импортыг Линукс болон Windows-тэй ижил хугацаанд гүйцэтгэнэ.
Контент дээр суурилсан шошго
Werf v1.1 нь зургийн агуулгаар тэмдэглэгээг дэмждэг - агуулгад суурилсан шошго. Үүссэн Docker зургийн шошго нь эдгээр зургийн агуулгаас хамаарна.
Командыг ажиллуулах үед werf publish --tags-by-stages-signature буюу werf ci-env --tagging-strategy=stages-signature гэж нэрлэгддэг зургуудыг нийтэлсэн тайзны гарын үсэг зураг. Зураг бүр дээр тус тусад нь дүрмийн дагуу тооцоолсон энэ зургийн үе шатуудын өөрийн гэсэн гарын үсгээр тэмдэглэгдсэн байдаг, гэхдээ зургийн ерөнхий таних тэмдэг юм.
Зургийн үе шатуудын гарын үсэг нь дараахь зүйлээс хамаарна.
- энэ зургийн агуулга;
- Энэ агуулгыг бий болгосон Гит өөрчлөлтүүдийн түүхүүд.
Git репозитор нь зургийн файлын агуулгыг өөрчилдөггүй хуурамч үүрэг даалгавартай байдаг. Жишээлбэл, зөвхөн тайлбар эсвэл нэгтгэх үүрэг бүхий амлалтууд эсвэл Git дээрх эдгээр файлуудыг өөрчилдөг амлалтууд нь зураг руу импортлогдохгүй.
Агуулгад суурилсан шошгололтыг ашиглах үед зургийн нэр өөрчлөгдсөний улмаас Кубернетес дэх програмын самбарыг шаардлагагүй дахин эхлүүлэх асуудал, зургийн агуулга өөрчлөгдөөгүй байсан ч шийдэгддэг. Дашрамд хэлэхэд, энэ нь нэг програмын олон микро үйлчилгээг нэг Git репозиторид хадгалахаас сэргийлж байгаа шалтгаануудын нэг юм.
Мөн агуулгад суурилсан шошго нь Git-ийн салбарууд дээр тэмдэглэгээ хийхээс илүү найдвартай шошголох арга юм, учир нь үүссэн зургийн агуулга нь нэг салбарын олон коммитуудыг угсрах CI систем дэх дамжуулах шугамуудыг гүйцэтгэх дарааллаас хамаардаггүй.
чухал: одооноос эхлэн үе шат-гарын үсэг Байна уу цорын ганц санал болгож буй шошголох стратеги. Энэ нь тушаалд анхдагчаар ашиглагдах болно werf ci-env (хэрэв та өөр тэмдэглэгээний схемийг тодорхой заагаагүй бол).
. Тусдаа нийтлэлийг мөн энэ онцлогт зориулах болно. ШИНЭЧЛЭГДСЭН (3-р сарын XNUMX): Дэлгэрэнгүй мэдээлэл бүхий нийтлэл .
Бүртгэлийн түвшин
Хэрэглэгч одоо гаралтыг хянах, бүртгэлийн түвшинг тохируулах, дибаг хийх мэдээлэлтэй ажиллах боломжтой болсон. Сонголтуудыг нэмсэн --log-quiet, --log-verbose, --log-debug.
Анхдагч байдлаар, гаралт нь хамгийн бага мэдээллийг агуулна:
Нарийвчилсан гаралтыг ашиглах үед (--log-verbose) та werf хэрхэн ажилладагийг харж болно:
Нарийвчилсан гаралт (--log-debug), werf дибаг хийх мэдээллээс гадна ашигласан номын сангийн бүртгэлийг агуулдаг. Жишээлбэл, та Docker Registry-тэй хэрхэн харьцаж байгааг харж, мөн ихээхэн хэмжээний цаг зарцуулсан газруудыг тэмдэглэж болно.
Цаашдын төлөвлөгөө
Анхаар Доор тайлбарласан сонголтуудыг тэмдэглэв v1.1 ойрын ирээдүйд ихэнх нь энэ хувилбарт гарах болно. Автомат шинэчлэлтүүдээр шинэчлэлтүүд ирэх болно . Эдгээр функцууд нь v1.1 функцуудын тогтвортой хэсэгт нөлөөлөхгүй бөгөөд тэдгээрийн харагдах байдал нь одоо байгаа тохиргоонд хэрэглэгчийн гараар хөндлөнгөөс оролцох шаардлагагүй болно.
Төрөл бүрийн Docker Registry хэрэгжилтийг бүрэн дэмжих (ШИНЭ)
- Хувилбар: v1.1
- Огноо: Гуравдугаар сар
Зорилго нь хэрэглэгч werf-г ашиглахдаа ямар ч хязгаарлалтгүйгээр өөрчлөн хэрэгжүүлэлтийг ашиглах явдал юм.
Одоогоор бид бүрэн дэмжлэг үзүүлэх дараах шийдлүүдийг тодорхойлсон.
- Өгөгдмөл (номын сан/бүртгэл)*,
- AWS ECR
- Азур*,
- Docker Hub
- GCR*,
- GitHub багцууд
- GitLab Бүртгэл *,
- Боомт*,
- Хүрээ.
Одоогоор werf-ээр бүрэн дэмжигдсэн шийдлүүд одоор тэмдэглэгдсэн байна. Бусдын хувьд дэмжлэг байдаг, гэхдээ хязгаарлалттай.
Хоёр үндсэн асуудлыг тодорхойлж болно:
- Зарим шийдэл нь Docker Registry API ашиглан шошгыг устгахыг дэмждэггүй тул хэрэглэгчдэд werf-ийн автомат цэвэрлэгээг ашиглахаас сэргийлдэг. Энэ нь AWS ECR, Docker Hub болон GitHub багцуудад үнэн юм.
- Зарим шийдэл нь үүрлэсэн репозиторуудыг (Docker Hub, GitHub багцууд болон Quay) дэмждэггүй эсвэл дэмждэггүй ч хэрэглэгч тэдгээрийг UI эсвэл API (AWS ECR) ашиглан гараар үүсгэх ёстой.
Бид эдгээр болон бусад асуудлыг шийдлийн эх API ашиглан шийдвэрлэх гэж байна. Энэ даалгаварт верфийн үйл ажиллагааны бүх мөчлөгийг тус бүрд нь туршиж үзэхийг багтаасан болно.
Тархсан зураг бүтээх (↑)
- Хувилбар: v1.2 v1.1 (энэ функцийг хэрэгжүүлэх тэргүүлэх чиглэл нэмэгдсэн)
- Хугацаа: Гуравдугаар сараас дөрөвдүгээр сар
Одоогоор werf v1.0 болон v1.1-ийг зөвхөн нэг зориулалтын хост дээр зураг бүтээх, нийтлэх, Kubernetes-д аппликейшн байршуулах зэрэгт ашиглах боломжтой.
Кубернетес дэх програмуудыг хэд хэдэн дурын хостууд дээр суулгаж, байршуулах ажлыг эхлүүлж, эдгээр хостууд бүтэц (түр зуурын гүйгч) хооронд төлөвөө хадгалахгүй байх үед werf-ийн тархсан ажлын боломжийг нээхийн тулд werf нь ашиглах чадварыг хэрэгжүүлэх шаардлагатай болно. Docker Registry нь тайзны дэлгүүр юм.
Өмнө нь werf төслийг dapp гэж нэрлэдэг хэвээр байхад ийм боломж байсан. Гэсэн хэдий ч бид werf-д энэ функцийг хэрэгжүүлэхэд анхаарах ёстой хэд хэдэн асуудалтай тулгарсан.
тайлбар. Энэ функц нь цуглуулагчаас Kubernetes pods дотор ажиллахыг шаарддаггүй, учир нь Үүнийг хийхийн тулд та локал Docker серверийн хамаарлаас салах хэрэгтэй (Kubernetes pod-д локал Docker серверт хандах боломжгүй, учир нь процесс нь өөрөө саванд ажиллаж байгаа бөгөөд werf дэмждэггүй бөгөөд дэмжихгүй. сүлжээгээр Docker сервертэй ажиллах). Kubernetes-ийг ажиллуулахад тусад нь дэмжлэг үзүүлэх болно.
GitHub үйлдлийн албан ёсны дэмжлэг (ШИНЭ)
- Хувилбар: v1.1
- Огноо: Гуравдугаар сар
werf баримт бичиг (хэсэг лавлах и гарын авлага), түүнчлэн werf-тэй ажиллах албан ёсны GitHub Action.
Үүнээс гадна, энэ нь werf-д түр зуурын гүйгч дээр ажиллах боломжийг олгоно.
Хэрэглэгчийн CI системтэй харьцах механизм нь програмыг бүтээх / гаргах тодорхой үйлдлийг эхлүүлэхийн тулд татах хүсэлт дээр шошго байрлуулахад суурилна.
Werf (↓) бүхий програмуудыг орон нутгийн хөгжүүлэлт, байршуулалт
- Хувилбар: v1.1
- Хугацаа: XNUMX-XNUMX-р сар
Гол зорилго нь программуудыг дотооддоо болон үйлдвэрлэлийн аль алинд нь, нарийн төвөгтэй үйлдэлгүйгээр, хайрцагнаас нь байрлуулах нэгдсэн нэг тохиргоонд хүрэх явдал юм.
werf нь мөн програмын кодыг засварлахад тохиромжтой үйлдлийн горимтой байх шаардлагатай бөгөөд дибаг хийх зорилгоор ажиллаж байгаа програмаас санал хүсэлтийг шууд хүлээн авах боломжтой.
Шинэ цэвэрлэх алгоритм (ШИНЭ)
- Хувилбар: v1.1
- Огноо: XNUMX-р сар
Процедур дахь werf v1.1-ийн одоогийн хувилбарт cleanup Агуулгад суурилсан хаяглалтын схемд зориулж зургийг цэвэрлэх заалт байхгүй - эдгээр зургууд хуримтлагдах болно.
Мөн werf-ийн одоогийн хувилбар (v1.0 ба v1.1) нь хаяглалтын схемийн дагуу нийтлэгдсэн зургуудыг цэвэрлэх өөр өөр бодлогыг ашигладаг: Git салбар, Git tag эсвэл Git commit.
Git-ийн үйлдлүүдийн түүхэнд үндэслэсэн, бүх шошголох схемд нэгдсэн дүрсийг цэвэрлэх шинэ алгоритмыг зохион бүтээжээ.
- Git HEAD (салбар ба шошго) тус бүрийн хамгийн сүүлийн үеийн N1-той холбоотой N2-ээс илүүгүй зургийг хадгал.
- Git HEAD (салбар ба шошго) тус бүрийн хувьд хамгийн сүүлийн үеийн N1 амлалттай холбоотой N2-ээс илүүгүй үе шатны зургийг хадгал.
- Ямар ч Kubernetes кластерийн нөөцөд ашиглагдаж буй бүх зургийг хадгална (тохируулгын файлын бүх kube контекст болон нэрийн орон зайг сканнердсан; та энэ үйлдлийг тусгай сонголтоор хязгаарлаж болно).
- Helm хувилбаруудад хадгалагдсан нөөцийн тохиргооны манифест ашигласан бүх зургийг хадгална.
- Хэрэв зураг нь git-ийн ямар ч HEAD-тай холбоогүй (жишээлбэл, харгалзах HEAD өөрөө устгагдсан тул) мөн Kubernetes кластер болон Helm хувилбаруудад ямар ч манифестэд ашиглагдаагүй бол устгаж болно.
Зэрэгцээ зураг бүтээх (↓)
- Хувилбар: v1.1
- Хугацаа: XNUMX-XNUMX-р сар XNUMX-р сар*
Werf-ийн одоогийн хувилбар нь дээр дурдсан зураг, эд өлгийн зүйлсийг цуглуулдаг werf.yaml, дараалсан. Зураг, олдворын бие даасан үе шатуудыг угсрах үйл явцыг зэрэгцүүлж, тохиромжтой, мэдээлэл сайтай гаралтыг хангах шаардлагатай.
* Тайлбар: хуваарилагдсан угсралтыг хэрэгжүүлэхэд илүү ач холбогдол өгч, хэвтээ тэнхлэгийн хэмжээг нэмэгдүүлэх, түүнчлэн GitHub үйлдлүүдтэй werf ашиглах зэрэг давуу талууд нэмэгдсэн тул эцсийн хугацааг өөрчилсөн. Зэрэгцээ угсралт нь нэг төслийг угсрах үед босоо өргөтгөх боломжийг олгодог дараагийн оновчлолын алхам юм.
3-р жолоодлого руу шилжих (↓)
- Хувилбар: v1.2
- Хугацаа: XNUMX-XNUMX-р сар XNUMX-р сар*
Шинэ кодын сан руу шилжих шилжилтийг багтаана одоо байгаа суулгацуудыг шилжүүлэх батлагдсан, тохиромжтой арга юм.
* Тэмдэглэл: Helm 3 руу шилжих нь werf-д чухал шинж чанаруудыг нэмэхгүй, учир нь Helm 3-ын бүх үндсэн функцууд (3 талын нэгдэл, хөндлөвчгүй) werf дээр аль хэдийн хэрэгжсэн. Түүнээс гадна werf-д байдаг заасан зүйлсээс гадна. Гэсэн хэдий ч энэ шилжилт бидний төлөвлөгөөнд хэвээр байгаа бөгөөд хэрэгжих болно.
Kubernetes тохиргоог тайлбарлах Jsonnet (↓)
- Хувилбар: v1.2
- Хугацаа: XNUMX-XNUMX-р сар XNUMX-XNUMX сар
Werf нь Jsonnet форматаар Kubernetes-ийн тохиргооны тайлбарыг дэмжих болно. Үүний зэрэгцээ werf нь Helm-тэй нийцтэй хэвээр байх бөгөөд тайлбарын форматыг сонгох боломжтой болно.
Үүний шалтгаан нь олон хүмүүсийн үзэж байгаагаар Go загварууд нь нэвтрэх өндөр саадтай байдаг бөгөөд эдгээр загваруудын кодыг ойлгох чадвар нь бас мууддаг.
Kubernetes-ийн тохиргооны тайлбарын бусад системийг (жишээлбэл, Kustomize) нэвтрүүлэх боломжийг мөн авч үзэж байна.
Kubernetes дотор ажиллах (↓)
- Хувилбар: v1.2
- Хугацаа: XNUMX-XNUMX-р сар, XNUMX-XNUMX-р сар
Зорилго: Зургийг бүтээж, Кубернетес дэх гүйгч ашиглан програмыг хүргэж байгаа эсэхийг шалгаарай. Тэдгээр. Шинэ зургуудыг Kubernetes pods-ээс шууд барьж, нийтэлж, цэвэрлэж, байрлуулж болно.
Энэ чадварыг хэрэгжүүлэхийн тулд эхлээд тархсан зураг бүтээх чадвартай байх хэрэгтэй (дээрх цэгийг үзнэ үү).
Энэ нь мөн Docker сервергүйгээр (жишээ нь Канико шиг бүтээх эсвэл хэрэглэгчийн орон зайд бүтээх) бүтээгчийн үйлдлийн горимд дэмжлэг үзүүлэх шаардлагатай.
Werf нь Кубернетес дээр зөвхөн Dockerfile-ээр зогсохгүй Stapel бүтээгчийг үе шаттайгаар сэргээн засварлаж, Ansible-тай хамт дэмжих болно.
Нээлттэй хөгжлийн алхам
Бид нийгэмдээ хайртай (, ) мөн бид улам олон хүмүүс werf-ийг сайжруулахад тусалж, бидний явж буй чиглэлийг ойлгож, хөгжилд оролцохыг хүсч байна.
Саяхан шилжихээр шийдсэн манай багийн ажлын явцыг илчлэх зорилгоор. Одоо та ойрын төлөвлөгөө, мөн дараах чиглэлээр хийгдэж буй ажлуудыг харж болно.
- ;
- ;
- ;
- .
Асуудлын талаар маш их ажил хийсэн:
- Үл хамаарах зүйлийг хассан.
- Одоо байгаа нь хангалттай тооны дэлгэрэнгүй мэдээлэл, нарийн ширийн зүйлийг нэг формат руу шилжүүлдэг.
- Санал, саналын шинэ асуудлууд нэмэгдсэн.
v1.1 хувилбарыг хэрхэн идэвхжүүлэх вэ
Энэ хувилбар нь одоогоор бэлэн байна (сувагуудад тогтвортой и чулуулаг Гэсэн хэдий ч тогтворжсон үед хувилбарууд гарч ирнэ ea өөрөө аль хэдийн ашиглахад хангалттай тогтвортой, учир нь сувгуудаар дамжсан Альфа и Бета). Идэвхжүүлсэн дараах байдлаар:
source $(multiwerf use 1.1 ea)
werf COMMAND ...дүгнэлт
Stapel болон Dockerfile бүтээгчдэд зориулсан шинэ шатны хадгалалтын архитектур болон бүтээгчийн оновчлол нь werf дээр тархсан болон зэрэгцээ бүтээцийг хэрэгжүүлэх боломжийг нээж өгч байна. Эдгээр функцууд удахгүй ижил v1.1 хувилбар дээр гарч ирэх бөгөөд автоматаар шинэчлэх механизмаар дамжуулан автоматаар ашиглах боломжтой болно (хэрэглэгчдэд зориулсан). ).
Энэ хувилбарт зургийн контент дээр суурилсан шошголох стратеги нэмэгдсэн - агуулгад суурилсан шошго, энэ нь анхдагч стратеги болсон. Үндсэн тушаалын бүртгэлийг мөн дахин боловсруулсан: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Дараагийн чухал алхам бол хуваарилагдсан угсралтуудыг нэмэх явдал юм. Тархсан бүтээцүүд нь v1.0-ээс хойш зэрэгцээ бүтээцтэй харьцуулахад илүү чухал ач холбогдолтой болсон, учир нь тэд werf-д илүү үнэ цэнийг нэмдэг: барилгачдын босоо масштаб болон төрөл бүрийн CI/CD систем дэх түр зуурын бүтээгчдийг дэмжих, түүнчлэн GitHub үйлдлүүдэд албан ёсны дэмжлэг үзүүлэх чадвар. . Тиймээс зэрэгцээ чуулганыг хэрэгжүүлэх хугацааг өөрчилсөн. Гэхдээ бид хоёр боломжийг аль болох хурдан хэрэгжүүлэхээр ажиллаж байна.
Мэдээг дагаж мөрдөөрэй! Мөн манайхаар зочлохоо бүү мартаарай Асуудал үүсгэх, одоо байгаа нэгийг нь олж нэмэх, PR үүсгэх эсвэл төслийн хөгжлийг үзэх.
PS
Мөн манай блог дээрээс уншина уу:
- «»
- «";
- Werf-ийн инновацийн талаархи цуврал тэмдэглэлүүд:
- «";
- «";
- «";
- «".
Эх сурвалж: www.habr.com