BUILD TOOLS

Ein Ein­stieg in die Welt der au­to­ma­ti­sier­ten Pro­zes­se

SCREENGUIDE - - Events - TEXT: Ste­fan Baum­gart­ner

Das CSS soll bit­te mög­lichst mo­du­lar ge­schrie­ben wer­den – und na­tür­lich kompakt, kom­pri­miert und oh­ne Red­un­dan­zen. Bei Ja­vaS­cript möch­ten Sie die hei­ßes­ten Fea­tu­res ver­wen­den, aber trotz­dem al­te Brow­ser be­die­nen. Und wenn Sie doch die HTMLDa­tei des Me­nüs nur ein­mal be­ar­bei­ten müss­ten und trotz­dem al­le Sei­ten ak­tua­li­siert wür­den! Doch nicht nur das: Oft ist ei­ne Rei­he an Vor­gän­gen nö­tig, um das Re­sul­tat so aus­zu­lie­fern, wie es all­ge­mein als op­ti­mal gilt. Sie kom­pi­lie­ren Sass nach CSS, mi­ni­fi­zie­ren, in­dem Sie un­nö­ti­ge Whi­te­s­paces und Long­hand Pro­per­ties lö­schen, und fü­gen noch dort Ven­dor Pre­fi­xes hin­zu, wo

