Већ смо више пута говорили о нашем ГитОпс алату , а овога пута желимо да поделимо наше искуство у склапању сајта са документацијом самог пројекта - (његова руска верзија је ). Ово је обична статична локација, али је њена монтажа занимљива по томе што је изграђена помоћу динамичког броја артефаката.
Уђите у нијансе структуре сајта: генерисање заједничког менија за све верзије, странице са информацијама о издањима итд. - нећемо. Уместо тога, хајде да се усредсредимо на проблеме и карактеристике динамичког склапања и мало на пратеће ЦИ/ЦД процесе.
Увод: како сајт функционише
За почетак, верф документација се чува заједно са својим кодом. Ово намеће одређене развојне захтеве који су генерално ван оквира овог чланка, али се у најмању руку може рећи да:
- Нове верф функције не би требало да буду објављене без ажурирања документације и, обрнуто, све измене у документацији подразумевају издавање нове верзије верф-а;
- Пројекат има прилично интензиван развој: нове верзије се могу објављивати неколико пута дневно;
- Било какве ручне операције за постављање сајта са новом верзијом документације су у најмању руку досадне;
- Пројекат усваја семантички приступ , са 5 канала за стабилност. Процес ослобађања укључује секвенцијални пролаз верзија кроз канале у циљу повећања стабилности: од алфа до чврсте;
- Сајт има верзију на руском језику, која „живи и развија“ (тј. чији се садржај ажурира) паралелно са главном (тј. на енглеском) верзијом.
Да сакријемо сву ову „унутрашњу кухињу“ од корисника, нудећи му нешто што „само ради“, урадили смо засебан алат за инсталацију и ажурирање верф-а - Је . Само треба да наведете број издања и канал стабилности који сте спремни да користите, а мултиверф ће проверити да ли постоји нова верзија на каналу и преузети је ако је потребно.
У менију за избор верзије на веб локацији, најновије верзије верфа су доступне на сваком каналу. Подразумевано, по адреси отвара се верзија најстабилнијег канала за најновије издање - такође га индексирају претраживачи. Документација за канал је доступна на одвојеним адресама (нпр. за бета издање 1.0).
Укупно, сајт има следеће доступне верзије:
- роот (отвара се подразумевано),
- за сваки активни канал ажурирања сваког издања (нпр. ).
Да бисте генерисали одређену верзију сајта, генерално, довољно је компајлирати је користећи покретањем у директоријуму /docs верф спремиште одговарајућа команда (jekyll build), након преласка на Гит ознаку потребне верзије.
Остаје само додати да:
- сам услужни програм (верф) се користи за склапање;
- ЦИ/ЦД процеси су изграђени на бази ГитЛаб ЦИ;
- и све ово, наравно, ради у Кубернетесу.
задаци
Хајде сада да формулишемо задатке који узимају у обзир све описане специфичности:
- Након промене верф верзије на било ком каналу за ажурирање документацију на сајту треба аутоматски ажурирати.
- За развој морате понекад бити у могућности прегледајте верзије сајта за преглед.
Сајт се мора поново компајлирати након промене верзије на било ком каналу са одговарајућих Гит ознака, али у процесу прављења слике добићемо следеће карактеристике:
- Пошто се листа верзија на каналима мења, потребно је само реконструисати документацију за канале на којима је верзија промењена. На крају крајева, поново све поново изградити није баш лепо.
- Скуп канала за издања се може променити. У неком тренутку, на пример, можда неће постојати верзија на каналима стабилнија од верзије 1.1 са раним приступом, али ће се временом појавити - у овом случају, зар не бисте требали ручно да промените склоп?
Испоставило се да монтажа зависи од промене спољних података.
Имплементација
Избор приступа
Алтернативно, можете да покренете сваку потребну верзију као засебан под у Кубернетес-у. Ова опција подразумева већи број објеката у кластеру, који ће расти са повећањем броја стабилних верф издања. А ово, заузврат, подразумева сложеније одржавање: свака верзија има свој ХТТП сервер и са малим оптерећењем. Наравно, ово повлачи и веће трошкове ресурса.
Ишли смо истим путем склапање свих потребних верзија у једну слику. Састављена статика свих верзија сајта налази се у контејнеру са НГИНКС-ом, а саобраћај до одговарајуће Деплоимент долази преко НГИНКС Ингресс-а. Једноставна структура - апликација без стања - омогућава вам да лако скалирате имплементацију (у зависности од оптерећења) користећи сам Кубернетес.
Да будемо прецизнији, прикупљамо две слике: једна за производно коло, друга је додатна за дев коло. Додатна слика се користи (покреће) само на дев колу заједно са главном и садржи верзију сајта из урезивања прегледа, а рутирање између њих се врши помоћу Ингресс ресурса.
верф вс гит клон и артефакти
Као што је већ поменуто, да бисте генерисали статику сајта за одређену верзију документације, потребно је да направите прелазак на одговарајућу ознаку спремишта. То можете урадити и тако што ћете клонирати спремиште сваки пут када правите, бирајући одговарајуће ознаке са листе. Међутим, ово је прилично ресурсно интензивна операција и, штавише, захтева писање нетривијалних инструкција... Још један озбиљан недостатак је то што са овим приступом нема начина да се нешто кешира током склапања.
Овде нам у помоћ прискаче сам услужни програм верф, имплементирајући паметно кеширање и омогућава вам да користите . Коришћење верф-а за додавање кода из спремишта значајно ће убрзати изградњу, јер верф у суштини клонира спремиште једном и затим се извршава само fetch ако је неопходно. Поред тога, приликом додавања података из спремишта, можемо изабрати само потребне директоријуме (у нашем случају ово је директоријум docs), што ће значајно смањити количину додатих података.
Пошто је Јекилл алат дизајниран за компајлирање статичких података и није потребан у коначној слици, било би логично да се компајлира у , и у коначну слику увоз само резултат компилације.
Пишемо верф.иамл
Дакле, одлучили смо да сваку верзију компајлирамо у посебан верф артефакт. Међутим ми не знамо колико ће ових артефаката бити током склапања, тако да не можемо да напишемо фиксну конфигурацију градње (строго говорећи, још увек можемо, али то неће бити потпуно ефикасно).
верф вам омогућава да користите у вашој конфигурационој датотеци (werf.yaml), и то омогућава генерише конфигурацију у ходу у зависности од спољних података (шта вам треба!). Екстерни подаци у нашем случају су информације о верзијама и издањима, на основу којих прикупљамо потребан број артефаката и као резултат добијамо две слике: werf-doc и werf-dev да ради на различитим круговима.
Екстерни подаци се прослеђују кроз променљиве окружења. Ево њиховог састава:
-
RELEASES— ред са листом издања и одговарајућом тренутном верзијом верф-а, у облику листе вредности раздвојених размацима у формату<НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>... Пример:1.0%v1.0.4-beta.20 -
CHANNELS— ред са листом канала и одговарајућом тренутном верзијом верф-а, у облику листе вредности раздвојених размацима у формату<КАНАЛ>%<НОМЕР_ВЕРСИИ>... Пример:1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22 -
ROOT_VERSION— верзија верф издања која се подразумевано приказује на сајту (није увек неопходно да се документација приказује по највећем броју издања). Пример:v1.0.4-beta.20 -
REVIEW_SHA— хеш урезивања прегледа из којег треба да направите верзију за тест петљу.
Ове варијабле ће бити попуњене у ГитЛаб ЦИ цевоводу, а како тачно је написано у наставку.
Пре свега, ради погодности, дефинишемо у werf.yaml Иди на променљиве шаблона, додељујући им вредности из променљивих окружења:
{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }} Опис артефакта за састављање статичке верзије сајта је генерално исти за све случајеве који су нам потребни (укључујући генерисање основне верзије, као и верзију за дев коло). Због тога ћемо га преместити у посебан блок помоћу функције define - за накнадну поновну употребу include. Проследићемо шаблону следеће аргументе:
-
Version— генерисана верзија (име ознаке); -
Channel— назив канала за ажурирање за који се артефакт генерише; -
Commit— хеш урезивања, ако је артефакт генерисан за урезивање прегледа; - контекст.
Опис шаблона артефакта
{{- define "doc_artifact" -}}
{{- $Root := index . "Root" -}}
artifact: doc-{{ .Channel }}
from: jekyll/builder:3
mount:
- from: build_dir
to: /usr/local/bundle
ansible:
install:
- shell: |
export PATH=/usr/jekyll/bin/:$PATH
- name: "Install Dependencies"
shell: bundle install
args:
executable: /bin/bash
chdir: /app/docs
beforeSetup:
{{- if .Commit }}
- shell: echo "Review SHA - {{ .Commit }}."
{{- end }}
{{- if eq .Channel "root" }}
- name: "releases.yml HASH: {{ $Root.Files.Get "releases.yml" | sha256sum }}"
copy:
content: |
{{ $Root.Files.Get "releases.yml" | indent 8 }}
dest: /app/docs/_data/releases.yml
{{- else }}
- file:
path: /app/docs/_data/releases.yml
state: touch
{{- end }}
- file:
path: "{{`{{ item }}`}}"
state: directory
mode: 0777
with_items:
- /app/main_site/
- /app/ru_site/
- file:
dest: /app/docs/pages_ru/cli
state: link
src: /app/docs/pages/cli
- shell: |
echo -e "werfVersion: {{ .Version }}nwerfChannel: {{ .Channel }}" > /tmp/_config_additional.yml
export PATH=/usr/jekyll/bin/:$PATH
{{- if and (ne .Version "review") (ne .Channel "root") }}
{{- $_ := set . "BaseURL" ( printf "v%s" .Channel ) }}
{{- else if ne .Channel "root" }}
{{- $_ := set . "BaseURL" .Channel }}
{{- end }}
jekyll build -s /app/docs -d /app/_main_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/tmp/_config_additional.yml
jekyll build -s /app/docs -d /app/_ru_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/app/docs/_config_ru.yml,/tmp/_config_additional.yml
args:
executable: /bin/bash
chdir: /app/docs
git:
- url: https://github.com/flant/werf.git
to: /app/
owner: jekyll
group: jekyll
{{- if .Commit }}
commit: {{ .Commit }}
{{- else }}
tag: {{ .Version }}
{{- end }}
stageDependencies:
install: ['docs/Gemfile','docs/Gemfile.lock']
beforeSetup: '**/*'
includePaths: 'docs'
excludePaths: '**/*.sh'
{{- end }} Назив артефакта мора бити јединствен. То можемо постићи, на пример, додавањем назива канала (вредност променљиве .Channel) као суфикс имена артефакта: artifact: doc-{{ .Channel }}. Али морате да схватите да ћете приликом увоза из артефаката морати да се позивате на иста имена.
Када се описује артефакт, користи се следећа верф карактеристика: . Монтажа која означава сервисни директоријум build_dir омогућава вам да сачувате Јекилл кеш између покретања цевовода, што значајно убрзава поновно састављање.
Можда сте такође приметили употребу датотеке releases.yml је ИАМЛ датотека са подацима о издању који се траже од (артефакт добијен приликом извршавања цевовода). Потребан је приликом састављања сајта, али у контексту чланка нам је занимљив јер зависи од његовог стања поновно састављање само једног артефакта — артефакт основне верзије сајта (није потребан у другим артефактима).
Ово се имплементира помоћу условне изјаве if Иди на шаблоне и дизајне {{ $Root.Files.Get "releases.yml" | sha256sum }} у фази . Ради на следећи начин: када се прави артефакт за роот верзију (променљива .Channel је једнако root) хеш датотеке releases.yml утиче на потпис целе фазе, пошто је део назива Ансибле задатка (параметар name). Дакле, приликом промене садржаја филе releases.yml одговарајући артефакт ће бити поново састављен.
Такође обратите пажњу на рад са спољним спремиштем. На слици артефакта из , додаје се само директоријум /docs, а у зависности од прослеђених параметара, одмах се додају подаци потребне ознаке или урезивања прегледа.
Да бисмо користили шаблон артефакта за генерисање описа артефакта пренетих верзија канала и издања, организујемо петљу на променљивој .WerfVersions в werf.yaml:
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}} Јер петља ће генерисати неколико артефаката (надамо се), потребно је узети у обзир сепаратор између њих - секвенцу --- (За више информација о синтакси конфигурационе датотеке, погледајте ). Као што је раније дефинисано, приликом позивања шаблона у петљи, ми прослеђујемо параметре верзије, УРЛ и основни контекст.
Слично, али без петље, ми називамо шаблон артефакта за „посебне случајеве“: за основну верзију, као и верзију из урезивања прегледа:
{{ dict "Version" .WerfRootVersion "Channel" "root" "Root" $Root | include "doc_artifact" }}
---
{{- if .WerfReviewCommit }}
{{ dict "Version" "review" "Channel" "review" "Commit" .WerfReviewCommit "Root" $Root | include "doc_artifact" }}
{{- end }} Имајте на уму да ће артефакт за урезивање прегледа бити направљен само ако је променљива подешена .WerfReviewCommit.
Артефакти су спремни - време је да почнете да увозите!
Коначна слика, дизајнирана да ради на Кубернетес-у, је обичан НГИНКС са додатом конфигурационом датотеком сервера nginx.conf и статичне од артефаката. Поред артефакта основне верзије сајта, потребно је да поновимо петљу на променљивој .WerfVersions да увезете артефакте канала и верзије издања + следите правило именовања артефаката које смо раније усвојили. Пошто сваки артефакт чува верзије сајта за два језика, ми их увозимо на места предвиђена конфигурацијом.
Опис финалне слике верф-доц
image: werf-doc
from: nginx:stable-alpine
ansible:
setup:
- name: "Setup /etc/nginx/nginx.conf"
copy:
content: |
{{ .Files.Get ".werf/nginx.conf" | indent 8 }}
dest: /etc/nginx/nginx.conf
- file:
path: "{{`{{ item }}`}}"
state: directory
mode: 0777
with_items:
- /app/main_site/assets
- /app/ru_site/assets
import:
- artifact: doc-root
add: /app/_main_site
to: /app/main_site
before: setup
- artifact: doc-root
add: /app/_ru_site
to: /app/ru_site
before: setup
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
add: /app/_main_site
to: /app/main_site/v{{ $Channel }}
before: setup
{{ end -}}
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
add: /app/_ru_site
to: /app/ru_site/v{{ $Channel }}
before: setup
{{ end -}}Додатна слика, која се, заједно са главном, покреће на дев колу, садржи само две верзије сајта: верзију из урезивања прегледа и коренску верзију сајта (постоје општа средства и, ако се сећате , подаци о издању). Дакле, додатна слика ће се разликовати од главне само у одељку за увоз (и, наравно, у називу):
image: werf-dev
...
import:
- artifact: doc-root
add: /app/_main_site
to: /app/main_site
before: setup
- artifact: doc-root
add: /app/_ru_site
to: /app/ru_site
before: setup
{{- if .WerfReviewCommit }}
- artifact: doc-review
add: /app/_main_site
to: /app/main_site/review
before: setup
- artifact: doc-review
add: /app/_ru_site
to: /app/ru_site/review
before: setup
{{- end }} Као што је горе наведено, артефакт за урезивање прегледа ће бити генерисан само када се покрене подешена променљива окружења REVIEW_SHA. Било би могуће да се слика верф-дев уопште не генерише ако не постоји променљива окружења REVIEW_SHA, али да би се Доцкер слике у верф-у су радиле за верф-дев слику, оставићемо је да се направи само са артефактом основне верзије (ионако је већ изграђен), да бисмо поједноставили структуру цевовода.
Скупштина је спремна! Пређимо на ЦИ/ЦД и важне нијансе.
Пипелине у ГитЛаб ЦИ и карактеристике динамичке градње
Када покрећемо буилд, морамо да подесимо променљиве окружења које се користе werf.yaml. Ово се не односи на променљиву РЕВИЕВ_СХА, коју ћемо поставити приликом позивања цевовода са ГитХуб куке.
Генерисаћемо неопходне спољне податке у Басх скрипти generate_artifacts, који ће генерисати два ГитЛаб артефакта цевовода:
- фајл
releases.ymlса подацима о издању, - фајл
common_envs.sh, који садржи променљиве окружења које се извозе.
Садржај датотеке generate_artifacts наћи ћете у нашој . Само примање података није тема чланка, већ фајл common_envs.sh нам је важно, јер од тога зависи рад верфа. Пример његовог садржаја:
export RELEASES='1.0%v1.0.6-4'
export CHANNELS='1.0-alpha%v1.0.7-1 1.0-beta%v1.0.7-1 1.0-ea%v1.0.6-4 1.0-stable%v1.0.6-4 1.0-rock-solid%v1.0.6-4'
export ROOT_VERSION='v1.0.6-4' Можете користити излаз такве скрипте, на пример, користећи Басх функцију source.
Сада долази забавни део. Да би и израда и имплементација апликације функционисали исправно, неопходно је то осигурати werf.yaml био исти барем унутар једног цевовода. Ако овај услов није испуњен, онда ће потписи фаза које верф израчунава током склапања и, на пример, постављања, бити другачији. Ово ће довести до грешке при постављању, јер... слика потребна за примену ће недостајати.
Другим речима, ако су током састављања слике сајта информације о издањима и верзијама исте, а у време имплементације је објављена нова верзија и варијабле окружења имају различите вредности, тада ће имплементација бити неуспешна са грешком: уосталом, артефакт нове верзије још није изграђен.
Ако генерација werf.yaml зависи од спољних података (на пример, списак актуелних верзија, као у нашем случају), онда састав и вредности таквих података треба да се забележе у оквиру цевовода. Ово је посебно важно ако се спољни параметри прилично често мењају.
Ми ћемо примају и снимају екстерне податке у првој фази гасовода у ГитЛабу (Пребуилд) и пренети их даље у облику ГитЛаб ЦИ артефакт. Ово ће вам омогућити да покренете и поново покренете послове цевовода (изградња, имплементација, чишћење) са истом конфигурацијом у werf.yaml.
Садржај бине Пребуилд филе .gitlab-ci.yml:
Prebuild:
stage: prebuild
script:
- bash ./generate_artifacts 1> common_envs.sh
- cat ./common_envs.sh
artifacts:
paths:
- releases.yml
- common_envs.sh
expire_in: 2 weekНакон што сте снимили спољне податке у артефакт, можете да направите и примените користећи стандардне фазе ГитЛаб ЦИ цевовода: Буилд и Деплои. Покрећемо сам цевовод користећи закачке из верф ГитХуб спремишта (тј. када дође до промена у ГитХуб репозиторијуму). Подаци за њих се могу наћи у својствима ГитЛаб пројекта у одељку Поставке ЦИ/ЦД-а -> Окидачи цевовода, а затим креирајте одговарајући Вебхоок у ГитХуб-у (Подешавања -> Вебхоокс).
Фаза изградње ће изгледати овако:
Build:
stage: build
script:
- type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
- type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
- source common_envs.sh
- werf build-and-publish --stages-storage :local
except:
refs:
- schedules
dependencies:
- Prebuild ГитЛаб ће додати два артефакта из фазе у фазу израде Пребуилд, тако да извозимо променљиве са припремљеним улазним подацима користећи конструкцију source common_envs.sh. Почињемо фазу изградње у свим случајевима, осим пуштања цевовода у рад према распореду. Према плану, водићемо цевовод за чишћење - у овом случају нема потребе за монтажом.
У фази имплементације, описаћемо два задатка - одвојено за примену у производна кола и кола за развој, користећи ИАМЛ шаблон:
.base_deploy: &base_deploy
stage: deploy
script:
- type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
- type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
- source common_envs.sh
- werf deploy --stages-storage :local
dependencies:
- Prebuild
except:
refs:
- schedules
Deploy to Production:
<<: *base_deploy
variables:
WERF_KUBE_CONTEXT: prod
environment:
name: production
url: werf.io
only:
refs:
- master
except:
variables:
- $REVIEW_SHA
refs:
- schedules
Deploy to Test:
<<: *base_deploy
variables:
WERF_KUBE_CONTEXT: dev
environment:
name: test
url: werf.test.flant.com
except:
refs:
- schedules
only:
variables:
- $REVIEW_SHA Задаци се суштински разликују само у назначавању контекста кластера у који верф треба да изврши распоређивање (WERF_KUBE_CONTEXT) и подешавање променљивих окружења петље (environment.name и environment.url), који се затим користе у шаблонима Хелмових графикона. Нећемо дати садржај шаблона, јер... тамо нема ништа занимљиво за предметну тему, али можете их пронаћи у .
Финал тоуцх
Пошто се верзије верф-а издају прилично често, нове слике ће се често правити, а Доцкер регистар ће стално расти. Због тога је неопходно конфигурисати аутоматско чишћење слике на основу смерница. То је врло лако урадити.
За имплементацију ће вам требати:
- Додајте корак чишћења у
.gitlab-ci.yml; - Додајте периодично извршавање задатка чишћења;
- Подесите променљиву окружења са токеном за приступ писању.
Додавање фазе чишћења у .gitlab-ci.yml:
Cleanup:
stage: cleanup
script:
- type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
- type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
- source common_envs.sh
- docker login -u nobody -p ${WERF_IMAGES_CLEANUP_PASSWORD} ${WERF_IMAGES_REPO}
- werf cleanup --stages-storage :local
only:
refs:
- schedules
Већ смо видели скоро све ово мало више – само да бисте га очистили, потребно је да се прво пријавите у Доцкер Регистри са токеном који има права за брисање слика у Доцкер регистру (аутоматски издати ГитЛаб ЦИ токен задатака не имају таква права). Токен мора бити креиран у ГитЛабу унапред и његова вредност мора бити наведена у променљивој окружења WERF_IMAGES_CLEANUP_PASSWORD пројекат (ЦИ/ЦД подешавања -> Променљиве).
Додавање задатка чишћења са потребним распоредом се врши у ЦИ/ЦД ->
Распореди.
То је то: пројекат у Доцкер регистру више неће стално расти из некоришћених слика.
На крају практичног дела, да вас подсетим да су комплетни спискови из чланка доступни у :
- ;
- .
Резултат
- Добили смо логичну структуру склопа: један артефакт по верзији.
- Склоп је универзалан и не захтева ручне промене када се објаве нове верзије верфа: документација на веб локацији се аутоматски ажурира.
- Две слике су састављене за различите контуре.
- Делује брзо, јер Кеширање се користи што је више могуће – када се објави нова верзија верф-а или се позове ГитХуб кука за урезивање прегледа, само се одговарајући артефакт са промењеном верзијом поново гради.
- Нема потребе да размишљате о брисању некоришћених слика: чишћење у складу са верф смерницама ће одржавати Доцкер регистар у реду.
Налази
- Коришћење верф-а омогућава да склоп ради брзо због кеширања и самог склопа и кеширања при раду са спољним репозиторијумима.
- Рад са спољним Гит репозиторијумима елиминише потребу за клонирањем целог спремишта сваки пут или поново измишљањем точака са лукавом логиком оптимизације. верф користи кеш меморију и врши клонирање само једном, а затим користи
fetchи то само по потреби. - Могућност коришћења Го шаблона у конфигурационој датотеци изградње
werf.yamlомогућава вам да опишете склоп чији резултат зависи од спољних података. - Коришћење моунт у верф-у значајно убрзава прикупљање артефаката - због кеша који је заједнички за све цевоводе.
- верф олакшава конфигурисање чишћења, што је посебно важно када се гради динамички.
ПС
Прочитајте и на нашем блогу:
- «";
- «";
- «";
- «'.
Извор: ввв.хабр.цом
