Вече сме говорили за нашия инструмент GitOps повече от веднъж , като този път бихме искали да споделим опита от изграждането на сайт с документацията на самия проект - (руската му версия е ). Това е нормален статичен сайт, но изграждането му е интересно, защото е изградено с помощта на динамичен брой артефакти.
Влезте в нюансите на структурата на сайта: генериране на общо меню за всички версии, страници с информация за версии и т.н. - ние няма. Вместо това, нека се съсредоточим върху проблемите и спецификата на динамичното сглобяване и малко върху свързаните CI/CD процеси.
Въведение: как работи сайтът
Нека започнем с факта, че документацията на werf се съхранява заедно с нейния код. Това налага определени изисквания за разработка, които обикновено са извън обхвата на тази статия, но като минимум може да се каже, че:
- Нови функции на werf не трябва да се пускат без актуализиране на документацията и, обратно, всички промени в документацията предполагат нова версия на werf;
- Проектът има доста интензивно развитие: нови версии могат да се пускат няколко пъти на ден;
- Всички ръчни операции за внедряване на сайт с нова версия на документацията са най-малкото досадни;
- Проектът възприема семантичния подход , с 5 канала на стабилност. Процесът на освобождаване включва последователно преминаване на версиите през каналите в реда на увеличаване на стабилността: от алфа до стабилна;
- Сайтът има рускоезична версия, която „живее и се развива“ (т.е. съдържанието на която се актуализира) успоредно с основната (т.е. англоезична) версия.
За да скрием цялата тази "вътрешна кухня" от потребителя, предлагайки му нещо, което "просто работи", направихме отделен инструмент за инсталиране и актуализиране на werf - . Просто трябва да посочите номера на версията и канала за стабилност, който сте готови да използвате, и multiwerf ще провери дали има нова версия на канала и ще я изтегли, ако е необходимо.
Най-новите версии на werf във всеки канал са достъпни в менюто за избор на версия на сайта. По подразбиране при отваря се версията на най-стабилния канал за последното издание - той също се индексира от търсачките. Документация за канала е достъпна на отделни адреси (напр. за бета версия 1.0).
Общо сайтът разполага със следните версии:
- root (отваря се по подразбиране),
- за всеки активен канал за актуализиране на всяка версия (например, ).
За да генерирате конкретна версия на сайта, в общия случай е достатъчно да я компилирате с помощта на като стартирате в директорията /docs werf хранилище със съответната команда (jekyll build), след като преминете към Git тага на необходимата версия.
Остава само да добавим, че:
- самата програма (werf) се използва за сглобяване;
- CI/CD процесите са изградени върху GitLab CI;
- и всичко това, разбира се, работи в Kubernetes.
задачи
Сега формулираме задачи, които отчитат всички описани специфики:
- След промяна на версията на werf на всеки канал за актуализация документацията на сайта трябва да се актуализира автоматично.
- За развитие е необходимо понякога да можете прегледайте визуализациите на сайта.
Прекомпилирането на сайта трябва да се извърши след промяна на версията на всеки канал от съответните Git тагове, но в процеса на изграждане на изображението ще получим следните функции:
- Тъй като списъкът с версии на каналите се променя, е необходимо само да се изгради отново документацията за каналите, където версията е променена. В крайна сметка възстановяването на всичко наново не е много красиво.
- Наборът от канали за издания може да се промени. В даден момент, например, може да няма версия на каналите, по-стабилна от изданието за ранен достъп 1.1, но с течение на времето те ще се появят - в този случай не променяйте сборката на ръка?
Оказва се, че сглобяването зависи от промяна на външни данни.
Изпълнение
Избор на подход
Като алтернатива можете да стартирате всяка необходима версия като отделен пакет в Kubernetes. Тази опция предполага по-голям брой обекти в клъстера, който ще расте с увеличаване на броя на стабилните версии на werf. А това от своя страна предполага по-сложна поддръжка: всяка версия има собствен HTTP сървър и с малко натоварване. Разбира се, това води и до по-високи разходи за ресурси.
Тръгнахме по пътя сглобяване на всички необходими версии в едно изображение. Компилираната статика на всички версии на сайта е в контейнер с NGINX, а трафикът към съответното разполагане идва през NGINX Ingress. Една проста структура - приложение без състояние - улеснява мащабирането на Разгръщане (в зависимост от натоварването) с помощта на самия Kubernetes.
За да бъдем по-точни, изграждаме две изображения: едното е за производствения цикъл, второто е допълнително за цикъла за разработка. Допълнителното изображение се използва (стартира) само на dev loop заедно с основното и съдържа версията на сайта от прегледа на комита, а маршрутизирането между тях се извършва с помощта на ресурси на Ingress.
werf срещу git клонинг и артефакти
Както вече споменахме, за да генерирате статика на сайта за конкретна версия на документацията, трябва да изградите, като превключите към съответния етикет на хранилището. Можете също да направите това, като клонирате хранилището всеки път, когато изграждате, като избирате подходящите тагове от списъка. Това обаче е доста ресурсоемка операция и освен това изисква писане на нетривиални инструкции ... Друг сериозен недостатък е, че при този подход няма начин да се кешира нещо по време на асемблирането.
Тук самата помощна програма werf идва на помощ, внедрявайки интелигентно кеширане и ви позволява да използвате . Използването на werf за добавяне на код от хранилището значително ще ускори изграждането, защото werf по същество клонира хранилището веднъж и след това го прави само fetch ако е необходимо. Освен това, когато добавяме данни от хранилището, можем да изберем само необходимите директории (в нашия случай това е директорията docs), което значително ще намали количеството добавени данни.
Тъй като Jekyll е инструмент за компилиране на статики и не е необходим в крайното изображение, би било логично да се компилира до , и в крайното изображение импортирайте само резултат от компилация.
Пишем werf.yaml
Така че решихме, че ще компилираме всяка версия в отделен werf артефакт. Ние обаче не знаем колко от тези артефакти ще бъдат по време на сглобяването, така че не можем да напишем фиксирана конфигурация за изграждане (стриктно погледнато, можем, но няма да е много ефективно).
werf ви позволява да използвате във вашия конфигурационен файл (werf.yaml), което го прави възможно генериране на конфигурация в движение в зависимост от външни данни (от какво се нуждаете!). Външните данни в нашия случай са информация за версии и версии, въз основа на които събираме необходимия брой артефакти и в резултат на това получаваме две изображения: werf-doc и werf-dev да работи на различни вериги.
Външните данни се предават чрез променливи на средата. Ето и състава им:
-
RELEASES- низ със списък от издания и съответната текуща версия на werf, като списък, разделен с интервал от стойности във формата<НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>, Пример:1.0%v1.0.4-beta.20 -
CHANNELS- ред със списък от канали и съответната текуща версия на werf, под формата на списък, разделен с интервал от стойности във формата<КАНАЛ>%<НОМЕР_ВЕРСИИ>, Пример:1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22 -
ROOT_VERSION— версия на версията на werf, която да се показва по подразбиране на сайта (не винаги е необходимо да се показва документация с най-високия номер на версия). Пример:v1.0.4-beta.20 -
REVIEW_SHA— хеш на ангажимента за преглед, от който трябва да изградите версия за тестовия цикъл.
Тези променливи ще бъдат попълнени в GitLab CI pipeline, а как точно е написано по-долу.
На първо място, за удобство, ние определяме в werf.yaml Отидете на шаблонни променливи, като им присвоите стойности от променливи на средата:
{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }} Описанието на артефакта за компилиране на статичната версия на сайта като цяло е едно и също за всички случаи, от които се нуждаем (включително генерирането на root версията, както и версията за dev схемата). Затова ще го извадим в отделен блок с помощта на функцията 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 }}. Но трябва да разберете, че когато импортирате от артефакти, ще трябва да се позовавате на същите имена.
При описване на артефакт се използва тази характеристика на werf, като напр . Монтиране със сервизна директория build_dir ви позволява да запазвате кеша на Jekyll между стартиранията на тръбопровода, което значително ускорява повторното сглобяване.
Освен това може да сте забелязали използването на файла releases.yml е YAML файл с данни за изданието, поискани от (артефакт, получен чрез изпълнение на конвейера). Необходим е при компилирането на сайта, но в контекста на статията ни е интересен, защото зависи от състоянието му възстановяване само на един артефакт - артефакт на сайта на основната версия (не е необходим в други артефакти).
Това се реализира с помощта на условния оператор if Отидете на модели и дизайни {{ $Root.Files.Get "releases.yml" | sha256sum }} в етап . Работи по следния начин: при изграждане на артефакт за основната версия (променлива .Channel е равно на root) файл хеш releases.yml засяга сигнатурата на целия етап, тъй като е част от името на заданието Ansible (параметър 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 -}} защото цикълът ще генерира няколко артефакта (надяваме се да е така), трябва да вземете предвид разделителя между тях - последователността --- (За подробности относно синтаксиса на конфигурационния файл вижте ). Както беше дефинирано по-рано, когато извикваме шаблона в цикъл, ние предаваме параметри на версията, URL адрес и корен на контекста.
По подобен начин, но без цикъл, наричаме шаблона на артефакта за „специални случаи“: за основната версия, както и версията от ангажимента за преглед:
{{ 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.
Артефактите са готови - време е да започнете импортирането!
Крайното изображение, предназначено да работи на Kubernetes, е обикновен NGINX с добавен към него конфигурационен файл на сървъра. nginx.conf и статичен от артефакти. В допълнение към артефакта на основната версия на сайта, трябва да повторим цикъла върху променливата .WerfVersions за импортиране на артефакти на канал и освобождаване на версия + следвайте правилото за именуване на артефакти, което приехме по-рано. Тъй като всеки артефакт съхранява версии на сайта за два езика, ние ги импортираме на местата, предвидени от конфигурацията.
Описание на окончателното изображение на werf-doc
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. Би било възможно изобщо да не се генерира изображението werf-dev, ако няма променлива на средата REVIEW_SHA, но за да Изображенията на Docker в werf работеха за изображението werf-dev, ние ще го оставим да бъде изградено само с артефакта на основната версия (той вече е изграден така или иначе), за да опростим структурата на конвейера.
Монтажът е готов! Нека да преминем към CI / CD и важни нюанси.
Конвейер в GitLab CI и характеристики на динамично сглобяване
Когато изпълняваме компилацията, трябва да зададем променливите на средата, използвани в werf.yaml. Това не се отнася за променливата REVIEW_SHA, която ще зададем, когато извикваме конвейера от куката на GitHub.
Ние ще прехвърлим формирането на необходимите външни данни към Bash скрипта generate_artifacts, което ще генерира два GitLab конвейерни артефакта:
- файл
releases.ymlс данни за изданието - файл
common_envs.shСъдържащ променливите на средата за експортиране.
Съдържанието на файла generate_artifacts ще намерите в нашия . Самото получаване на данните не е предмет на статията, а файла common_envs.sh важно за нас, защото werf зависи от това. Пример за съдържанието му:
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' Можете да използвате изхода на такъв скрипт, например, като използвате функцията Bash source.
И сега най-интересното. За да работи както изграждането, така и внедряването на приложението правилно, трябва да се уверите, че werf.yaml Това беше същото най-малко в рамките на един тръбопровод. Ако това условие не е изпълнено, тогава сигнатурите на етапа, които werf изчислява по време на изграждане и, например, разгръщане, ще бъдат различни. Това ще доведе до грешка при внедряването, като изображението, необходимо за внедряване, ще липсва.
С други думи, ако по време на изграждането на изображението на сайта има само една информация за издания и версии и по време на внедряването е пусната нова версия и променливите на средата имат различни стойности, тогава внедряването ще се провали с грешка: в крайна сметка артефактът на новата версия все още не е изграден.
Ако поколение werf.yaml зависи от външни данни (например списък с текущи версии, както в нашия случай), тогава съставът и стойностите на тези данни трябва да бъдат фиксирани в конвейера. Това е особено важно, ако външните параметри се променят доста често.
Ще го направим получаване и коригиране на външни данни на първия етап от конвейера в GitLab (Предварително изграждане) и ги предайте по-нататък във формата GitLab CI артефакт. Това ще ви позволи да стартирате и рестартирате конвейерни задачи (изграждане, внедряване, почистване) със същата конфигурация в 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След като коригирате външни данни в артефакт, можете да изградите и внедрите, като използвате стандартните етапи на GitLab CI pipeline: Build and Deploy. Ние стартираме самия тръбопровод чрез кукички от хранилището на werf GitHub (тоест, когато се правят промени в хранилището на GitHub). Данните за тях могат да бъдат взети в свойствата на проекта GitLab в секцията CI / CD настройки -> Задействания на тръбопроводаи след това създайте съответния Webhook в GitHub (Настройки -> Уебкукички).
Етапът на изграждане ще изглежда така:
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 GitLab ще добави два артефакта от етапа към етапа на изграждане Предварително изграждане, така че експортираме подготвени входни променливи с конструкцията source common_envs.sh. Започваме етапа на изграждане във всички случаи, с изключение на планираното пускане на тръбопровода. Според графика ще пуснем тръбопровод за почистване - в този случай не е необходимо да строите.
На етапа на внедряване ще опишем две задачи - поотделно за внедряване в производствени и dev вериги, използвайки YAML шаблон:
.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 трябва да се внедри (WERF_KUBE_CONTEXT) и задаване на променливите на средата на пътя (environment.name и environment.url), които след това се използват в шаблони за диаграми на Helm. Няма да даваме съдържанието на шаблоните, т.к няма нищо интересно за разглежданата тема, но можете да ги намерите в .
Последно докосване
Тъй като версиите на werf се пускат доста често, нови изображения ще се изграждат често и регистърът на Docker постоянно ще расте. Поради това е наложително да конфигурирате автоматично почистване на изображения според правилата. Много е лесно да направите това.
Изпълнението ще изисква:
- Добавете стъпка за почистване към
.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
Вече видяхме почти всичко това малко по-нагоре - само за почистване трябва първо да влезете в регистъра на Docker с токен, който има права за изтриване на изображения в регистъра на Docker (автоматично издаденият токен за задача GitLab CI няма такова права). Токенът трябва да бъде въведен предварително в GitLab и неговата стойност трябва да бъде посочена в променливата на средата WERF_IMAGES_CLEANUP_PASSWORD проект (Настройки на CI/CD -> Променливи).
Добавянето на задача за почистване с необходимия график се извършва в CI/CD ->
Списъци.
Всичко: проектът в регистъра на Docker вече няма да нараства постоянно от неизползвани изображения.
В края на практическата част напомням, че пълните списъци от статията са налични в :
- ;
- .
Резултат
- Имаме логична структура на изграждане: един артефакт на версия.
- Сглобката е универсална и не изисква ръчни промени, когато се пускат нови версии на werf: документацията на сайта се актуализира автоматично.
- Две изображения са сглобени за различни контури.
- Работи бързо, защото кеширането се използва максимално — когато се пусне нова версия на werf или се извика кука на GitHub за ангажимент за преглед — само съответният артефакт с модифицираната версия се изгражда отново.
- Няма нужда да мислите за изтриване на неизползвани изображения: почистването чрез политики на werf ще поддържа регистъра на Docker в ред.
Данни
- Използването на werf позволява на сглобката да работи бързо поради кеширането както на самата сглобка, така и на кеширането при работа с външни хранилища.
- Работата с външни хранилища на Git елиминира необходимостта от клониране на хранилището всеки път напълно или преоткриване на колелото с сложна логика за оптимизация. werf използва кеша и прави клонирането само веднъж и след това използва
fetchи то само при нужда. - Възможност за използване на Go-templates в конфигурационния файл за изграждане
werf.yamlви позволява да опишете сборка, чийто резултат зависи от външни данни. - Използването на mount в werf значително ускорява събирането на артефакти - поради кеша, който е общ за всички конвейери.
- werf улеснява персонализирането на почистването, което е особено вярно за динамичните компилации.
PS
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «".
Източник: www.habr.com