es nö­tig ist. Vor­her müs­sen Sie sich na­tür­lich erst schlau ma­chen, wel­che Pre­fi­xes Sie über­haupt für Ih­re Ziel­platt­form be­nö­ti­gen. Web­wor­ker ken­nen al­le die mü­he­vol­le Haus­ar­beit, die sel­ten ma­nu­ell durch­führ­bar ist. Die Lö­sung fin­det sich in ei­ner Viel­zahl an Werk­zeu­gen. Prä­pro­zes­so­ren wie Sass sind aus der CSS-Ent­wick­lung nicht mehr weg­zu­den­ken. Ty­peS­cript ist en vo­gue und er­freut sich nicht nur im En­ter­pri­se- und An­gu­lar-Um­feld größ­ter Be­liebt­heit (sie­he Screen­gui­de #35). Lö­sun­gen exis­tie­ren al­so, al­ler­dings sind die­se oft nur schwer un­ter ei­nen Hut zu brin­gen. Un­ter­schied­li­che Schnitt­stel­len oder sehr spe­zi­fi­sche An­wen­dungs­fäl­le las­sen Web­wor­ker oft mehr Zeit mit dem Werk­zeug selbst ver­brin­gen als mit der ei­gent­li­chen Ar­beit. Die gu­te Nach­richt: Hier schafft ei­ne Re­kur­si­on Ab­hil­fe. Für un­se­re Werk­zeu­ge gibt es Werk­zeu­ge! Die schlech­te Nach­richt: Das Öko­sys­tem ist mitt­ler­wei­le wie Un­kraut ge­wach­sen und oh­ne Rei­se­füh­rer ziem­lich un­durch­sich­tig. Auf den fol­gen­den Sei­ten wol­len wir ei­ne Über­sicht bie­ten und für je­den Gus­to das rich­ti­ge Werk­zeug fin­den. Da­bei hal­ten wir uns ge­zielt im No­de.js-Öko­sys­tem auf. Das ist ei­ner­seits viel nä­her an den Aus­gangs­da­ten, die wir be­ar­bei­ten möch­ten. An­de­rer­seits gibt es dort auch den ein­gangs be­schrie­be­nen Wild­wuchs. CO­DE­KIT FÜR TIPP-VER­WEI­GE­RER Als Auf­wärm­übung blei­ben wir zu­nächst gra­fisch. Vie­le der Werk­zeu­ge, die wir bän­di­gen wol­len, neh­men ei­nen be­stimm­ten Ein­ga­be­typ und spu­cken an­schlie­ßend HTML, CSS oder Ja­vaS­cript raus. Je­der Ein­ga­be­typ be­sitzt nor­ma­ler­wei­se ei­ne ty­pen­spe­zi­fi­sche Da­tei­en­dung. TS für Ty­peS­cript, SCSS für Sass. Auf Ba­sis die­ser Da­tei­en­dun­gen kann ein Werk­zeug na­mens Co­de­Kit ein Stan­dard­set an Pro­zes­sen vor­de­fi­nie­ren [code­ki­tapp. com]. Die Desk­to­pan­wen­dung er­laubt per Drag-and-Drop gan­ze Pro­jek­te zu la­den und fin­det für je­den Da­tei­typ den pas­sen­den Pro­zess. Da­zu ge­hö­ren ne­ben ein­gangs er­wähn­ten Prä­pro­zes­so­ren auch die Grö­ßen­op­ti­mie­rung von Bild­in­hal­ten zu Per­for­man­ce­zwe­cken. Da­zu wer­den bei PNG-Da­tei­en neue Farb­for­ma­te ge­wählt, JPEG- und SVG-Da­tei­en wie­der­um wer­den von un­nö­ti­gen Me­ta-In­for­ma­tio­nen be­freit. Ein Scan durch das Ver­zeich­nis fin­det al­le be­ar­beit­ba­ren In­pu­tDa­tei­en und stellt für den Kom­pi­lier­vor­gang De­fault-Pa­ra­me­ter ein. Ist ei­ner der au­to­ma­tisch iden­ti­fi­zier­ten Vor­gän­ge falsch, kön­nen Sie hän­disch nach­bes­sern. Die au­to­ma­ti­sche Er­ken­nung ist al­ler­dings sehr so­li­de. Ein Klick auf „Build Pro­ject” setzt die He­bel in Be­we­gung: Sass wird zu CSS kom­pi­liert, da­nach wer­den mit Au­to­pre­fi­xer Ven­dor Pre­fi­xes au­to­ma­tisch hin­zu­ge­fügt (mit Feed­back von ca­ni­use.com). Ty­peS­cript wird nach Ja­vaS­cript über­setzt und läuft durch ei­nen Mi­ni­fi­ka­ti­ons­pro­zess. Hand­le­bars Tem­pla­tes wer­den zu voll­wer­ti­gen HTML-Sei­ten. Und auch Bil­der wer­den kom­pri­miert und op­ti­miert. Soll­te das nicht ge­nug sein oder sind di­ver­se Stell­schrau­ben ge­wünscht, kön­nen Sie je­den Pro­zess se­pa­rat kon­fi­gu­rie­ren. Die ge­tä­tig­ten Kon­fi­gu­ra­tio­nen kön­nen in ei­ner Da­tei ge­spei­chert wer­den. Co­de­Kit ist seit je­her die Ein­stiegs­dro­ge für Au­to­ma­ti­sie­rungs­Neu­gie­ri­ge in der Web­welt. Mit nur ei­nem Knopf­druck füh­ren Sie ei­ne Viel­zahl an Werk­zeu­gen aus, die nicht nur das Edi­tie­ren und Be­ar­bei­ten der Da­tei­en ein­fa­cher ma­chen, son­dern auch das op­ti­mier­te Aus­lie­fern der sel­bi­gen. Mitt­ler­wei­le ist die Desk­to­pan­wen­dung auch platt­for­mun­ab­hän­gig und läuft auf Elec­tron. Win­dows- und Li­nux-Nut­zer sind al­so eben­falls gut auf­ge­ho­ben. Wer spen­da­bel ist, darf den Er­stel­ler mit ein paar Dol­lars un­ter­stüt­zen und si­chert so den Fort­be­stand der Ap­pli­ka­ti­on. Co­de­Kit eig­net sich al­so her­vor­ra­gend für Ein-Per­so­nen-Agen­tu­ren, die auf ih­re Hand­ar­beit viel Wert le­gen und auch noch hän­disch Da­tei­en per FTP rauf­schie­ben. So­bald Sie Con­ti­nuous De­li­very be­trei­ben möch­ten (sie­he un­ten), rei­chen die Mög­lich­kei­ten des GUI-ba­sier­ten Co­de­kits nicht mehr aus. Hier be­nö­ti­gen Sie et­was Fle­xi­ble­res. Et­was, das Sie auch auf ei­ner Ma­schi­ne oh­ne gra­fi­sche Ober­flä­chen lau­fen las­sen kön­nen. SKRIPTING MIT NPM Ei­ne Samm­lung klei­ne­rer Skrip­te als Build Tool zu ver­wen­den, ist ei­ne Idee, die mitt­ler­wei­le mehr als 40 Jah­re zu­rück­liegt. 1977 er­schien näm­lich die ers­te Ver­si­on von Ma­ke. Ma­ke ist ei­ne Soft­ware, in der Sie mit ein­fa­chen Ein­sprungs­mar­ken Kom­man­do­zei­len­be­feh­le aus­füh­ren konn­ten. An­statt die ge­sam­te GnuC++-Com­pi­ler-Pa­ra­me­ter­lis­te je­des Mal hän­disch ein­zu­tip­pen, reich­te ein „ma­ke build”, und der Be­fehl samt Ab­hän­gig­kei­ten wur­de aus­ge­führt. Ma­ke kann tat­säch­lich auch heu­te noch ganz un­pro­ble­ma­tisch ver­wen­det wer­den. Al­ler­dings sind Al­ter­na­ti­ven wie die un­ten­ste­hend be­schrie­be­ne doch ein we­nig ele­gan­ter. Vor al­lem, wenn Sie sich schon im No­de.js-Öko­sys­tem be­we­gen. Als Webent­wick­ler kom­men Sie kaum an Ja­vaS­cript vor­bei. No­de. js bie­tet ei­ne Ja­vaS­cript-Lauf­zeit­um­ge­bung oh­ne Brow­ser­kon­text. Da­für aber mit Zu­griff auf Pro­zes­se des Be­triebs­sys­tems und das Da­tei­sys­tem. Klingt nach ei­nem gu­ten Zu­gang für un­ser Pro­blem. Den ein­fachs­ten Weg von ei­ner gra­fi­schen Be­nut­zer­ober­flä­che hin zu et­was, das Sie per Tas­ten­druck auf der Kom­man­do­zei­le aus­füh­ren, bie­tet das No­de.js-Öko­sys­tem frei Haus an: NPM, der No­de.js Pa­ket­ma­na­ger, und die da­mit ver­bun­de­ne pa­cka­ge.json. So ziem­lich je­des Werk­zeug, das Sie als Webent­wick­ler ver­wen­den, ist via NPM ver­füg­bar. Die meis­ten von die­sen kom­men mit ei­ge­nem Com­mand Li­ne In­ter­face.

Tipp: NPM-Skrip­te eig­nen sich auch her­vor­ra­gend da­für, Short­cuts für Gulp, Web­pack und Kon­sor­ten zu lie­fern. Da­mit ha­ben Sie un­ab­hän­gig vom Werk­zeug ein­fach zu mer­ken­de und gleich­lau­ten­de Be­feh­le, mit de­nen Sie ei­nen Kom­pi­lie­rungs­vor­gang star­ten kön­nen.

Die­se Com­mand Li­ne In­ter­faces kön­nen Sie nun über ei­nen be­nann­ten Ein­trag in der pa­cka­ge.json an­steu­ern. Neh­men wir an, wir wol­len un­se­re Sass-Fi­les nun über ein paar Skrip­te in CSS um­wan­deln. Wir in­stal­lie­ren da­zu die No­de.js Bridge für Sass. Shell $ npm in­stall no­de-sass Be­ach­ten Sie, dass Sie die­se Werk­zeu­ge, wie von vie­len In­stal­la­ti­ons­be­schrei­bun­gen ge­for­dert, nicht glo­bal in­stal­lie­ren und ver­füg­bar ma­chen müs­sen. Sie kön­nen no­de-sass lokal für Ihr Pro­jekt in­stal­lie­ren und ha­ben über NPM-Skrip­te Zu­griff auf das CLI. Da­durch ge­hen Sie ei­nem Ver­si­ons­cha­os aus dem Weg, das Sie mit glo­bal in­stal­lier­ten Ab­hän­gig­kei­ten im­mer be­kom­men. In der (eben er­stell­ten) pa­cka­ge.json fin­den Sie un­ter dem Ein­trag „de­pen­den­cies” die in­stal­lier­te Ab­hän­gig­keit. Die­se füh­ren wir nun durch ei­nen Ein­trag in „scripts” aus. pa­cka­ge.json { "na­me": "de­mo", "de­pen­den­cies": { "no­de-sass": "~3.5.4" }, "scripts": { ”build”: "no­de-sass in­put.scss out­put.css" }} Der Schlüs­sel des eben er­stell­ten Ein­trags ist ein Ali­as, mit dem NPM den Short­cut er­kennt. Im Wert des Ein­trags steht der CLIBe­fehl, der aus­ge­führt wer­den soll. Mit ei­nem „npm run build” auf der Kom­man­do­zei­le wird nun die­ser Short­cut aus­ge­führt: Das Tool „no­de-sass” kom­pi­liert die Da­tei in­put.scss und spei­chert das Er­geb­nis in out­put.css. NPM-Skrip­te kön­nen an­de­re NPMSkrip­te auf­ru­fen. Au­ßer­dem gibt es ein paar vor­ge­fer­tig­te Na­men, die NPM nach In­stal­la­ti­ons­vor­gän­gen und Ähn­li­chem trig­gert. Mit die­ser Än­de­rung ha­ben Sie Fol­gen­des er­reicht: • Sie kön­nen nun über ein kla­res In­ter­face Ih­re Tools an­steu­ern.

• Je­des Tool ist in der Ver­si­on für das je­wei­li­ge Pro­jekt ein­deu­tig. Sie be­nö­ti­gen auch kei­ne glo­bal zu­gäng­li­che Soft­ware mehr (mit Aus­nah­me von NPM und No­de.js). • NPM-Skrip­te kön­nen an­de­re NPM-Skrip­te auf­ru­fen. Ein „npm run sty­les && npm run scripts” beim „build”-Ein­trag führt zwei un­ter­schied­li­che Tasks aus.

• Sie sind be­reit, um mit ver­schie­de­nen Con­ti­nuous-De­li­ver­ySys­te­men zu ar­bei­ten. „npm run build” ist so­gar Stan­dard­auf­ruf bei Ser­vern wie Tra­vis. Da­mit sind wir der Au­to­ma­ti­sie­rung schon ei­nen gro­ßen Schritt nä­her­ge­kom­men. NPM-Skrip­te kön­nen al­ler­dings in grö­ße­ren Pro­jek­ten schnell un­über­sicht­lich wer­den. Wol­len Sie un­ab­hän­gi­ge Tasks par­al­lel ab­ar­bei­ten, müs­sen Sie sich mit der Tas­k­aus­füh­rung des je­wei­li­gen Be­triebs­sys­tems aus­ein­an­der­set­zen. Au­ßer­dem bleibt das Pro­blem mit den un­ter­schied­li­chen Schnitt­stel­len un­ter­schied­li­cher Werk­zeu­ge. So blei­ben NPM-Skrip­te das per­fek­te Build Tool, wenn Sie mit klei­ne­ren, sehr über­schau­ba­ren Auf­ga­ben ar­bei­ten und de­fi­nier­te Ein­sprungs­punk­te in Ih­rem Pro­zess brau­chen. So­bald die ein­zel­nen Build-Schrit­te kom­ple­xer wer­den und Sie meh­re­re Auf­ga­ben nach­ein­an­der­ket­ten müs­sen, be­nö­ti­gen Sie et­was Fle­xi­ble­res.

GULP ALS TASK RUNNER

Ja­vaS­cript Task Runner ar­bei­ten ähn­lich zu den ein­gangs er­wähn­ten NPM-Skrip­ten, le­gen aber ei­ne Abs­trak­ti­ons­ebe­ne dar­über. An­statt die Werk­zeu­ge di­rekt an­zu­spre­chen und ih­nen mit ei­nem La­bel ei­nen Ali­as zu ge­ben, pro­gram­mie­ren Sie hier die Aus­füh­rung der Auf­ga­ben selbst. Das kann mit über­ra­schend lan­gen Kon­fi­gu­ra­ti­ons­da­tei­en pas­sie­ren oder aber ele­gant funk­tio­nal wie bei Gulp [gul­p­js.com]. Gleich vor­weg: War­um an die­ser Stel­le Gulp steht und nicht ei­nes der un­zäh­li­gen an­de­ren Build Tools, ist schlicht und er­grei­fend Ge­schmacks­sa­che. Al­ter­na­ti­ven wie Gr­unt, Broc­co­li, Brunch oder Ca­ke klin­gen nicht nur schmack­haf­ter, son­dern funk­tio­nie­ren ähn­lich gut. Für be­stimm­te Auf­ga­ben viel­leicht so­gar bes­ser! Gulp hat sich al­ler­dings nicht nur auf lan­ge Sicht be­währt, son­dern auch viel Zu­spruch in der Com­mu­ni­ty ge­fun­den. Die meis­ten Star­ter Kits, die nicht auf um­fang­rei­che Ja­vaS­cript-Ap­pli­ka­tio­nen set­zen, nut­zen Gulp un­ter der Hau­be, um die Soft­ware zu kom­pi­lie­ren. Gulp und Kon­sor­ten funk­tio­nie­ren in der Grund­struk­tur ähn­lich. Ein In­ter­face er­laubt, Tasks zu de­fi­nie­ren. Die­se Tasks ha­ben Na­men und sind so von au­ßen auf­ruf­bar. Im Un­ter­schied zu NPMSkrip­ten kön­nen Sie auch Ab­hän­gig­keits­bäu­me de­fi­nie­ren. Ein Task „build” muss vor­her „css”, „js” und „html” auf­ru­fen, be­vor er selbst star­ten darf. Die­se Ab­hän­gig­keits­bäu­me er­lau­ben ei­ne bes­se­re Ver­tei­lung der Auf­ga­ben. Sie kön­nen so si­cher­stel­len, dass vor je­dem Kom­pi­la­ti­ons­schritt zum Bei­spiel das Build-Ver­zeich­nis ge­löscht wird, um kei­ne un­ge­woll­ten Ar­te­fak­te zu er­zeu­gen. Ein Ja­vaS­crip­tKom­pi­lat hat im­mer ei­ne Test-Pha­se vor­aus, in der Unit und In­te­gra­ti­ons-Tests aus­ge­führt wer­den. Die­se test- und cle­an-Tasks kön­nen un­ab­hän­gig aus­ge­führt wer­den, sind aber als Ab­hän­gig­keit im­mer vor dem ge­wünsch­ten Task an der Rei­he.

In­ner­halb der Tasks setzt Gulp auf Ob­jekt­strö­me. Sämt­li­che Da­tei­en wer­den als vir­tu­el­le Da­ten­ob­jek­te ge­le­sen und in ei­nen No­de.js Ob­ject Stream ge­schickt. Da­mit wird Da­tei um Da­tei an ei­ne Rei­he Plug­ins wei­ter­ge­ge­ben. Die­se küm­mern sich um die Mo­di­fi­ka­ti­on. Als Ent­wick­ler kön­nen Sie sich so für je­des Auf­ga­ben­ge­biet ei­ne Aus­füh­rungs­pipe­line zu­sam­men­stel­len, in der un­ter­schied­li­che Ver­ar­bei­tungs­schrit­te nach und nach aus­ge­führt wer­den. Der dar­aus ent­ste­hen­de Co­de wird über­ra­schend über­schau­bar. Ein ge­sam­tes Gul­pfi­le hat in fol­gen­dem Co­de-Bei­spiel pro­blem­los Platz und küm­mert sich um das Kom­pi­lat von LESS, Ja­vaS­cript (in­klu­si­ve Sour­ce­maps) und HTML mit der Tem­pla­te-Spra­che Pug. Gul­pfi­le.js var gulp = re­qui­re('gulp'); var pug = re­qui­re('gulp-pug'); var less = re­qui­re('gulp-less'); var mi­ni­fyCSS = re­qui­re('gulp-cs­so'); var con­cat = re­qui­re('gulp-con­cat'); var pre­fix = re­qui­re('gulp-au­to­pre­fi­xer); var ug­li­fy = re­qui­re('gulp-ug­li­fy); var sour­ce­maps = re­qui­re('gulp-sour­ce­maps'); gulp.task('html', func­tion(){ re­turn gulp.src('cli­ent/tem­pla­tes/*.pug') .pipe(pug()) .pipe(gulp.dest('build/html'))}); gulp.task('css', func­tion(){ re­turn gulp.src('cli­ent/tem­pla­tes/*.less') .pipe(less()).pipe(mi­ni­fyCSS()) .pipe(pre­fix()) .pipe(gulp.dest('build/css'))}); gulp.task('js', func­tion(){ re­turn gulp.src('cli­ent/ja­vas­cript/*.js') .pipe(sour­ce­maps.in­it()) .pipe(con­cat('app.min.js')) .pipe(ug­li­fy()) .pipe(sour­ce­maps.wri­te()) .pipe(gulp.dest('build/js'))}); gulp.task('de­fault', [ 'html', 'css', 'js' ]); Die­ses Gul­pfi­le ent­hält al­le nö­ti­gen Bau­an­wei­sun­gen. In un­se­rem Bei­spiel wer­den „Pug”-Da­tei­en nach HTML kom­pi­liert. Un­se­re LESS-Da­tei­en (LESS ist ein Prä­pro­zes­sor, ähn­lich wie Sass) wer­den nach CSS kom­pi­liert, mi­ni­fi­ziert und dann mit Au­to­pre­fi­xer auf den neu­en Stand ge­bracht. Ja­vaS­cript wird zu­erst in ei­ne Da­tei kon­ka­te­niert (zu­sam­men­ge­fügt), da­nach mi­ni­fi­ziert. Für ein­fa­che­res De­bug­gen schreibt der Task auch Sour­ce­maps raus. Da­mit fin­det ein Brow­ser wie­der den Weg vom Kom­pi­lat zu den Ori­gi­nal­da­tei­en (sie­he Screen­gui­de #25). Ein „gulp js” kom­pi­liert nur den Ja­vaS­cript-Task. Ein „gulp de­fault” bzw. ein ein­fa­ches „gulp” führt den Stan­dard-Task aus, der zu­erst al­le drei als Ab­hän­gig­kei­ten de­fi­nier­ten Vor­gän­ge aus­füh­ren soll. Sehr über­schau­bar und auch sehr gut greif­bar. Die Struk­tur mit an­ein­an­der­ge­reih­ten Plug­ins er­laubt Ih­nen auch, meh­re­re Tools pro Task zu ver­wen­den, für je­den An­wen­dungs­fall ei­gens zu­ge­schnit­ten. Die Vor­tei­le lie­gen auf der Hand: • Un­ab­hän­gi­ge Tasks kön­nen par­al­lel ab­ge­ar­bei­tet wer­den. Das er­laubt ei­ne Ver­ket­tung von Shell-Skrip­ten nicht so ein­fach.

• Durch das Wei­ter­rei­chen von Da­tei­ob­jek­ten er­rei­chen Sie auch in­ner­halb ei­nes Tasks ma­xi­ma­le Par­al­le­li­tät.

• Ist ein Ver­ar­bei­tungs­schritt ei­ner Pi­pe­line auf ein­mal un­er­wünscht, müs­sen Sie nur ei­ne Zei­le ent­fer­nen, an­statt ei­ne um­fang­rei­che Kon­fi­gu­ra­ti­ons­da­tei um­zu­bau­en.

• Ab­hän­gig­keits­bäu­me stel­len si­cher, dass Sie nie ei­nen Task ver­ges­sen, der un­be­dingt vor ei­nem an­de­ren Schritt aus­ge­führt wer­den muss.

• Sie kön­nen sehr ein­fach le­sen, was Sie da ma­chen. Das In­ter­face ist für je­den Task und für je­des Tool das glei­che.

• Sie kön­nen dank No­de.js In­ter­face auch wie­der auf der Con­ti­nuous-De­li­very-Platt­form bau­en. Sie be­mer­ken al­ler­dings auch gleich die gro­ßen Nach­tei­le ei­ner sol­chen Lö­sung: • Al­le Tools, die ei­gent­lich schon exis­tie­ren, müs­sen in ein Plu­gin ver­packt wer­den. Aus­nah­me sind Pro­mi­se-ba­sier­te Tools (sie­he Tipp bzw. goo.gl/BQVs­bT).

• Da­mit schafft sich Gulp (und Gr­unt, Broc­co­li etc.) ein ei­ge­nes Öko­sys­tem. Sie hin­ken mit Ih­ren Plug­ins im­mer ei­ne Ver­si­on hin­ter­her, weil Sie das Werk­zeug nicht di­rekt ver­wen­den.

• Apro­pos ei­ge­nes Öko­sys­tem: Sämt­li­che Plug­ins ar­bei­ten mit ei­nem vir­tu­el­len Da­tei­sys­tem, das Gulp be­reit­stellt. Da­mit er­reicht Gulp zwar die Ge­schwin­dig­kei­ten, die un­ter an­de­ren Tools nicht er­reich­bar wä­ren, ist aber höchst in­kom­pa­ti­bel mit an­de­rer Soft­ware, die un­ter glei­chen Ge­sichts­punk­ten ar­bei­tet. Gulp Plug­ins kön­nen nur mit Gulp Plug­ins.

• Sie müs­sen doch sehr viel selbst schrei­ben. Fle­xi­bi­li­tät schön und gut, aber kein Schritt er­folgt oh­ne ei­ge­nen Co­de.

• Ab­hän­gig­kei­ten sind de­kla­ra­tiv, aber nicht se­man­tisch. Das be­deu­tet, dass Sie zwar Tasks mit­ein­an­der ver­ket­ten kön­nen, nicht aber er­ken­nen, ob je nach Da­tei­in­halt viel­leicht doch ei­ne an­de­re Auf­ga­be an­ge­brach­ter wä­re. Ein Bei­spiel: al­le Bil­der op­ti­mie­ren und kom­pri­mie­ren geht als Ab­hän­gig­keit von „html” recht ein­fach. Sie se­hen aber nicht, wel­che Bild­da­ten in Ih­rem HTML tat­säch­lich ver­wen­det wer­den.

Tipp: Bei Gulp be­nö­ti­gen Sie nicht zwin­gend Plug­ins, die be­ste­hen­de Funk­tio­nen Gulp-kom­pa­ti­bel ma­chen. Wel­che Tech­no­lo­gi­en sich mit Gulp ver­bin­den las­sen, fin­den Sie un­ter goo.gl/BQVs­bT.

Task Runner und die da­mit ver­bun­de­nen Bau­vor­schrif­ten eig­nen sich her­vor­ra­gend für Ent­wick­ler, de­ren Ap­pli­ka­tio­nen nach Typ ge­ord­net un­ab­hän­gig von­ein­an­der funk­tio­nie­ren. Web­site-Bau­er, die vor al­lem Tem­pla­tes lie­fern oder gar In­hal­te mit sta­ti­schen Sei­ten­ge­ne­ra­to­ren bau­en, wer­den mit Gulp und Kon­sor­ten ih­re hel­le Freu­de ha­ben. Leu­te, die haupt­säch­lich Ja­vaS­cript-Ap­pli­ka­tio­nen bau­en, brau­chen ein we­nig mehr.

BUNDLING TOOLS WIE WEB­PACK

Was für die Welt der Tem­pla­te­bau­er schön und rich­tig ist, ist für Ap­pli­ka­ti­ons­ent­wick­ler oft ein we­nig müh­sam. Das liegt vor al­lem an höchst un­ter­schied­li­chen An­wen­dungs­fäl­len. Ap­pli­ka­ti­ons­ent­wick­ler hal­ten sich heut­zu­ta­ge fast aus­schließ­lich in Ja­vaS­cript auf. Ge­ra­de auf­grund der ho­hen Po­pu­la­ri­tät, die Frame­works wie Re­act und Vue mit sich brin­gen, ver­las­sen Ent­wick­ler JS-Da­tei­en äu­ßerst sel­ten. Au­ßer­dem ha­ben sie Mark­up und oft auch Style-In­for­ma­tio­nen kompakt in ei­ner Da­tei. Kom­po­nen­ten sind das neue Ding, ei­ne tech­no­lo­gie­be­zo­ge­ne Tren­nung ist nur noch we­nig sinn­voll. Na­tür­lich gibt es für die­sen An­wen­dungs­fall auch ei­ne Än­de­rung in den Build Tools. Wenn sich die gan­ze Ent­wick­lungs­welt in ei­nem Ja­vaS­cript-Mo­dul be­wegt, so soll­te auch das Build Tool in die­ser Welt zu Hau­se sein. Hier sprin­gen Bundling Tools ein. Der Grund­ge­dan­ke ei­nes sol­chen Tools ist re­la­tiv ein­fach: Ir­gend­wo in Ih­rem Sour­ce Co­de be­fin­den sich An­wei­sun­gen, in de­nen Sie die In­hal­te ei­ner Ja­vaS­cript-Da­tei la­den und in ei­ner an­de­ren aus­füh­ren. So fin­det bei­spiels­wei­se das „re­qui­re”-State­ment, das wir aus No­de.js nur zu gut ken­nen, Ein­zug in die cli­ent­sei­ti­ge Ja­vaS­cript-An­wen­dung. mo­dul.js mo­du­le.ex­ports = func­tion(a) { re­turn a * a; } app.js var sqrt = re­qui­re('./mo­dul'); con­so­le.log(sqrt(2)); Da­mit weiß die Ap­pli­ka­ti­on selbst sehr gut, wel­che Da­tei­en nun be­nö­tigt wer­den und wel­che nicht. Die Auf­ga­be ei­nes Bundling Tools ist es nun, die­se „re­qui­re” State­ments (oder „im­ports” in der wei­te­ren Aus­bau­stu­fe) zu er­ken­nen und die In­hal­te in der glei­chen Da­tei an die­ser Stel­le ver­füg­bar zu ma­chen. Das Er­geb­nis soll ei­ne Da­tei sein, in der al­le Mo­du­le kompakt vor­han­den sind. Re­fe­ren­zen auf an­de­re Mo­du­le wer­den sau­ber auf­ge­löst, Sie stellt auch si­cher, in kei­ne zy­kli­schen Ab­hän­gig­kei­ten zu ge­ra­ten. Ei­nes der ers­ten Ver­tre­ter die­ser Bundling Tools war Brow­se­ri­fy [brow­se­ri­fy.org]. Ein Werk­zeug, das sehr gut in die Gulp-Welt in­te­griert war und für lan­ge Zeit den Ja­vaS­cript-Bundling-Vor­gang de­fi­niert hat. Brow­se­ri­fy er­laub­te es, die aus No­de.js be­kann­ten „re­qui­re”-State­ments nicht nur für ei­ge­ne Ap­pli­ka­tio­nen zu ver­wen­den, son­dern auch No­de.js-Mo­du­le er­folg­reich in Cli­ent-sei­ti­gen Ja­vaS­cript-Co­de ein­zu­bin­den. Brow­se­ri­fy war in der An­wen­dung zwar rich­tungs­wei­send, aber doch nicht ra­di­kal ge­nug, um ei­nen kom­plet­ten Per­spek­ti­ven­wech­sel in der Buil­dTool-Land­schaft zu be­wir­ken. Denn was wä­re, wenn Sie nicht nur Ja­vaS­cript über „re­qui­re”-State­ments la­den, son­dern je­de be­lie­bi­ge Da­tei mit je­der be­lie­bi­gen En­dung? Hier kommt Web­pack ins Spiel [web­pack.js.org]. Wie Ab­bil­dung 2 ver­an­schau­licht, er­laubt Web­pack das Re­fe­ren­zie­ren von un­ter­schied­li­chen Da­tei­en in un­ter­schied­li­chen Da­tei­ty­pen. Ein Bild, dass per IMG-Ele­ment in ei­nem Hand­le­bar­sTem­pla­te re­fe­ren­ziert wird, gilt hier ge­nau­so wie ei­ne SASS-Da­tei, auf die Sie per „re­qui­re” im Ja­vaS­cript ver­wei­sen. Web­pack löst die­se Re­fe­ren­zen auf, er­kennt die Ein­gangs­da­tei­for­ma­te und de­ren Ziel­for­mat und er­zeugt für je­des die­ser Ziel­for­ma­te (CSS, JS) ein Bün­del. Bil­der wer­den op­ti­miert, und nur die Da­tei­en, die Sie auch tat­säch­lich brau­chen, wer­den in das Aus­ga­be­ver­zeich­nis ge­spei­chert. Ein­sprungs­punkt da­für ist die ei­ne Ja­vaS­cript-Da­tei, die Sie als Haupt­da­tei im Kom­pi­lie­rungs­vor­gang an­ge­ben. Die­se Fle­xi­bi­li­tät er­hält Web­pack durch so­ge­nann­te Loa­der. Die­se Loa­der wis­sen, wie sie ge­wis­se Da­ten­ty­pen la­den sol­len, was für Aus­ga­be­ty­pen man von ih­nen ver­langt und wel­ches Werk­zeug zum Transpi­lat not­wen­dig ist. Loa­der kön­nen auch ver­ket­tet wer­den: Ein Sass Loa­der sorgt da­für, dass SASS-Da­tei­en nach CSS über­setzt wer­den. Ein CSS Loa­der sorgt da­für, dass die­se CSSDa­tei­en auch im Ja­vaS­cript re­fe­ren­ziert wer­den kön­nen. Die Aus­gangs­soft­ware kommt oh­ne Stell­schrau­ben schon recht gut vor­an: Wol­len Sie Ja­vaS­cript bün­deln, braucht Web­pack nur ei­ne Aus­gangs- und ei­ne Ziel­da­tei. Den Rest er­le­digt der vor­ge­fer­tig­te Mecha­nis­mus. Wol­len Sie al­ler­dings mit Loa­dern und un­ter­schied­li­chen Da­tei­ty­pen ar­bei­ten, ist ei­ne Kon­fi­gu­ra­ti­ons­da­tei un­um­gäng­lich. Das fol­gen­de Lis­ting zeigt, wie Sie ei­nen Sass-Loa­der in ei­ner Web­pack-Kon­fi­gu­ra­ti­ons­da­tei kon­fi­gu­rie­ren. web­pack.con­fig.js mo­du­le.ex­ports = { ... mo­du­le: { ru­les: [{ test: /\.scss$/, use: [{ loa­der: "style-loa­der" // crea­tes style nodes from JS strings

Web­pack kommt ab Ver­si­on 4 mit weit we­ni­ger Kon­fi­gu­ra­ti­ons­auf­wand aus. Vie­le Stan­dar­d­op­tio­nen ha­ben sich dort in Kom­man­do­zei­len­pa­ra­me­tern ver­steckt.

}, { loa­der: "css-loa­der" // trans­la­tes CSS in­to Com­monJS }, { loa­der: "sass-loa­der" // com­pi­les Sass to CSS }] }] };} Das ist ge­hö­rig viel Auf­wand, zahlt sich aber aus. Am En­de kön­nen Sie näm­lich in Ih­rer Kom­po­nen­te so et­was auf­füh­ren: Com­po­nent.js const sty­les = re­qui­re('./fi­le.scss'); con­so­le.log(sty­les.clas­sNa­me); Wo­bei „clas­sNa­me” ei­nem von Ih­nen de­fi­nier­ten Klas­sen­na­men ent­spricht. Pa­ra­dig­men­wech­sel, ja. Aber ei­ner, der sich in der Welt von kom­po­nen­ten­ori­en­tier­tem Ja­vaS­cript aus­zahlt. An­ders als die Kol­le­gen von Gulp, Gr­unt & Co. hat Web­pack nicht den Feh­ler be­gan­gen, Wrap­per um ei­gent­li­che Funk­tio­na­li­tät zu stri­cken, son­dern ver­lässt sich auf APIs. Das un­ter dem Sass-Loa­der zu­gäng­li­che Sass mit No­de.js Bin­ding ist näm­lich kei­ne Ab­hän­gig­keit des Loa­ders, son­dern muss se­pa­rat in­stal­liert wer­den. So kön­nen Sie Up­dates so­fort ge­nie­ßen, oh­ne auf die ent­spre­chen­de Ak­tua­li­sie­rung beim Loa­der zu war­ten. Kon­fi­gu­ra­ti­ons­da­tei­en er­öff­nen Ih­nen aber nicht nur den Weg zu Loa­dern, son­dern auch zu ei­ni­gen an­de­ren in­ter­es­san­ten Fea­tu­res. Hier ein Über­blick: Web­pack Dev Ser­ver: Web­pack be­sitzt ei­nen in­te­grier­ten Ent­wick­lungs-Ser­ver. Der Ser­ver öff­net ei­nen Port auf lo­cal­host, kann die kom­pi­lier­ten Da­tei­en aus­füh­ren, be­kommt Sour­ce­maps und in­kre­men­tel­le Builds. Durch den so­ge­nann­ten Hot-Re­loa­ding-Mecha­nis­mus er­kennt Web­pack auch, wel­che Tei­le ei­nes Bün­dels sich ge­än­dert ha­ben, und tauscht die­se um­ge­hend aus – und das oh­ne den Ap­pli­ka­ti­ons­sta­tus zu ver­lie­ren. Im­port-Funk­ti­on: Da ein gro­ßes Ja­vaS­cript-Bün­del nicht un­be­dingt zu Per­for­mance-Ge­win­nen bei­trägt, hat Web­pack sich ent­schlos­sen, die Brow­ser-na­ti­ve „im­port”-Funk­ti­on als Po­ly­fill zu im­ple­men­tie­ren. Mit der „im­port”-Funk­ti­on kön­nen Sie an­de­re Ja­vaS­cript-Mo­du­le dy­na­misch nach­la­den. „im­port” gibt da­bei ei­ne Pro­mi­se zu­rück. Das zu er­war­ten­de Er­geb­nis ent­hält das ex­por­tier­te Mo­dul. Da­mit be­treibt Web­pack Co­de-Split­ting auf die na­tivs­te Mög­lich­keit: zu­kunfts­si­che­rer Co­de und op­ti­mier­tes­te Er­geb­nis­se. Pro­duc­tion-Mo­dus: Web­pack ver­fügt über ei­nen Pro­duc­tionMo­dus. Da­mit wer­den Op­ti­mie­run­gen ge­trof­fen, die der Per­for­mance in fer­ti­gen Bün­deln gut­tun. Co­de wird mi­ni­fi­ziert, Sour­ce­maps wer­den nicht ge­ne­riert. Web As­sem­bly: Nach­dem die An­zahl an Prä­pro­zes­so­ren ja of­fen­sicht­lich noch nicht ge­nug ist, er­laubt Web­pack bald den Im­port von na­tiv ge­schrie­be­nen Pro­gram­men in Rust und C++. Da ist na­tür­lich nicht Voo­doo und Ma­gie drin, son­dern ein For­schungs­pro­jekt mit der Un­ter­stüt­zung von Mo­zil­la. Web­pack soll näm­lich das Ein­fü­gen von Web-As­sem­bly-Pro­jek­ten ein­fach und zu­gäng­lich ma­chen. Mul­ti-Pa­ge-Ap­pli­ka­tio­nen: Web­pack geht im Re­gel­fall von ei­ner Ja­vaS­cript-Da­tei als Start­mo­dul aus, wie bei Sing­le-Pa­ge-Ap­pli­ka­tio­nen üb­lich. Oft be­nö­ti­gen Sie aber meh­re­re Start­punk­te, wie es bei ge­wöhn­li­chen Web­sites mit meh­re­ren HTML- bzw. Ja­vaS­cript-Da­tei­en der Fall ist. Die Web­pack-Kon­fi­gu­ra­ti­on er­laubt, meh­re­re Start­mo­du­le an­zu­ge­ben und mit dem glei­chen Re­gel­werk an Loa­dern zu über­set­zen. So­mit funk­tio­niert Web­pack auch au­ßer­halb des SPA-Uni­ver­sums ganz präch­tig. Das klingt na­tür­lich nach ei­ner gan­zen Men­ge Fea­tu­res, die Sie in un­ter­schied­li­cher Band­brei­te brau­chen kön­nen. In den meis­ten Fäl­len kom­men Sie mit ei­nem Ba­sis­set aus. Die ver­schie­den ver­schach­tel­ten Loa­der sind zwar mäch­tig, kön­nen aber in der Kon­fi­gu­ra­ti­on sehr un­durch­sich­tig sein. Hier soll­ten Sie sich auf fer­ti­ge Pa­ke­te ver­las­sen, die Ih­nen Boi­ler­pla­tes und Star­ter­kit im Web an­bie­ten. Wer zum Bei­spiel mit dem Vue.js-Frame­work un­ter­wegs ist, hat mit den Web­pack-Kon­fi­gu­ra­tio­nen des Her­stel­lers al­les, was er be­nö­tigt. Web­pack ist al­so op­ti­mal für Leu­te, die viel Zeit in Ja­vaS­cript ver­brin­gen und trotz­dem nicht auf an­de­re Werk­zeu­ge ver­zich­ten wol­len. Al­ter­na­ti­ven wie Brow­se­ri­fy, Rol­lup und Par­cel sind ähn­lich im Fea­tu­re­set, aber nicht an­nä­hernd so po­pu­lär. Je nach An­wen­dungs­fall kön­nen Sie ei­nen nä­he­ren Blick dar­auf wer­fen. Rol­lup ist zum Bei­spiel un­ter Bi­b­lio­theks­her­stel­lern sehr be­liebt, weil die Mo­du­le di­rekt auf­ge­löst wer­den und durch Fea­tu­res wie Tree-Sha­king die Bün­del­grö­ßen viel klei­ner sind [rol­lup­js.org].

NACH­HAL­TIG­KEIT

Bei der Viel­zahl an Werk­zeu­gen und Plug­ins fragt man sich na­tür­lich, wie lang­le­big sol­che Pro­jek­te sind. Tat­säch­lich ist es so­gar so, dass sich die Werk­zeu­ge oft das Staf­fel­holz rei­chen und ganz schnell un­po­pu­lär wer­den. Win­dows-Nut­zer schiel­ten da­mals nei­disch auf die Mac-Be­sit­zer, weil die­se mit dem Co­de­Kit viel pro­duk­ti­ver und ef­fi­zi­en­ter op­ti­mier­te As­sets er­zeu­gen konn­ten. So lan­ge bis Co­de­Kit von dem fle­xi­ble­ren und Platt­form-un­ab­hän­gi­gen Gr­unt ab­ge­löst wur­de. Gr­unt war für vie­le Front­en­dEnt­wick­ler der Zu­gang zu No­de.js und rief Gulp auf den Plan, das viel knap­per und le­ser­li­cher wirk­te. Wo Gulp sich mit kom­ple­xen Plug­ins und ty­pen­ab­hän­gi­gen Pi­pe­lines den Weg ver­baut hat,

kam ein Web­pack, das Da­tei­en wie­der in Kon­text brach­te. Je­des Pro­jekt, das ein an­de­res ab­lös­te, wur­de zwar wei­ter­ent­wi­ckelt, al­ler­dings auf Spar­flam­me. Auf ei­ne Ver­si­on 4 von Gulp war­te­te man bei­spiels­wei­se meh­re­re Jah­re. Da­zu sei ge­sagt, dass Tools wie Gulp, die nur ei­ne dün­ne Hül­le über an­de­re No­de.js-Mo­du­le stri­cken und haupt­säch­lich auf Plug­ins auf­bau­en, schon so gut wie fer­tig sind. Neue Fea­tu­res brau­chen Sie nicht, Bug­fi­xes wer­den schlep­pend, aber doch von ei­ner Grup­pe Frei­wil­li­ger ge­war­tet. Da­mit Web­pack nicht in ein ähn­li­ches Pro­blem läuft und bald vom nächs­ten gro­ßen Hit ab­ge­löst wird, hat sich die Grup­pe nach­hal­tig auf­ge­stellt. Mit ei­nem Ein­trag auf OpenCollec­tive hat sich ei­ne Grup­pe ge­fun­den, die Web­pack fi­nan­zi­ell un­ter­stützt und so si­cher­stellt, dass das Kern­team sich auch wirk­lich um die Wei­ter­ent­wick­lung des Werk­zeugs küm­mern kann [opencollec­tive.com/web­pack]. Die Un­ter­stüt­zer rei­chen da­bei von mit­tel­gro­ßen und gro­ßen Fir­men bis hin zu Pri­vat­per­so­nen. Das funk­tio­niert bis­lang sehr gut.

KON­TI­NU­IER­LI­CHE IN­TE­GRA­TI­ON

Nicht nur in De­vOps-Krei­sen gilt: Nur wenn es auf Pro­duc­tion Ser­vern läuft, ist es fer­tig. Da­mit Ih­re Builds und Build Tools nicht nur auf Ih­ren lo­ka­len Ma­schi­nen funk­tio­nie­ren, gibt es et­li­che Ser­vices, die sich auf kon­ti­nu­ier­li­che In­te­gra­ti­on, eng­lisch Con­ti­nuous

In­te­gra­ti­on bzw. Con­ti­nuous De­ploy­ment, spe­zia­li­siert ha­ben. Mi­cro­softs Team Foundation Ser­ver [vi­su­al­stu­dio.com/de/tfs], Tra­vis [tra­vis-ci.org] und Co­deship [co­deship.com] ver­fü­gen über ganz brauch­ba­re, kos­ten­lo­se Ta­ri­fe. Mit sol­chen Ser­vices ist es mög­lich, die sorg­fäl­tig er­stell­ten Builds nun auch von ei­ner Ma­schi­ne aus­füh­ren zu las­sen – als letz­te In­stanz vor ei­nem mög­li­chen De­ploy­ment. Nur wenn am Build-Ser­ver al­le Tests po­si­tiv aus­ge­führt wer­den und die Build-Ar­te­fak­te kor­rekt er­stellt wer­den kön­nen, ist es er­laubt, die neu­en Da­ten auch auf den Pro­duc­tion-Ser­ver zu über­tra­gen. Die­ser Trans­fer von Build-Ar­te­fak­ten wird auch über den Build-Ser­ver aus­ge­führt. Wir re­den al­so von meh­re­ren Stu­fen: Tes­ten, Kom­pi­lie­ren, Hoch­la­den. Klas­si­scher­wei­se or­ga­ni­sie­ren Sie die­se Pha­sen in ei­ner Build-Pi­pe­line. Das be­deu­tet, dass kei­ne Stu­fe star­ten darf, be­vor nicht die vor­her­ge­hen­de er­folg­reich be­en­det wird. Als wei­te­re Si­cher­heits­stu­fe la­den Sie das fer­ti­ge Kom­pi­lat noch auf ei­nen Sta­ging Ser­ver, wo Sie sich in Ru­he selbst vom Er­geb­nis über­zeu­gen kön­nen. Die­se Cloud Ser­vices nut­zen ent­we­der vor­ge­fer­tig­te Schnitt­stel­len – wie „npm run build” bei Tra­vis’ No­de.js-Ap­pli­ka­tio­nen – oder er­lau­ben kom­plet­te Frei­heit wie bei Co­deship. Sämt­li­che Tools sind al­ler­dings sehr stark mit Git oder GitHub ver­bun­den. Bei ei­nem neu­en Com­mit auf ei­nen be­stimm­ten Branch wird die­ser aus­ge­checkt und ei­ne Rei­he an Pro­zes­sen aus­ge­führt. Je nach er­folg­rei­chem Sta­tus­code wird zum Bei­spiel ein Pull Re­quest als va­li­de oder nicht va­li­de mar­kiert. Da­mit stel­len Sie si­cher, dass neue Fea­tu­res auch tat­säch­lich funk­tio­nie­ren, und rui­nie­ren sich nicht Ih­ren Pro­duk­ti­ons-Co­de. Werk­zeu­ge wie Net­li­fy den­ken den Pro­zess von An­fang bis En­de durch [net­li­fy.com]. Net­li­fy lie­fert nicht nur Mög­lich­kei­ten zur Con­ti­nuous In­te­gra­ti­on, es wer­den auch gleich Sta­ging und Pro­duc­tion Ser­ver für das De­ploy­ment zur Ver­fü­gung ge­stellt. Net­li­fys kos­ten­lo­ser Ta­rif ist er­staun­lich mäch­tig und soll­te für Durch­schnitts­pro­jek­te aus­rei­chen.

FA­ZIT

Die An­sprü­che, die Ent­wick­ler an Web­sites ha­ben, sind heu­te hö­her denn je. We­ge, wie Sie Co­de für Web­tech­no­lo­gi­en schrei­ben, än­dern sich fort­lau­fend und ra­sant. Gut al­so, wenn Sie das „hea­vy lif­ting” Ih­rer Ar­beit au­to­ma­ti­sier­ten Pro­zes­sen über­las­sen kön­nen. Bei all der Lie­be zur Au­to­ma­ti­sie­rung soll­ten Sie al­ler­dings nicht ver­ges­sen, dass Sie auch noch tat­säch­li­chen Ap­pli­ka­ti­ons­code schrei­ben. Nicht sel­ten ha­ben sich Ent­wick­ler so sehr in den Wei­ten der Build-Kon­fi­gu­ra­tio­nen ver­lo­ren, dass das ge­wünsch­te Fea­tu­re zwar her­aus­ra­gend au­to­ma­ti­siert ge­lie­fert wur­de, der Auf­wand da­zu aber ei­nem Viel­fa­chen der ei­gent­li­chen Auf­ga­ben­stel­lung ent­sprach.

Abb. 1: Co­de­Kit bie­tet ein in­tui­ti­ves In­ter­face, um die meis­ten Auf­ga­ben per Drag-and-Drop und mit ein paar Klicks zu er­le­di­gen.

Abb. 2: Der Web­pack-Vor­gang auf der Web­sei­te kurz er­klärt: Je­des Fi­le hat Ab­hän­gig­kei­ten, un­ab­hän­gig vom Da­tei­typ. Web­pack er­kennt sie al­le.

Abb. 4: No­de und NPM sind nur ei­ne der Tech­no­lo­gi­en, die von Co­deship un­ter­stützt wer­den. Hier nut­zen wir Stan­dardhooks wie npm run build und npm pu­blish, um un­se­re Web­sei­te zu de­ploy­en.

Abb. 3: Co­deship gibt gut Auf­schluss über den Zu­stand ein­zel­ner Builds. Je Com­mit in den Git Mas­ter Branch wird ein Build ge­trig­gert.

Ste­fan Baum­gart­ner lei­tet das Web Ex­pe­ri­ence und De­sign Ops Team bei Dy­na­tra­ce in Linz, Ös­ter­reich [dy­na­tra­ce.de]. In sei­ner Frei­zeit or­ga­ni­siert er Scrip­tConf, De­vo­ne und das Lin­zer Tech­no­lo­gie­plau­scherl. Mit sei­nen Kol­le­gen vom Wor­king Draft Pod­cast spricht Ste­fan wö­chent­lich über ak­tu­el­le Web-The­men. Twit­ter: @dd­prrt Kom­men­tie­ren: screen­gui.de/39/build-tools

Newspapers in German

Newspapers from Germany

© PressReader. All rights reserved.