mao ang among open source GitOps CLI utility para sa pagtukod ug paghatud sa mga aplikasyon sa Kubernetes. Ingon sa gisaad, nagtimaan sa pagsugod sa pagdugang bag-ong mga bahin sa werf ug pag-usab sa tradisyonal nga mga pamaagi. Karon nalipay kami nga ipresentar ang pagpagawas v1.1, nga usa ka dako nga lakang sa pag-uswag ug pundasyon alang sa umaabot kolektor werf. Ang bersyon anaa karon sa .
Ang sukaranan sa pagpagawas mao ang bag-ong entablado nga arkitektura sa pagtipig ug pag-optimize sa trabaho sa duha nga mga kolektor (alang sa Stapel ug Dockerfile). Ang bag-ong arkitektura sa pagtipig nagbukas sa posibilidad sa pagpatuman sa gipang-apod-apod nga mga asembliya gikan sa daghang mga host ug parallel nga mga asembliya sa parehas nga host.
Ang pag-optimize sa trabaho naglakip sa pagtangtang sa wala kinahanglana nga mga kalkulasyon sa yugto sa pagkalkula sa mga pirma sa entablado ug pagbag-o sa mga mekanismo sa pagkalkula sa mga checksum sa file aron mahimong mas episyente. Kini nga pag-optimize nagpamenos sa kasagaran nga oras sa pagtukod sa proyekto gamit ang werf. Ug ang mga idle build, kung ang tanan nga mga yugto anaa sa cache yugto-pagtipig, karon paspas na kaayo. Sa kadaghanan nga mga kaso, ang pagsugod pag-usab sa pagtukod dili moubos sa 1 segundo! Kini magamit usab sa mga pamaagi sa pag-verify sa mga yugto sa proseso sa trabaho sa mga grupo. werf deploy и werf run.
Usab sa kini nga pagpagawas, usa ka estratehiya sa pag-tag sa mga imahe pinaagi sa sulud nagpakita - tag-tag nga gibase sa sulod, nga karon gipalihok pinaagi sa default ug ang usa ra nga girekomenda.
Atong tan-awon pag-ayo ang yawe nga mga inobasyon sa werf v1.1, ug sa samang higayon nagsulti kanimo mahitungod sa mga plano alang sa umaabot.
Unsa ang nausab sa werf v1.1?
Bag-ong format sa pagngalan sa yugto ug algorithm alang sa pagpili sa mga yugto gikan sa cache
Bag-ong lagda sa henerasyon sa ngalan sa entablado. Karon ang matag yugto sa pagtukod makamugna og usa ka talagsaon nga ngalan sa entablado, nga naglangkob sa 2 ka bahin: usa ka pirma (sama sa v1.0) ug usa ka talagsaon nga temporaryo nga identifier.
Pananglitan, ang tibuok ngalan sa hulagway sa entablado mahimong sama niini:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...o sa kinatibuk-an:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Здесь:
-
SIGNATUREusa ka pirma sa entablado, nga nagrepresentar sa identifier sa sulod sa entablado ug nagdepende sa kasaysayan sa mga pag-edit sa Git nga mitultol niini nga sulod; -
TIMESTAMP_MILLISECmao ang usa ka garantisadong talagsaon nga larawan identifier nga namugna sa panahon sa usa ka bag-o nga larawan nga gitukod.
Ang algorithm sa pagpili sa mga yugto gikan sa cache gibase sa pagsusi sa relasyon sa Git commit:
- Gikalkulo ni Werf ang pirma sa usa ka yugto.
- В yugto-pagtipig Mahimong adunay daghang mga yugto alang sa gihatag nga pirma. Gipili ni Werf ang tanan nga mga yugto nga mohaum sa pirma.
- Kung ang karon nga yugto nalambigit sa Git (git-archive, naandan nga yugto nga adunay mga patch sa Git:
install,beforeSetup,setup; o git-latest-patch), unya gipili lamang sa werf ang mga yugto nga nalangkit sa usa ka commit nga usa ka katigulangan sa kasamtangan nga commit (nga gitawag ang pagtukod). - Gikan sa nahabilin nga angay nga mga yugto, gipili ang usa - ang labing karaan sa petsa sa paglalang.
Ang usa ka yugto alang sa lainlaing mga sanga sa Git mahimong adunay parehas nga pirma. Apan pugngan sa werf ang cache nga adunay kalabotan sa lainlaing mga sanga nga magamit taliwala sa kini nga mga sanga, bisan kung ang mga pirma magkatugma.
.
Bag-ong algorithm alang sa paghimo ug pagtipig sa mga yugto sa pagtipig sa entablado
Kung, kung nagpili mga yugto gikan sa cache, ang werf wala makit-an ang angay nga yugto, nan ang proseso sa pag-assemble sa usa ka bag-ong yugto gisugdan.
Timan-i nga daghang mga proseso (sa usa o daghan pa nga mga host) mahimong magsugod sa pagtukod sa parehas nga yugto sa hapit parehas nga oras. Gigamit ni Werf ang usa ka malaumon nga blocking algorithm yugto-pagtipig sa higayon sa pagtipig sa bag-ong nakolekta nga imahe sa yugto-pagtipig. Niining paagiha, kung andam na ang bag-ong yugto sa pagtukod, ang werf block yugto-pagtipig ug magtipig og bag-ong nakolekta nga hulagway didto lamang kung wala na ang angay nga hulagway didto (pinaagi sa pirma ug uban pang mga parameter - tan-awa ang bag-ong algorithm alang sa pagpili sa mga yugto gikan sa cache).
Ang usa ka bag-ong natapok nga imahe gigarantiyahan nga adunay usa ka talagsaon nga identifier pinaagi sa TIMESTAMP_MILLISEC (tan-awa ang bag-ong pormat sa pagngalan sa entablado). Sa kaso sa yugto-pagtipig makit-an ang usa ka angay nga imahe, isalikway ni werf ang bag-ong naipon nga imahe ug gamiton ang imahe gikan sa cache.
Sa laing pagkasulti: ang una nga proseso sa paghuman sa pagtukod sa imahe (ang pinakapaspas nga usa) makakuha sa katungod sa pagtipig niini sa mga yugto-pagtipig (ug unya kini nga usa ka imahe nga gamiton alang sa tanan nga mga pagtukod). Ang usa ka hinay nga proseso sa pagtukod dili gayud makababag sa usa ka mas paspas nga proseso gikan sa pagtipig sa mga resulta sa pagtukod sa kasamtangan nga yugto ug sa pagpadayon sa sunod nga pagtukod.
.
Gipauswag ang performance sa Dockerfile builder
Sa pagkakaron, ang pipeline sa mga yugto alang sa usa ka imahe nga gitukod gikan sa usa ka Dockerfile naglangkob sa usa ka yugto - dockerfile. Kung gikalkula ang pirma, ang checksum sa mga file gikalkula context, nga gamiton panahon sa asembliya. Sa wala pa kini nga pag-uswag, ang werf balik-balik nga naglakaw sa tanan nga mga file ug nakakuha usa ka checksum pinaagi sa pagsuma sa konteksto ug mode sa matag file. Sugod sa v1.1, ang werf mahimong mogamit sa mga kalkulado nga checksum nga gitipigan sa usa ka Git repository.
Ang algorithm gibase sa . Gikonsiderar sa algorithm ang mga rekord sa .dockerignore ug moagi sa file tree balik-balik lang kung gikinahanglan. Sa ingon, kami nag-decoupled gikan sa pagbasa sa file system, ug ang pagsalig sa algorithm sa gidak-on context dili mahinungdanon.
Gisusi usab sa algorithm ang wala masubay nga mga file ug, kung kinahanglan, gikonsiderar kini sa checksum.
Mas maayo nga performance kung mag-import og mga file
Ang mga bersyon sa werf v1.1 naggamit ug rsync server kung kanus-a . Kaniadto, ang pag-import gihimo sa duha ka mga lakang gamit ang usa ka directory mount gikan sa host system.
Ang pasundayag sa pag-import sa macOS dili na limitado sa mga volume sa Docker, ug kompleto ang mga pag-import sa parehas nga oras sa Linux ug Windows.
Pag-tag nga gibase sa sulud
Gisuportahan sa Werf v1.1 ang gitawag nga pag-tag pinaagi sa sulud sa imahe - tag-tag nga gibase sa sulod. Ang mga tag sa resulta nga mga imahe sa Docker nagdepende sa mga sulud sa kini nga mga imahe.
Sa diha nga nagdagan sa sugo werf publish --tags-by-stages-signature o werf ci-env --tagging-strategy=stages-signature gipatik nga mga hulagway sa gitawag nga pirma sa entablado hulagway. Ang matag hulagway gi-tag nga adunay kaugalingong pirma sa mga yugto niini nga hulagway, nga gikalkulo sumala sa samang mga lagda sa regular nga pirma sa matag yugto nga gilain, apan usa ka kinatibuk-ang identifier sa hulagway.
Ang pirma sa mga yugto sa imahe nagdepende sa:
- ang sulod niini nga hulagway;
- kasaysayan sa mga kausaban sa Git nga mitultol niini nga sulod.
Ang usa ka Git repository kanunay adunay dummy commits nga dili makausab sa sulod sa mga file sa imahe. Pananglitan, nag-commit nga adunay mga komento lamang o nag-merge sa mga commit, o nag-commit nga nagbag-o sa mga file sa Git nga dili ma-import sa imahe.
Kung gigamit ang tag nga nakabase sa sulud, ang mga problema sa dili kinahanglan nga pag-restart sa mga pod sa aplikasyon sa Kubernetes tungod sa mga pagbag-o sa ngalan sa imahe masulbad, bisan kung ang sulud sa imahe wala mausab. Pinaagi sa dalan, kini usa sa mga hinungdan nga nagpugong sa pagtipig sa daghang mga microservice sa usa ka aplikasyon sa usa ka Git repository.
Usab, ang pag-tag nga nakabase sa sulud usa ka mas kasaligan nga pamaagi sa pag-tag kaysa pag-tag sa mga sanga sa Git, tungod kay ang sulud sa mga sangputanan nga mga imahe wala magdepende sa han-ay kung diin ang mga pipeline gipatuman sa sistema sa CI alang sa pag-assemble sa daghang mga commit sa parehas nga sanga.
importante: sugod karon yugto-pirma Mao ba ang bugtong girekomendar nga estratehiya sa pag-tag. Kini gamiton sa default sa command werf ci-env (gawas kung klaro nga imong gitakda ang lahi nga laraw sa pag-tag).
. Usa ka bulag nga publikasyon ang igahin usab sa kini nga bahin. UPDATED (Abril 3): Artikulo nga adunay mga detalye .
Mga lebel sa pag-log
Ang tiggamit karon adunay higayon nga makontrol ang output, itakda ang lebel sa pag-log ug magtrabaho uban ang impormasyon sa pag-debug. Gidugang ang mga kapilian --log-quiet, --log-verbose, --log-debug.
Sa kasagaran, ang output naglangkob sa minimum nga impormasyon:
Kung gigamit ang verbose output (--log-verbose) imong makita kung giunsa ang pagtrabaho sa werf:
Detalyadong output (--log-debug), dugang sa impormasyon sa pag-debug sa werf, adunay usab mga log sa gigamit nga mga librarya. Pananglitan, imong makita kung giunsa ang pakig-uban sa Docker Registry mahitabo, ug irekord usab ang mga lugar diin gigugol ang daghang oras:
Mga plano sa umaabot
Pasidaan Ang mga opsyon nga gihulagway sa ubos gimarkahan v1.1 mahimong magamit sa kini nga bersyon, kadaghanan kanila sa umaabot nga umaabot. Ang mga update moabut pinaagi sa mga auto-update . Kini nga mga bahin dili makaapekto sa lig-on nga bahin sa v1.1 nga mga gimbuhaton; ang ilang hitsura wala magkinahanglan og manwal nga interbensyon sa tiggamit sa kasamtangan nga mga configuration.
Bug-os nga suporta alang sa lainlaing mga pagpatuman sa Docker Registry (BAG-O)
- Bersyon: v1.1
- Mga Petsa: Marso
Ang tumong mao ang paggamit sa usa ka kostumbre nga pagpatuman nga walay mga pagdili sa paggamit sa werf.
Sa pagkakaron, nahibal-an na namo ang mosunod nga hugpong sa mga solusyon nga gusto namo nga garantiya sa hingpit nga suporta:
- Default (librarya/registry)*,
- AWS ECR
- Azure*,
- Docker Hub
- GCR*,
- Mga Pakete sa GitHub
- GitLab Registry*,
- Dunggoanan*,
- Quay.
Ang mga solusyon nga sa pagkakaron hingpit nga gisuportahan sa werf gimarkahan og asterisk. Alang sa uban adunay suporta, apan adunay mga limitasyon.
Duha ka dagkong mga problema ang mailhan:
- Ang ubang mga solusyon wala nagsuporta sa pagtangtang sa tag gamit ang Docker Registry API, nga nagpugong sa mga tiggamit sa paggamit sa werf's automatic cleanup. Tinuod kini alang sa AWS ECR, Docker Hub, ug GitHub Packages.
- Ang ubang mga solusyon wala mosuporta sa gitawag nga nested repository (Docker Hub, GitHub Packages ug Quay) o buhaton, apan ang user kinahanglang maghimo niini nga mano-mano gamit ang UI o API (AWS ECR).
Among sulbaron kini ug uban pang mga problema gamit ang lumad nga mga API sa mga solusyon. Kini nga buluhaton naglakip usab sa pagtabon sa tibuok nga siklo sa operasyon sa werf nga adunay mga pagsulay alang sa matag usa niini.
Giapod-apod nga paghimo sa imahe (↑)
- Bersyon: v1.2 v1.1 (ang prayoridad sa pagpatuman niini nga bahin gidugangan)
- Mga Petsa: Marso-Abril Marso
Sa pagkakaron, ang werf v1.0 ug v1.1 magamit lamang sa usa ka dedikado nga host para sa mga operasyon sa pagtukod ug pagmantala sa mga hulagway ug pag-deploy sa aplikasyon ngadto sa Kubernetes.
Aron maablihan ang mga posibilidad sa gipang-apod-apod nga trabaho sa werf, kung ang pagtukod ug pag-deploy sa mga aplikasyon sa Kubernetes gilansad sa daghang mga arbitraryong host ug kini nga mga host wala magtipig sa ilang estado taliwala sa mga pagtukod (temporaryo nga mga runner), gikinahanglan ang werf nga ipatuman ang abilidad sa paggamit ang Docker Registry isip usa ka tindahan sa entablado.
Kaniadto, sa dihang ang werf nga proyekto gitawag pa nga dapp, kini adunay ingon nga oportunidad. Bisan pa, nakasugat kami daghang mga isyu nga kinahanglan nga tagdon kung ipatuman kini nga pagpaandar sa werf.
Примечание. Kini nga bahin wala magkinahanglan nga ang kolektor magtrabaho sulod sa mga pod sa Kubernetes, tungod kay Aron mahimo kini, kinahanglan nimo nga kuhaon ang pagsalig sa lokal nga Docker server (sa Kubernetes pod walay access sa lokal nga Docker server, tungod kay ang proseso mismo nagdagan sa usa ka sudlanan, ug ang werf dili ug dili mosuporta nagtrabaho kauban ang Docker server sa network). Ang suporta sa pagpadagan sa Kubernetes ipatuman nga gilain.
Opisyal nga suporta alang sa GitHub Actions (BAG-O)
- Bersyon: v1.1
- Mga Petsa: Marso
Naglakip sa dokumentasyon sa werf (mga seksyon reperensiya и sa paggiya), ingon man ang opisyal nga GitHub Action alang sa pagtrabaho kauban ang werf.
Dugang pa, kini magtugot sa werf nga magtrabaho sa mga ephemeral runners.
Ang mga mekaniko sa interaksyon sa gumagamit sa sistema sa CI ibase sa pagbutang sa mga label sa mga hangyo sa pagbitad aron masugdan ang pipila nga mga aksyon aron matukod / ma-roll out ang aplikasyon.
Lokal nga pag-uswag ug pag-deploy sa mga aplikasyon nga adunay werf (↓)
- Bersyon: v1.1
- Mga Petsa: Enero-Pebrero Abril
Ang panguna nga katuyoan mao ang pagkab-ot sa usa ka hiniusa nga config alang sa pag-deploy sa mga aplikasyon sa lokal ug sa produksiyon, nga wala’y komplikado nga mga aksyon, sa gawas sa kahon.
Ang werf gikinahanglan usab nga adunay operating mode diin kini sayon sa pag-edit sa application code ug diha-diha dayon makadawat og feedback gikan sa running application alang sa debugging.
Bag-ong algorithm sa pagpanglimpyo (BAG-O)
- Bersyon: v1.1
- Mga Petsa: Abril
Sa kasamtangan nga bersyon sa werf v1.1 sa pamaagi cleanup Wala'y probisyon alang sa paglimpyo sa mga imahe alang sa laraw sa pag-tag nga gibase sa sulud - kini nga mga imahe magtipon.
Usab, ang kasamtangan nga bersyon sa werf (v1.0 ug v1.1) naggamit sa lain-laing mga polisiya sa paglimpyo alang sa mga hulagway nga gipatik ubos sa mga laraw sa pag-tag: Git branch, Git tag o Git commit.
Usa ka bag-ong algorithm alang sa paglimpyo sa mga imahe base sa kasaysayan sa mga commit sa Git, nahiusa alang sa tanan nga mga laraw sa pag-tag, naimbento:
- Hupti ang dili labaw pa sa N1 nga mga hulagway nga may kalabutan sa N2 nga pinakabag-o nga commit alang sa matag git HEAD (mga sanga ug mga tag).
- Pagtipig dili labaw pa sa N1 nga mga hulagway sa entablado nga may kalabutan sa N2 nga pinakabag-o nga mga commit alang sa matag git HEAD (mga sanga ug mga tag).
- Tipigi ang tanang hulagway nga gigamit sa bisan unsang Kubernetes cluster resources (tanan nga kube contexts sa configuration file ug namespaces gi-scan; mahimo nimong limitahan kini nga kinaiya gamit ang espesyal nga mga opsyon).
- Tipigi ang tanang mga hulagway nga gigamit sa resource configuration manifests nga gitipigan sa Helm releases.
- Ang usa ka imahen mahimong matangtang kung wala kini kauban sa bisan unsang HEAD gikan sa git (pananglitan, tungod kay ang katugbang nga HEAD mismo gitangtang) ug wala gigamit sa bisan unsang mga pagpakita sa cluster sa Kubernetes ug sa mga pagpagawas sa Helm.
Parallel image building (↓)
- Bersyon: v1.1
- Mga Petsa: Enero-Pebrero Abril*
Ang karon nga bersyon sa werf nagkolekta sa mga imahe ug artifact nga gihulagway sa werf.yaml, sunodsunod. Gikinahanglan nga ipahiangay ang proseso sa pag-assemble sa mga independente nga yugto sa mga imahe ug artifact, ingon man paghatag og kombenyente ug informative nga output.
* Matikdi: ang deadline gibalhin tungod sa dugang nga prayoridad alang sa pagpatuman sa giapod-apod nga asembliya, nga makadugang sa dugang nga horizontal scaling nga mga kapabilidad, ingon man ang paggamit sa werf sa GitHub Actions. Ang parallel assembly mao ang sunod nga lakang sa pag-optimize, nga naghatag ug bertikal nga scalability kung mag-assemble sa usa ka proyekto.
Pagbalhin ngadto sa Helm 3 (↓)
- Bersyon: v1.2
- Petsa: Pebrero-Marso Mayo*
Naglakip sa paglalin sa bag-ong codebase ug usa ka napamatud-an, kombenyente nga paagi sa pagbalhin sa kasamtangan nga mga instalasyon.
* Matikdi: ang pagbalhin sa Helm 3 dili makadugang ug mahinungdanong bahin sa werf, tungod kay ang tanang importanteng bahin sa Helm 3 (3-way-merge ug walay tiller) kay gipatuman na sa werf. Dugang pa, ang werf adunay dugang sa mga gipakita. Bisan pa, kini nga pagbalhin nagpabilin sa among mga plano ug ipatuman.
Jsonnet para sa paghulagway sa Kubernetes configuration (↓)
- Bersyon: v1.2
- Mga Petsa: Enero-Pebrero Abril-Mayo
Suportado sa Werf ang mga deskripsyon sa pagsumpo para sa Kubernetes sa format nga Jsonnet. Sa parehas nga oras, ang werf magpabilin nga katugma sa Helm ug adunay kapilian nga pormat sa paghulagway.
Ang hinungdan mao nga ang mga template sa Go, sumala sa daghang mga tawo, adunay taas nga babag sa pagsulod, ug ang pagkasabut sa code sa kini nga mga template nag-antus usab.
Ang posibilidad sa pagpaila sa ubang mga sistema sa paghulagway sa configuration sa Kubernetes (pananglitan, Kustomize) gikonsiderar usab.
Nagtrabaho sulod sa Kubernetes (↓)
- Bersyon: v1.2
- Petsa: Abril-Mayo-Hunyo
Tumong: Siguruha nga ang mga imahe gihimo ug ang aplikasyon gihatag gamit ang mga runner sa Kubernetes. Mga. Ang bag-ong mga hulagway mahimong mabuhat, mamantala, malimpyohan, ug ma-deploy direkta gikan sa mga pod sa Kubernetes.
Aron mapatuman kini nga kapabilidad, kinahanglan una nimo nga makahimo sa pag-apod-apod nga mga imahe (tan-awa ang punto sa ibabaw).
Nagkinahanglan usab kini og suporta alang sa operating mode sa builder nga walay Docker server (ie Kaniko-like build o build in userspace).
Suportado sa Werf ang pagtukod sa Kubernetes dili lamang sa Dockerfile, kondili usab sa Stapel builder niini nga adunay mga incremental rebuilds ug Ansible.
Usa ka lakang padulong sa bukas nga kalamboan
Gimahal namo ang among komunidad (, ) ug gusto namo nga mas daghang tawo ang motabang sa paghimo sa werf nga mas maayo, masabtan ang direksyon nga among giagian, ug moapil sa kalamboan.
Bag-o lang nakahukom nga mobalhin sa aron mapadayag ang proseso sa pagtrabaho sa among team. Karon makita nimo ang mga dinalian nga plano, ingon man ang karon nga trabaho sa mga musunud nga lugar:
- ;
- ;
- ;
- .
Daghang trabaho ang nahimo sa mga isyu:
- Gitangtang ang mga wala’y kalabotan.
- Ang mga anaa na gidala sa usa ka format, nga adunay igo nga gidaghanon sa mga detalye ug mga detalye.
- Bag-ong mga isyu sa mga ideya ug mga sugyot gidugang.
Giunsa pagpaandar ang bersyon v1.1
Ang bersyon anaa karon sa (sa mga kanal Lig и lig-on nga bato Ang mga pagpagawas makita samtang mahitabo ang pag-stabilize, bisan pa ea sa iyang kaugalingon igo na nga lig-on alang sa paggamit, tungod kay miagi sa mga kanal Alpha и Beta). Gi-activate sa mosunod nga paagi:
source $(multiwerf use 1.1 ea)
werf COMMAND ...konklusyon
Ang bag-ong arkitektura sa pagtipig sa entablado ug mga pag-optimize sa tigtukod alang sa mga magtutukod sa Stapel ug Dockerfile nagbukas sa posibilidad sa pagpatuman sa giapod-apod ug parehas nga mga pagtukod sa werf. Kini nga mga bahin makita sa dili madugay sa parehas nga pagpagawas v1.1 ug mahimong awtomatiko nga magamit pinaagi sa mekanismo sa awtomatikong pag-update (alang sa mga tiggamit ).
Niini nga pagpagawas, usa ka estratehiya sa pag-tag base sa sulud sa imahe ang gidugang - tag-tag nga gibase sa sulod, nga nahimong default nga estratehiya. Ang nag-unang command log gi-rework usab: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Ang sunod nga hinungdanon nga lakang mao ang pagdugang sa giapod-apod nga mga asembliya. Ang gipang-apod-apod nga mga pagtukod nahimong mas taas nga prayoridad kay sa parallel build sukad sa v1.0 tungod kay kini nagdugang og dugang nga bili sa werf: vertical scaling sa mga magtutukod ug suporta alang sa ephemeral builders sa nagkalain-laing mga CI / CD system, ingon man ang abilidad sa paghimo sa opisyal nga suporta alang sa GitHub Actions . Busa, ang mga deadline sa pagpatuman alang sa parallel assemblies gibalhin. Bisan pa, kami naningkamot sa pagpatuman sa duha ka mga posibilidad sa labing dali nga panahon.
Sunda ang balita! Ug ayaw kalimot sa pagbisita kanamo sa sa paghimo og usa ka isyu, pangitaa ang usa nga anaa na ug pagdugang og dugang, paghimo og PR, o tan-awa lang ang kalamboan sa proyekto.
PS
Basaha usab sa among blog:
- «»
- «";
- Usa ka serye sa mga nota bahin sa mga inobasyon sa werf:
- «";
- «";
- «";
- «".
Source: www.habr.com