{"id":87467,"date":"2020-07-08T13:42:11","date_gmt":"2020-07-08T11:42:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn"},"modified":"2020-07-08T13:42:11","modified_gmt":"2020-07-08T11:42:11","slug":"rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","title":{"rendered":"Guide f\u00f6r nyb\u00f6rjare: Skapa en DevOps-pipeline","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Om du \u00e4r ny inom DevOps, ta en titt p\u00e5 denna guide f\u00f6r att skapa din f\u00f6rsta pipeline i fem steg.<\/i><\/p>\n

\"Guide<\/p>\n

DevOps har blivit den standardl\u00f6sning som \u00e5tg\u00e4rdar l\u00e5ngsamma, isolerade eller defekta mjukvaruutvecklingsprocesser. Problemet \u00e4r att om du \u00e4r ny inom DevOps och inte vet var du ska b\u00f6rja kan det saknas en f\u00f6rst\u00e5else f\u00f6r dessa metoder. I denna artikel kommer vi att definiera en DevOps-pipeline samt ge en guide f\u00f6r hur man skapar en i fem steg. \u00c4ven om denna handledning inte \u00e4r utt\u00f6mmande, b\u00f6r den ge dig en grund f\u00f6r att b\u00f6rja din resa och f\u00f6r att ut\u00f6ka dina kunskaper i framtiden. Men f\u00f6rst, l\u00e5t oss b\u00f6rja med historien.<\/p>\n

Min resa inom DevOps<\/h3>\n

\nTidigare arbetade jag i cloud-teamet p\u00e5 Citi Group, d\u00e4r jag utvecklade en Infrastructure-as-a-Service (IaaS) webbapplikation f\u00f6r att hantera Citis molninfrastruktur, men jag har alltid varit intresserad av hur man kan effektivisera utvecklingsprocessen och f\u00f6ra in positiva kulturella f\u00f6r\u00e4ndringar i utvecklarteamet. Svaret fann jag i en bok rekommenderad av Greg Lavender, teknisk direkt\u00f6r f\u00f6r Citis molnarkitektur och infrastruktur. Boken hette \"The Phoenix Project\" (The Phoenix Project<\/a><\/noindex>), och den f\u00f6rklarar principerna f\u00f6r DevOps, samtidigt som den l\u00e4ses som en roman.<\/p>\n

I tabellen p\u00e5 baksidan av boken visas hur ofta olika f\u00f6retag distribuerar sina system i en release-milj\u00f6:<\/p>\n

Amazon: 23 000 per dag
\nGoogle: 5 500 per dag
\nNetflix: 500 per dag
\nFacebook: En g\u00e5ng per dag
\nTwitter: Tre g\u00e5nger i veckan
\nTypiskt f\u00f6retag: En g\u00e5ng var nio m\u00e5nad<\/p>\n

Hur \u00e4r det ens m\u00f6jligt f\u00f6r Amazon, Google och Netflix att ha s\u00e5dana frekvenser? Det beror p\u00e5 att dessa f\u00f6retag har kommit p\u00e5 hur man kan skapa en n\u00e4stan perfekt DevOps-pipeline.
\n<\/a><\/noindex>
\nVi var l\u00e5ngt ifr\u00e5n detta tills vi implementerade DevOps p\u00e5 Citi. D\u00e5 hade mitt team olika milj\u00f6er, men distributionen p\u00e5 utvecklingsservern var helt manuell. Alla utvecklare hade endast tillg\u00e5ng till en utvecklingsserver baserad p\u00e5 IBM WebSphere Application Server Community Edition. Problemet var att servern st\u00e4ngdes av varje g\u00e5ng flera anv\u00e4ndare f\u00f6rs\u00f6kte distribuera samtidigt, s\u00e5 utvecklarna var tvungna att meddela varandra om sina avsikter, vilket var ganska sm\u00e4rtsamt. Dessutom fanns det problem med l\u00e5g testt\u00e4ckning av koden, besv\u00e4rliga processer f\u00f6r manuell distribution och bristen p\u00e5 m\u00f6jlighet att sp\u00e5ra koddistribution kopplad till en specifik uppgift eller anv\u00e4ndarhistoria.<\/p>\n

Jag ins\u00e5g att n\u00e5got beh\u00f6vde g\u00f6ras och hittade en kollega som t\u00e4nkte som jag. Vi beslutade att samarbeta f\u00f6r att skapa den ursprungliga DevOps-pipelinen - han installerade en virtuell maskin och en Tomcat-applikationsserver medan jag arbetade med Jenkins, integrerade Atlassian Jira och BitBucket, samt arbetade med testt\u00e4ckning av koden. Det h\u00e4r sidoprojektet var mycket framg\u00e5ngsrikt: vi automatiserade n\u00e4stan helt m\u00e5nga processer, n\u00e5dde n\u00e4ra 100 % tillf\u00f6rlitlighet p\u00e5 v\u00e5r utvecklingsserver, s\u00e4kerst\u00e4llde sp\u00e5rbarhet och f\u00f6rb\u00e4ttrade testt\u00e4ckningen av koden, samt lade till m\u00f6jligheten att koppla grenar i Git med uppgifter i Jira eller distribution. De flesta verktyg som vi anv\u00e4nde f\u00f6r att bygga v\u00e5r DevOps-pipeline hade \u00f6ppen k\u00e4llkod.<\/p>\n

Nu f\u00f6rst\u00e5r jag hur enkel v\u00e5r DevOps-pipeline var: vi anv\u00e4nde inte till\u00e4gg som Jenkins-filer eller Ansible. Denna enkla pipeline fungerade dock bra, kanske tack vare Paretoprincipen (\u00e4ven k\u00e4nd som 80\/20-regeln).<\/p>\n

En kort introduktion till DevOps och CI\/CD-pipelines<\/h3>\n

\nOm du fr\u00e5gar flera personer: \"Vad \u00e4r DevOps?\", f\u00e5r du f\u00f6rmodligen flera olika svar. DevOps, precis som Agile, har utvecklats f\u00f6r att omfatta m\u00e5nga olika discipliner, men de flesta h\u00e5ller med om n\u00e5gra saker: DevOps \u00e4r en programvaruutvecklingspraxis eller livscykel f\u00f6r programvaruutveckling (SDLC), d\u00e4r en central princip \u00e4r att f\u00f6r\u00e4ndra kulturen d\u00e4r utvecklare och icke-utvecklare existerar i en milj\u00f6 d\u00e4r:<\/p>\n

Operationer som tidigare utf\u00f6rdes manuellt \u00e4r automatiserade;
\nAlla g\u00f6r det de \u00e4r b\u00e4st p\u00e5;
\nAntalet implementeringar under en viss tidsperiod \u00f6kar; Genomstr\u00f6mningen \u00f6kar;
\nUtvecklingsflexibiliteten \u00f6kar.<\/p>\n

\u00c4ven om r\u00e4tt programvaruverktyg inte \u00e4r det enda som kr\u00e4vs f\u00f6r att skapa en DevOps-milj\u00f6, \u00e4r vissa verktyg n\u00f6dv\u00e4ndiga. Ett nyckelverktyg \u00e4r kontinuerlig integration och kontinuerlig distribution (CI\/CD). I denna pipeline har milj\u00f6erna olika faser (t.ex. DEV, INT, TST, QA, UAT, STG, PROD), m\u00e5nga operationer \u00e4r automatiserade, och utvecklare kan skriva h\u00f6gkvalitativ kod, uppn\u00e5 utvecklingsflexibilitet och h\u00f6g distributionsfrekvens.<\/p>\n

I den h\u00e4r artikeln beskrivs en femstegsmetod f\u00f6r att skapa en DevOps-pipeline liknande den som visas i f\u00f6ljande diagram, med anv\u00e4ndning av verktyg med \u00f6ppen k\u00e4llkod.<\/p>\n

Steg 1: CI\/CD-metoder<\/h3>\n

\nDet f\u00f6rsta du beh\u00f6ver \u00e4r ett verktyg f\u00f6r CI\/CD. Jenkins, ett verktyg med \u00f6ppen k\u00e4llkod baserat p\u00e5 Java och distribuerat under MIT-licensen, \u00e4r det verktyg som har populariserat DevOps-riktningen och blivit de facto-standard.<\/p>\n

Vad \u00e4r d\u00e5 Jenkins? T\u00e4nk p\u00e5 det som en slags magisk universalfj\u00e4rrkontroll som kan kommunicera med olika tj\u00e4nster och verktyg och organisera dem. Sj\u00e4lva CI\/CD-verktyget, som Jenkins, \u00e4r v\u00e4rdel\u00f6st, men det blir mer kraftfullt n\u00e4r det kopplas till olika verktyg och tj\u00e4nster.<\/p>\n

Jenkins \u00e4r bara ett av m\u00e5nga verktyg med \u00f6ppen k\u00e4llkod f\u00f6r CI\/CD som du kan anv\u00e4nda f\u00f6r att bygga DevOps-pipelines.<\/p>\n

Jenkins: Creative Commons och MIT
\nTravis CI: MIT
\nCruiseControl: BSD
\nBuildbot: GPL
\nApache Gump: Apache 2.0
\nCabie: GNU<\/p>\n

S\u00e5 h\u00e4r ser DevOps-processerna ut med CI\/CD-verktyget:<\/p>\n

\"Guide<\/p>\n

Du har ett CI\/CD-verktyg som k\u00f6rs p\u00e5 din lokala v\u00e4rd, men just nu kan du g\u00f6ra lite eller inget. L\u00e5t oss g\u00e5 vidare till n\u00e4sta steg i resan in i DevOps-v\u00e4rlden.<\/p>\n

Steg 2: Hantering av versionskontrollsystem<\/h3>\n

\nDet b\u00e4sta (och kanske enklaste) s\u00e4ttet att kontrollera att ditt CI\/CD-verktyg kan g\u00f6ra magi \u00e4r att integrera det med ett versionskontrollsystem (VCS). Varf\u00f6r beh\u00f6ver du kontroll \u00f6ver k\u00e4llkoden? Anta att du utvecklar en applikation. Varje g\u00e5ng du bygger en applikation skriver du kod, oavsett om du anv\u00e4nder Java, Python, C++, Go, Ruby, JavaScript eller n\u00e5gon av de miljontals programmeringsspr\u00e5ken. Koden du skriver kallas k\u00e4llkod. I b\u00f6rjan, s\u00e4rskilt n\u00e4r du arbetar ensam, \u00e4r det f\u00f6rmodligen okej att lagra allt i en lokal katalog. Men n\u00e4r projektet v\u00e4xer och du bjuder in andra att samarbeta, beh\u00f6ver du ett s\u00e4tt att f\u00f6rhindra konflikter vid effektiv delning av modifieringar. Du beh\u00f6ver ocks\u00e5 ett s\u00e4tt att \u00e5terst\u00e4lla tidigare versioner, eftersom att g\u00f6ra backuper och kopiera\/klistra in dem redan \u00e4r f\u00f6r\u00e5ldrat. Du (och dina teamkamrater) beh\u00f6ver n\u00e5got b\u00e4ttre.<\/p>\n

H\u00e4r blir ett versionskontrollsystem n\u00e4stan en n\u00f6dv\u00e4ndighet. Detta verktyg lagrar din kod i repositorier, h\u00e5ller reda p\u00e5 versioner och koordinerar arbetet mellan projektets deltagare.<\/p>\n

\u00c4ven om det finns m\u00e5nga versionskontrollsystem \u00e4r Git standarden, och det \u00e4r sant. Jag rekommenderar starkt att anv\u00e4nda Git, \u00e4ven om det finns andra alternativ som \u00e4r \u00f6ppen k\u00e4llkod.<\/p>\n

Git: GPLv2 och LGPL v2.1
\nSubversion: Apache 2.0
\nConcurrent Versions System (CVS): GNU
\nVesta: LGPL
\nMercurial: GNU GPL v2+<\/p>\n

S\u00e5 h\u00e4r ser DevOps-pipelinen ut med till\u00e4gg av versionskontrollsystem.<\/p>\n

\"Guide<\/p>\n

CI\/CD-verktyget kan automatisera processerna f\u00f6r testning, h\u00e4mtning av k\u00e4llkod och samarbetet mellan medlemmar. Inte illa? Men hur omvandlar man detta till en fungerande applikation som miljarder m\u00e4nniskor kan anv\u00e4nda och v\u00e4rdera?<\/p>\n

Steg 3: Skapa automatiseringsverktyget f\u00f6r byggprocessen<\/h3>\n

\nBra! Du kan kontrollera koden och g\u00f6ra \u00e4ndringar i versionshanteringssystemet, samt bjuda in dina v\u00e4nner att samarbeta i utvecklingen. Men du har \u00e4nnu inte skapat en applikation. F\u00f6r att skapa ett webbprogram m\u00e5ste det kompileras och paketeras i ett distribuerbart format eller k\u00f6ras som en k\u00f6rbar fil. (Observera att tolkade programmeringsspr\u00e5k som JavaScript eller PHP inte beh\u00f6ver kompileras).<\/p>\n

Anv\u00e4nd automatiseringsverktyget f\u00f6r byggande. Oavsett vilket automatiseringsverktyg f\u00f6r byggande du v\u00e4ljer att anv\u00e4nda, syftar de alla mot samma m\u00e5l: att sammanst\u00e4lla koden till ett \u00f6nskat format och automatisera uppgifter som st\u00e4dning, kompilering, testning och distribution i en viss milj\u00f6. Byggverktyg kan variera beroende p\u00e5 ditt programmeringsspr\u00e5k, men h\u00e4r \u00e4r n\u00e5gra vanliga open source-alternativ.<\/p>\n

Namn
\nLicens
\nProgrammeringsspr\u00e5k<\/p>\n

Maven
\nApache 2.0
\n Java<\/p>\n

Ant
\nApache 2.0
\nJava<\/p>\n

Gradle
\nApache 2.0
\nJava<\/p>\n

Bazel
\nApache 2.0
\nJava<\/p>\n

Make
\n(Gnu\u2019s Not Unix), som syftar till att utveckla systemkomponenter f\u00f6r att skapa ett fritt alternativ till Unix, vilket g\u00f6r det m\u00f6jligt att helt undvika propriet\u00e4r programvara. Under GNU:s skydd har det skapats en gemenskap av fria projekt, som r\u00f6r sig mot ett gemensamt m\u00e5l och utvecklas i enlighet med en enad ideologi och filosofi. Initialt var de centrala delarna av projektet
\nN\/A<\/p>\n

Grunt
\nMIT
\nJavaScript<\/p>\n

Gulp
\nMIT
\nJavaScript<\/p>\n

Buildr
\nApache
\nRuby<\/p>\n

Rake
\nMIT
\nRuby<\/p>\n

A-A-P
\n(Gnu\u2019s Not Unix), som syftar till att utveckla systemkomponenter f\u00f6r att skapa ett fritt alternativ till Unix, vilket g\u00f6r det m\u00f6jligt att helt undvika propriet\u00e4r programvara. Under GNU:s skydd har det skapats en gemenskap av fria projekt, som r\u00f6r sig mot ett gemensamt m\u00e5l och utvecklas i enlighet med en enad ideologi och filosofi. Initialt var de centrala delarna av projektet
\nPython<\/p>\n

SCons
\nMIT
\nPython<\/p>\n

BitBake
\nGPLv2
\nPython<\/p>\n

Cake
\nMIT
\nC#<\/p>\n

ASDF
\nExpat (MIT)
\nLISP<\/p>\n

Cabal
\nBSD
\nHaskell<\/p>\n

Bra! Du kan placera konfigurationsfilerna f\u00f6r automatiseringsverktyget i versionshanteringssystemet och l\u00e5ta ditt CI\/CD-verktyg s\u00e4tta ihop allt.<\/p>\n

\"Guide<\/p>\n

Allt ser bra ut, eller hur? Men var ska du distribuera din applikation?<\/p>\n

Steg 4: Server f\u00f6r webbapplikationer<\/h3>\n

\nS\u00e5 l\u00e5ngt har du en paketerad fil som kan vara antingen k\u00f6rbar eller installerbar. F\u00f6r att en applikation ska vara verkligt nyttig m\u00e5ste den erbjuda n\u00e5gon form av tj\u00e4nst eller gr\u00e4nssnitt, och du beh\u00f6ver en beh\u00e5llare f\u00f6r att hysa din applikation.<\/p>\n

En server f\u00f6r webbapplikationer \u00e4r just en s\u00e5dan beh\u00e5llare. Servern tillhandah\u00e5ller en milj\u00f6 d\u00e4r logiken f\u00f6r den distribuerade paketet kan definieras. Den erbjuder ocks\u00e5 ett gr\u00e4nssnitt och webb tj\u00e4nster, vilket \u00f6ppnar upp f\u00f6r externa kontakter. Du beh\u00f6ver en HTTP-server och ocks\u00e5 en viss milj\u00f6 (till exempel en virtuell maskin) f\u00f6r att installera den. Och f\u00f6r nu, l\u00e5t oss anta att du f\u00e5r veta mer om det senare (\u00e4ven om jag kommer att ber\u00e4tta om containrar nedan).<\/p>\n

Det finns flera open source-servrar f\u00f6r webbapplikationer.<\/p>\n

Namn
\nLicens
\nProgrammeringsspr\u00e5k<\/p>\n

Tomcat
\nApache 2.0
\nJava<\/p>\n

Jetty
\nApache 2.0
\nJava<\/p>\n

WildFly
\nGNU Lesser Public
\nJava<\/p>\n

GlassFish
\nCDDL & GNU Less Public
\nJava<\/p>\n

Django
\n3-Clause BSD
\nPython<\/p>\n

Tornado
\nApache 2.0
\nPython<\/p>\n

Gunicorn
\nMIT
\nPython<\/p>\n

Python
\nMIT
\nPython<\/p>\n

Rails
\nMIT
\nRuby<\/p>\n

Node.js
\nMIT
\nJavascript<\/p>\n

Din DevOps-pipeline \u00e4r n\u00e4stan klar att anv\u00e4nda. Bra jobbat!<\/p>\n

\"Guide<\/p>\n

\u00c4ven om man kan stanna h\u00e4r och integrera sj\u00e4lv, \u00e4r kodens kvalitet en viktig aspekt f\u00f6r applikationsutvecklare, och detta beh\u00f6ver uppm\u00e4rksammas.<\/p>\n

Steg 5: T\u00e4ckning av kodtestning<\/h3>\n

\nImplementering av tester kan vara ett annat tungt krav, men utvecklare b\u00f6r f\u00e5nga alla fel i applikationen tidigt och f\u00f6rb\u00e4ttra kodens kvalitet f\u00f6r att s\u00e4kerst\u00e4lla att slutanv\u00e4ndarna kommer att vara n\u00f6jda. Lyckligtvis finns det m\u00e5nga verktyg med \u00f6ppen k\u00e4llkod f\u00f6r att testa din kod och ge rekommendationer f\u00f6r att f\u00f6rb\u00e4ttra dess kvalitet. \u00c4nnu b\u00e4ttre \u00e4r att de flesta CI\/CD-verktyg kan kopplas till dessa verktyg och automatisera processen.<\/p>\n

Kodtestning best\u00e5r av tv\u00e5 delar: testningsramverk som hj\u00e4lper till att skriva och k\u00f6ra tester, samt verktyg f\u00f6r att generera f\u00f6rslag som hj\u00e4lper till att f\u00f6rb\u00e4ttra kodens kvalitet.<\/p>\n

Kodtestningssystem<\/b><\/p>\n

Namn
\nLicens
\nProgrammeringsspr\u00e5k<\/p>\n

JUnit
\nEclipse Public License
\nJava<\/p>\n

EasyMock
\nApache
\nJava<\/p>\n

Mockito
\nMIT
\nJava<\/p>\n

PowerMock
\nApache 2.0
\nJava<\/p>\n

Pytest
\n MIT
\nPython<\/p>\n

Hypothesis
\nMozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Rekommendationssystem f\u00f6r kodf\u00f6rb\u00e4ttring<\/b><\/p>\n

Namn
\nLicens
\nProgrammeringsspr\u00e5k<\/p>\n

Cobertura
\n(Gnu\u2019s Not Unix), som syftar till att utveckla systemkomponenter f\u00f6r att skapa ett fritt alternativ till Unix, vilket g\u00f6r det m\u00f6jligt att helt undvika propriet\u00e4r programvara. Under GNU:s skydd har det skapats en gemenskap av fria projekt, som r\u00f6r sig mot ett gemensamt m\u00e5l och utvecklas i enlighet med en enad ideologi och filosofi. Initialt var de centrala delarna av projektet
\nJava<\/p>\n

CodeCover
\nEclipse Public (EPL)
\nJava<\/p>\n

Coverage.py
\n Apache 2.0
\nPython<\/p>\n

Emma
\nCommon Public License
\nJava<\/p>\n

JaCoCo
\n Eclipse Public License
\nJava<\/p>\n

Hypothesis
\n Mozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Jasmine
\nMIT
\nJavaScript<\/p>\n

Karma
\nMIT
\nJavaScript<\/p>\n

Mocha
\n MIT
\nJavaScript<\/p>\n

Jest
\nMIT
\nJavaScript<\/p>\n

Observera att de flesta verktyg och ramverk som n\u00e4mns ovan \u00e4r skrivna f\u00f6r Java, Python och JavaScript, medan C++ och C# \u00e4r propriet\u00e4ra programmeringsspr\u00e5k (\u00e4ven om GCC har \u00f6ppen k\u00e4llkod).<\/p>\n

Nu n\u00e4r du har implementerat verktygen f\u00f6r kodt\u00e4ckning b\u00f6r din DevOps-pipeline se ut som diagrammet som visas i b\u00f6rjan av denna guide.<\/p>\n

Extra steg<\/h3>\n

\nContainrar<\/b><\/p>\n

Som jag redan n\u00e4mnt kan du hosta din server p\u00e5 en virtuell maskin eller server, men containrar \u00e4r en popul\u00e4r l\u00f6sning.<\/p>\n

Vad \u00e4r containrar? En kort f\u00f6rklaring \u00e4r att en virtuell maskin beh\u00f6ver en enorm m\u00e4ngd minne fr\u00e5n operativsystemet, vilket \u00f6verstiger storleken p\u00e5 applikationen, medan en container bara beh\u00f6ver n\u00e5gra bibliotek och konfigurationer f\u00f6r att k\u00f6ra applikationen. Det \u00e4r uppenbart att virtuella maskiner fortfarande har viktiga anv\u00e4ndningsomr\u00e5den, men en container \u00e4r en l\u00e4tt l\u00f6sning f\u00f6r att hosta applikationen, inklusive applikationsservrar.<\/p>\n

\u00c4ven om det finns andra alternativ f\u00f6r containrar, \u00e4r de mest popul\u00e4ra Docker och Kubernetes.<\/p>\n

Docker: Apache 2.0
\nKubernetes: Apache 2.0<\/p>\n

Mellanautomatiseringsverktyg<\/b><\/p>\n

V\u00e5r DevOps-pipeline \u00e4r fr\u00e4mst inriktad p\u00e5 samarbete f\u00f6r skapande och distribution av applikationer, men det finns m\u00e5nga andra saker som kan g\u00f6ras med hj\u00e4lp av DevOps-verktyg. En av dem \u00e4r anv\u00e4ndningen av verktyg f\u00f6r Infrastruktur som Kod (IaC), som ocks\u00e5 \u00e4r k\u00e4nda som mellanautomatiseringsmedel. Dessa verktyg hj\u00e4lper till att automatisera installation, hantering och andra uppgifter f\u00f6r mellanprogramvara. Till exempel kan ett automatiseringsverktyg extrahera applikationer som webbapplikationsservrar, databaser och \u00f6vervakningsverktyg, med r\u00e4tt konfigurationer och distribuera dem p\u00e5 applikationsservern.<\/p>\n

H\u00e4r \u00e4r n\u00e5gra mellanautomatiseringsverktyg med \u00f6ppen k\u00e4llkod:<\/p>\n

Ansible: GNU Public
\nSaltStack: Apache 2.0
\nChef: Apache 2.0
\nPuppet: Apache eller GPL<\/p>\n

\"Guide<\/p>\n

L\u00e4r dig mer om hur du kan skaffa en eftertraktad yrkesroll fr\u00e5n grunden eller Level Up dina f\u00e4rdigheter och din l\u00f6n genom att ta betalda onlinekurser fr\u00e5n SkillFactory:<\/p>\n