{"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\/ro\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","title":{"rendered":"Ghid pentru \u00eencep\u0103tori: cre\u0103m un pipeline DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dac\u0103 e\u0219ti nou \u00een DevOps, arunc\u0103 o privire asupra acestui ghid pentru a-\u021bi crea primul pipeline \u00een cinci etape.<\/i><\/p>\n

\"Ghid<\/p>\n

DevOps a devenit solu\u021bia standard pentru remedierea proceselor de dezvoltare software lente, fragmentate sau ineficiente. Problema este c\u0103, dac\u0103 e\u0219ti novice \u00een DevOps \u0219i nu \u0219tii de unde s\u0103 \u00eencepi, s-ar putea s\u0103 \u00ee\u021bi lipseasc\u0103 \u00een\u021belegerea acestor metode. \u00cen acest articol, vom defini pipeline-ul DevOps \u0219i va fi oferit un ghid pentru a-l crea \u00een cinci pa\u0219i. De\u0219i acest ghid nu este exhaustiv, ar trebui s\u0103 \u00ee\u021bi ofere o baz\u0103 pentru a-\u021bi \u00eencepe c\u0103l\u0103toria \u0219i a-\u021bi extinde cuno\u0219tin\u021bele \u00een viitor. Dar s\u0103 \u00eencepem cu o poveste.<\/p>\n

C\u0103l\u0103toria mea \u00een DevOps<\/h3>\n

\n\u00cen trecut, am lucrat \u00een echipa de cloud a Citi Group, dezvolt\u00e2nd o aplica\u021bie web Infrastructure-as-a-Service (IaaS) pentru gestionarea infrastructurii cloud a Citi, dar am fost mereu interesat de cum s\u0103 fac procesul de dezvoltare mai eficient \u0219i s\u0103 aduc schimb\u0103ri culturale pozitive \u00een echipa de dezvoltare. R\u0103spunsul l-am g\u0103sit \u00een cartea recomandat\u0103 de Greg Lavender, directorul tehnic al Citi pentru arhitectura cloud \u0219i infrastructur\u0103. Cartea se numea \u201eProiectul Fenix\u201d (The Phoenix Project<\/a><\/noindex>), \u0219i explic\u0103 principiile DevOps, fiind citit\u0103 ca un roman.<\/p>\n

\u00cen tabelul de pe coperta din spate a c\u0103r\u021bii se arat\u0103 c\u00e2t de des diferite companii \u00ee\u0219i desf\u0103\u0219oar\u0103 sistemele \u00een mediul de lansare a versiunilor:<\/p>\n

Amazon: 23.000 pe zi
\nGoogle: 5.500 pe zi
\nNetflix: 500 pe zi
\nFacebook: O dat\u0103 pe zi
\nTwitter: De 3 ori pe s\u0103pt\u0103m\u00e2n\u0103
\nO companie tipic\u0103: O dat\u0103 la 9 luni<\/p>\n

Cum sunt posibile frecven\u021bele Amazon, Google \u0219i Netflix? Totul deoarece aceste companii au g\u0103sit solu\u021bia pentru a crea un pipeline DevOps aproape perfect.
\n<\/a><\/noindex>
\nAm fost departe de acest lucru p\u00e2n\u0103 c\u00e2nd am implementat DevOps \u00een Citi. Atunci, echipa mea avea medii diverse, dar desf\u0103\u0219urarea pe serverul de dezvoltare era complet manual\u0103. To\u021bi dezvoltatorii aveau acces doar la un singur server de dezvoltare bazat pe IBM WebSphere Application Server Community Edition. Problema era c\u0103 serverul se \u00eenchidea de fiecare dat\u0103 c\u00e2nd mai mul\u021bi utilizatori \u00eencercau simultan s\u0103 efectueze desf\u0103\u0219urarea, a\u0219a c\u0103 dezvoltatorii trebuiau s\u0103 \u00ee\u0219i comunice inten\u021biile, ceea ce era destul de dificil. \u00cen plus, existau probleme cu acoperirea testelor la nivel de cod, cu procesele voluminoase de desf\u0103\u0219urare manual\u0103 \u0219i cu lipsa posibilit\u0103\u021bii de a urm\u0103ri desf\u0103\u0219urarea codului legat\u0103 de o anumit\u0103 sarcin\u0103 sau poveste utilizator.<\/p>\n

Am realizat c\u0103 trebuie s\u0103 fac ceva \u0219i am g\u0103sit un coleg cu acelea\u0219i viziuni. Am decis s\u0103 colabor\u0103m pentru a crea prima versiune a conveiului nostru DevOps \u2013 el a configurat o ma\u0219in\u0103 virtual\u0103 \u0219i serverul de aplica\u021bii Tomcat, \u00een timp ce eu am lucrat la Jenkins, am integrat Atlassian Jira \u0219i BitBucket \u0219i am lucrat la acoperirea testelor de cod. Acest proiect lateral a fost foarte de succes: am automatizat aproape complet multe procese, am ob\u021binut o func\u021bionalitate de aproape 100% a serverului nostru de dezvoltare, am asigurat urm\u0103rirea \u0219i am \u00eembun\u0103t\u0103\u021bit acoperirea testului de cod, precum \u0219i am ad\u0103ugat posibilitatea de a lega ramuri \u00een Git de sarcini \u00een Jira sau desf\u0103\u0219ur\u0103ri. Majoritatea instrumentelor pe care le-am folosit pentru a construi conveiul nostru DevOps erau cu surs\u0103 deschis\u0103.<\/p>\n

Acum \u00een\u021beleg c\u00e2t de simplu era conveiul nostru DevOps: nu foloseam extensii precum Jenkins files sau Ansible. Cu toate acestea, acest conveiu simplu a func\u021bionat bine, poate datorit\u0103 principiului Pareto (cunoscut \u0219i sub numele de regula 80\/20).<\/p>\n

Introducere scurt\u0103 \u00een DevOps \u0219i conveiul CI\/CD<\/h3>\n

\nDac\u0103 \u00eentreba\u021bi c\u00e2\u021biva oameni: \u201eCe este DevOps?\u201d, probabil ve\u021bi ob\u021bine c\u00e2teva r\u0103spunsuri diferite. DevOps, la fel ca Agile, a evoluat pentru a cuprinde multe discipline diferite, dar majoritatea oamenilor vor fi de acord cu anumite lucruri: DevOps este o practic\u0103 de dezvoltare software sau un ciclu de via\u021b\u0103 al dezvolt\u0103rii software (SDLC), al c\u0103rei principiu central este schimbarea culturii \u00een care dezvoltatorii \u0219i non-dezvoltatorii coexist\u0103 \u00eentr-un mediu \u00een care:<\/p>\n

Opera\u021biunile care erau anterior efectuate manual sunt automatizate;
\nFiecare face ceea ce \u0219tie s\u0103 fac\u0103 cel mai bine;
\nNum\u0103rul de implement\u0103ri pe o anumit\u0103 perioad\u0103 de timp cre\u0219te; Capacitatea de lucru cre\u0219te;
\nFlexibilitatea dezvolt\u0103rii cre\u0219te.<\/p>\n

De\u0219i a avea instrumentele software potrivite nu este singurul lucru necesar pentru a crea un mediu DevOps, unele instrumente sunt esen\u021biale. Un instrument cheie este integrarea continu\u0103 \u0219i livrarea continu\u0103 (CI\/CD). \u00cen aceast\u0103 conduct\u0103, mediile au diferite etape (de exemplu, DEV, INT, TST, QA, UAT, STG, PROD), multe opera\u021biuni sunt automatizate, iar dezvoltatorii pot scrie cod de calitate superioar\u0103, ob\u021bin\u00e2nd flexibilitate \u00een dezvoltare \u0219i frecven\u021b\u0103 ridicat\u0103 a livr\u0103rilor.<\/p>\n

Acest articol descrie o abordare \u00een cinci pa\u0219i pentru a crea un conduct\u0103 DevOps, similar\u0103 cu cea ilustrat\u0103 \u00een diagrama urm\u0103toare, folosind instrumente cu surs\u0103 deschis\u0103.<\/p>\n

Pasul 1: Metode CI\/CD<\/h3>\n

\nPrimul lucru de care ave\u021bi nevoie este un instrument pentru CI\/CD. Jenkins, un instrument cu surs\u0103 deschis\u0103 bazat pe Java \u0219i distribuit sub licen\u021ba MIT, este acel instrument care a popularizat direc\u021bia DevOps \u0219i a devenit standardul de facto.<\/p>\n

Ce este Jenkins mai exact? Considera\u021bi-l un fel de telecomand\u0103 magic\u0103 universal\u0103 care poate comunica cu diverse servicii \u0219i instrumente \u0219i le poate organiza. De unul singur, un instrument CI\/CD, cum ar fi Jenkins, este inutil, dar devine mai puternic pe m\u0103sur\u0103 ce se conecteaz\u0103 la diverse instrumente \u0219i servicii.<\/p>\n

Jenkins este doar unul dintre cele multe instrumente cu surs\u0103 deschis\u0103 pentru CI\/CD pe care le pute\u021bi folosi pentru a construi un conduct\u0103 DevOps.<\/p>\n

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

Iat\u0103 cum arat\u0103 procesele DevOps cu un instrument CI\/CD:<\/p>\n

\"Ghid<\/p>\n

Ave\u021bi un instrument CI\/CD care func\u021bioneaz\u0103 pe localhost, dar \u00een prezent nu pute\u021bi face prea multe. S\u0103 trecem la urm\u0103toarea etap\u0103 a c\u0103l\u0103toriei \u00een lumea DevOps.<\/p>\n

Pasul 2: Gestionarea sistemelor de control al versiunilor<\/h3>\n

\nCea mai bun\u0103 (\u0219i, poate, cea mai simpl\u0103) modalitate de a verifica dac\u0103 instrumentul dvs. CI\/CD poate face minuni este s\u0103 se integreze cu un instrument de control al surselor (SCM). De ce ave\u021bi nevoie de controlul surselor? Presupun\u00e2nd c\u0103 dezvolta\u021bi o aplica\u021bie. De fiecare dat\u0103 c\u00e2nd crea\u021bi o aplica\u021bie, programa\u021bi, iar acest lucru este valabil indiferent dac\u0103 folosi\u021bi Java, Python, C++, Go, Ruby, JavaScript sau unul dintre zecile de mii de limbaje de programare. Codul pe care \u00eel scrie\u021bi se nume\u0219te cod surs\u0103. La \u00eenceput, mai ales c\u00e2nd lucra\u021bi singur, este probabil c\u0103 pute\u021bi pune totul \u00eentr-un director local. Dar c\u00e2nd proiectul devine mai mare \u0219i invita\u021bi alte persoane s\u0103 colaboreze, ave\u021bi nevoie de o modalitate de a preveni conflictele \u00een timp ce partaja\u021bi modific\u0103rile eficient. De asemenea, ave\u021bi nevoie de o modalitate de a recupera versiunile anterioare, deoarece crearea de copii de rezerv\u0103 \u0219i copierea\/\u00eenserarea acestora este deja dep\u0103\u0219it\u0103. Ave\u021bi (\u0219i echipa dvs.) nevoie de ceva mai bun.<\/p>\n

Aici este unde un instrument de control al versiunilor devine practic necesar. Acest instrument p\u0103streaz\u0103 codul dvs. \u00een depozite, \u021bine eviden\u021ba versiunilor \u0219i coordoneaz\u0103 activitatea participan\u021bilor la proiect.<\/p>\n

De\u0219i exist\u0103 multe instrumente de control al surselor, Git este standardul, \u0219i este adev\u0103rat. V\u0103 recomand cu c\u0103ldur\u0103 s\u0103 utiliza\u021bi Git, de\u0219i exist\u0103 \u0219i alte op\u021biuni cu surs\u0103 deschis\u0103, dac\u0103 prefera\u021bi.<\/p>\n

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

Iat\u0103 cum arat\u0103 un pipeline DevOps cu instrumentele de control al surselor ad\u0103ugate.<\/p>\n

\"Ghid<\/p>\n

Instrumentul CI\/CD poate automatiza procesele de verificare, ob\u021binere a codului surs\u0103 \u0219i colaborare \u00eentre membri. Nu este r\u0103u? Dar cum transform\u0103m asta \u00eentr-o aplica\u021bie func\u021bional\u0103, astfel \u00eenc\u00e2t miliarde de oameni s\u0103 o poat\u0103 utiliza \u0219i aprecia?<\/p>\n

Pasul 3: Crearea instrumentului de automatizare a construc\u021biei<\/h3>\n

\nExcelent! Pute\u021bi verifica codul \u0219i face modific\u0103ri \u00een sistemul de control al versiunilor, precum \u0219i invita prietenii s\u0103 colaboreze la dezvoltare. Dar nu a\u021bi creat \u00eenc\u0103 o aplica\u021bie. Pentru a face o aplica\u021bie web, trebuie s\u0103 fie compilat\u0103 \u0219i \u00eempachetat\u0103 \u00eentr-un format de pachet desf\u0103\u0219urabil sau s\u0103 fie rulat\u0103 ca un fi\u0219ier executabil. (Re\u021bine\u021bi c\u0103 un limbaj de programare interpretat, cum ar fi JavaScript sau PHP, nu necesit\u0103 compilare).<\/p>\n

Utiliza\u021bi un instrument de automatizare a construirii. Indiferent de instrumentul de automatizare a construirii pe care decide\u021bi s\u0103-l folosi\u021bi, toate au acela\u0219i scop: de a procesa codul surs\u0103 \u00eentr-un format dorit \u0219i de a automatiza sarcini precum cur\u0103\u021bAREA, compilAREA, testAREA \u0219i desf\u0103\u0219urAREA \u00een medii specifice. Instrumentele de construire vor varia \u00een func\u021bie de limbajul dumneavoastr\u0103 de programare, dar iat\u0103 c\u00e2teva op\u021biuni comune cu surs\u0103 deschis\u0103.<\/p>\n

Denumire
\nLicen\u021b\u0103
\nLimbaj de programare<\/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
\nGNU
\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
\nGNU
\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

Minunat! Pute\u021bi plasa fi\u0219ierele de configurare ale instrumentului de automatizare a construirii \u00een sistemul de control al versiunilor \u0219i permite\u021bi instrumentului dumneavoastr\u0103 CI\/CD s\u0103 le integreze.<\/p>\n

\"Ghid<\/p>\n

Totul este bine, nu-i a\u0219a? Dar unde ve\u021bi desf\u0103\u0219ura aplica\u021bia dumneavoastr\u0103?<\/p>\n

Pasul 4: Server pentru aplica\u021bii web<\/h3>\n

\nP\u00e2n\u0103 acum ave\u021bi un fi\u0219ier \u00eempachetat care poate fi fie executabil, fie instalabil. Pentru ca orice aplica\u021bie s\u0103 fie cu adev\u0103rat util\u0103, ea trebuie s\u0103 ofere un serviciu sau o interfa\u021b\u0103, dar ave\u021bi nevoie de un container pentru a g\u0103zdui aplica\u021bia.<\/p>\n

Serverul pentru aplica\u021bii web este exact acel container. Serverul ofer\u0103 un mediu \u00een care poate fi definit\u0103 logica pachetului desf\u0103\u0219urat. De asemenea, serverul ofer\u0103 o interfa\u021b\u0103 \u0219i ofer\u0103 servicii web, deschiz\u00e2nd socket-uri c\u0103tre lumea extern\u0103. Ave\u021bi nevoie de un server HTTP, precum \u0219i de un mediu (de exemplu, o ma\u0219in\u0103 virtual\u0103) pentru instalarea sa. \u00centre timp, s\u0103 presupunem c\u0103 ve\u021bi \u00eenv\u0103\u021ba despre acest lucru mai t\u00e2rziu (de\u0219i v\u0103 voi vorbi despre containere mai jos).<\/p>\n

Exist\u0103 mai multe servere pentru aplica\u021bii web cu surs\u0103 deschis\u0103.<\/p>\n

Denumire
\nLicen\u021b\u0103
\nLimbaj de programare<\/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

Pipelines-ul t\u0103u DevOps este aproape gata de utilizare. Bun\u0103 treab\u0103!<\/p>\n

\"Ghid<\/p>\n

De\u0219i te po\u021bi opri aici \u0219i s\u0103 te ocupi de integrare pe cont propriu, calitatea codului este un aspect important pentru dezvoltatorii de aplica\u021bii, \u0219i trebuie s\u0103 fie o preocupare.<\/p>\n

Pasul 5: Acoperirea test\u0103rii codului<\/h3>\n

\nImplementarea testelor poate fi o alt\u0103 cerin\u021b\u0103 voluminoas\u0103, dar dezvoltatorii trebuie s\u0103 prind\u0103 orice eroare \u00een aplica\u021bie din fazele incipiente \u0219i s\u0103 \u00eembun\u0103t\u0103\u021beasc\u0103 calitatea codului pentru a garanta c\u0103 utilizatorii finali vor fi mul\u021bumi\u021bi. Din fericire, exist\u0103 o mul\u021bime de instrumente open-source pentru a testa codul t\u0103u \u0219i a oferi sugestii de \u00eembun\u0103t\u0103\u021bire a acestuia. Mai bine, majoritatea instrumentelor CI\/CD pot fi integrate cu aceste unelte \u0219i pot automatiza procesul.<\/p>\n

Testarea codului se \u00eemparte \u00een dou\u0103 p\u0103r\u021bi: framework-uri de testare a codului, care ajut\u0103 la scrierea \u0219i execu\u021bia testelor, \u0219i instrumente care ofer\u0103 sugestii pentru \u00eembun\u0103t\u0103\u021birea calit\u0103\u021bii codului.<\/p>\n

Sisteme de testare a codului<\/b><\/p>\n

Denumire
\nLicen\u021b\u0103
\nLimbaj de programare<\/p>\n

JUnit
\nLicen\u021ba Public\u0103 Eclipse
\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

Sisteme de recomandare pentru \u00eembun\u0103t\u0103\u021birea codului<\/b><\/p>\n

Denumire
\nLicen\u021b\u0103
\nLimbaj de programare<\/p>\n

Cobertura
\nGNU
\nJava<\/p>\n

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

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

Emma
\nLicen\u021ba Public\u0103 Comun\u0103
\nJava<\/p>\n

JaCoCo
\n Licen\u021ba Public\u0103 Eclipse
\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

Re\u021bine c\u0103 majoritatea instrumentelor \u0219i framework-urilor men\u021bionate mai sus sunt scrise pentru Java, Python \u0219i JavaScript, deoarece C++ \u0219i C# sunt limbaje de programare proprietare (de\u0219i GCC are cod surs\u0103 deschis).<\/p>\n

Acum c\u0103 ai implementat instrumentele de acoperire a codului cu teste, pipeline-ul t\u0103u DevOps ar trebui s\u0103 arate ca diagrama prezentat\u0103 la \u00eenceputul acestui ghid.<\/p>\n

Pa\u0219i suplimentari<\/h3>\n

\nContainere<\/b><\/p>\n

A\u0219a cum am men\u021bionat, po\u021bi g\u0103zdui serverul pe o ma\u0219in\u0103 virtual\u0103 sau pe un server, dar containerele sunt o solu\u021bie popular\u0103.<\/p>\n

Ce sunt containerele? Pe scurt, o ma\u0219in\u0103 virtual\u0103 necesit\u0103 o cantitate considerabil\u0103 de memorie pentru sistemul de operare, dep\u0103\u0219ind dimensiunea aplica\u021biei, \u00een timp ce un container are nevoie doar de c\u00e2teva biblioteci \u0219i configura\u021bii pentru a rula aplica\u021bia. Evident, o ma\u0219in\u0103 virtual\u0103 are \u00eenc\u0103 aplica\u021bii importante, dar un container este o solu\u021bie u\u0219oar\u0103 pentru g\u0103zduirea aplica\u021biei, inclusiv a serverului de aplica\u021bii.<\/p>\n

De\u0219i exist\u0103 \u0219i alte tipuri de containere, cele mai populare sunt Docker \u0219i Kubernetes.<\/p>\n

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

Instrumente intermediare de automatizare<\/b><\/p>\n

Pipeline-ul nostru DevOps se concentreaz\u0103 \u00een principal pe colaborarea \u00een crearea \u0219i desf\u0103\u0219urarea aplica\u021biilor, dar exist\u0103 multe alte lucruri care pot fi realizate cu instrumentele DevOps. Unul dintre acestea este utilizarea instrumentelor Infrastructure as Code (IaC), care sunt cunoscute \u0219i sub numele de instrumente intermediare de automatizare. Aceste instrumente ajut\u0103 la automatizarea instal\u0103rii, gestion\u0103rii \u0219i altor sarcini pentru software-ul intermediar. De exemplu, un instrument de automatizare poate extrage aplica\u021bii precum serverul aplica\u021biilor web, baza de date \u0219i instrumentul de monitorizare, cu configura\u021biile corecte \u0219i le poate desf\u0103\u0219ura pe serverul aplica\u021biilor.<\/p>\n

Iat\u0103 c\u00e2teva instrumente intermediare de automatizare cu surs\u0103 deschis\u0103:<\/p>\n

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

\"Ghid<\/p>\n

Afla\u021bi detaliile despre cum s\u0103 ob\u021bine\u021bi o profesie solicitat\u0103 de la zero sau s\u0103 face\u021bi un Level Up pentru abilit\u0103\u021bi \u0219i salariu, parcurg\u00e2nd cursurile online cu plat\u0103 SkillFactory:<\/p>\n