Och du svarade \u00e4nd\u00e5 inte p\u00e5 fr\u00e5gan: \"Beh\u00f6vs Jenkins eller inte?\"<\/em><\/p>\n<\/p>\n
Jenkins beh\u00f6vs egentligen inte i n\u00e5got fall. Om jag ska vara \u00e4rlig, s\u00e5 ger verktyg som Jenkins, Gitlab dig bekv\u00e4mlighet. Du kommer att se om bygget lyckades eller inte. De kan hj\u00e4lpa dig, men de ger dig inte praktiken. De kan bara ge dig en indikator \u2013 Okej, inte okej. Och s\u00e5vida du skriver tester, f\u00f6r annars \u00e4r det n\u00e4stan meningsl\u00f6st. S\u00e5 det beh\u00f6vs, f\u00f6r att \u2013 det \u00e4r bekv\u00e4mare, men i stort sett kan man klara sig utan det, man f\u00f6rlorar inte mycket. <\/p>\n
<\/p>\n
Det vill s\u00e4ga, om du har praxis, s\u00e5 beh\u00f6vs det inte?<\/em><\/p>\n<\/p>\n
Helt korrekt. Jag rekommenderar testet av Jez Humble. Jag har en blandad k\u00e4nsla ang\u00e5ende den sista punkten. Men generellt, om du har tre saker; du sl\u00e5r samman konstant, du k\u00f6r tester p\u00e5 commits i master, och fixar bygget snabbt i master, d\u00e5 kanske du inte beh\u00f6ver n\u00e5got mer. <\/p>\n
<\/p>\n
Medan vi v\u00e4ntar p\u00e5 fr\u00e5gor fr\u00e5n deltagarna, har jag en fr\u00e5ga. Vi har nu pratat om produktkod. Har du anv\u00e4nt det f\u00f6r infrastrukturkod? \u00c4r det samma slags kod, med samma principer och livscykel, eller finns det andra livscykler och principer? Vanligtvis n\u00e4r alla pratar om Continuous Integration och Development, gl\u00f6mmer man att det ocks\u00e5 finns infrastrukturkod. Och p\u00e5 senaste tiden har det \u00f6kat mer och mer. B\u00f6r vi f\u00f6ra in alla dessa regler d\u00e4r?<\/em><\/p>\n<\/p>\n
Det handlar inte bara om att det b\u00f6r g\u00f6ras, det skulle vara fantastiskt, eftersom det verkligen skulle f\u00f6renkla livet. S\u00e5 fort vi arbetar med kod, inte med bash-skript, utan vi har normal kod.<\/p>\n
<\/p>\n
Stopp-stop, bash-skript \u00e4r ocks\u00e5 kod. R\u00f6r inte min gamla k\u00e4rlek.<\/em> <\/p>\n<\/p>\n
Bra, jag ska inte trampa p\u00e5 dina minnen. Jag har en personlig aversion mot bash. Det kraschar p\u00e5 ett fult och skr\u00e4mmande s\u00e4tt hela tiden. Och det kraschar ofta of\u00f6ruts\u00e4gbart, s\u00e5 jag gillar det inte. Men okej, l\u00e5t oss s\u00e4ga att du har kod i bash. Kanske har jag verkligen ingen aning, och det finns bra testframeworks d\u00e4r. Jag \u00e4r bara inte insatt. Och vi f\u00e5r samma f\u00f6rdelar.<\/p>\n
<\/p>\n
N\u00e4r vi v\u00e4l hanterar infrastruktur som kod f\u00e5r vi alla samma problem som utvecklare. F\u00f6r n\u00e5gra m\u00e5nader sedan st\u00f6tte jag p\u00e5 en situation d\u00e4r en kollega skickade en pull request p\u00e5 1 000 rader bash. Och du fastnar p\u00e5 granskningen i 4 timmar. Problemen \u00e4r desamma. Det \u00e4r fortfarande kod. Och fortfarande samarbete. Vi fastnar med pull requests och vi fastnar med att reda ut samma sammanslagningskonflikter i bash, till exempel. <\/p>\n
<\/p>\n
Just nu tittar jag v\u00e4ldigt aktivt p\u00e5 allt detta med att programmera infrastrukturen p\u00e5 det mest eleganta s\u00e4ttet. Jag har just integrerat Pulumi i infrastrukturen. Det \u00e4r ren programmering. D\u00e4r \u00e4r det \u00e4nnu mer tilltalande, eftersom jag har alla spr\u00e5kets m\u00f6jligheter, dvs. jag gjorde snygga toggles med samma if-satser mitt p\u00e5 plan. S\u00e5 mitt f\u00f6r\u00e4ndring finns redan i master. Alla kan se det. Andra ingenj\u00f6rer \u00e4r medvetna om det. Det har redan p\u00e5verkat n\u00e5got. Men det har inte aktiverats f\u00f6r alla infrastrukturer. Det har aktiverats f\u00f6r mina testmilj\u00f6er, till exempel. S\u00e5 f\u00f6r att svara p\u00e5 din fr\u00e5ga igen, det beh\u00f6vs. Det f\u00f6renklar verkligen livet f\u00f6r oss ingenj\u00f6rer som arbetar med kod. <\/p>\n
<\/p>\n
\u00c4r det n\u00e5gra fler fr\u00e5gor?<\/em> <\/p>\n<\/p>\n
Jag har en fr\u00e5ga. Jag vill forts\u00e4tta diskussionen med Oleg. Generellt sett tycker jag att du har r\u00e4tt; om en uppgift tar en m\u00e5nad att g\u00f6ra, s\u00e5 har du problem med arkitekturen, du har problem med analys, dekonstruktion, planering, osv. Men jag har en k\u00e4nsla av att om du b\u00f6rjar f\u00f6rs\u00f6ka leva efter Continuous Integration, s\u00e5 kommer du att b\u00f6rja \u00e5tg\u00e4rda sm\u00e4rtorna med planeringen, f\u00f6r du kan inte undkomma det. <\/p>\n
<\/p>\n
(Oleg) Ja, s\u00e5 \u00e4r det. Denna praktik \u00e4r j\u00e4mf\u00f6rbar i arbetsinsats med andra allvarliga metoder som f\u00f6r\u00e4ndrar kulturen. Det sv\u00e5raste att \u00f6vervinna \u00e4r vanor, s\u00e4rskilt d\u00e5liga vanor. Och om det kr\u00e4vs en betydande f\u00f6r\u00e4ndring av vanorna hos de runt omkring: utvecklare, ledning, produktionschef, d\u00e5 kan ni f\u00f6rv\u00e4nta er \u00f6verraskningar.<\/em> <\/p>\n<\/p>\n
Vilka \u00f6verraskningar kan det vara? L\u00e5t oss s\u00e4ga att du best\u00e4mmer att du ska g\u00f6ra integration oftare. Och under integrationen \u00e4r det anslutna saker, till exempel artefakter. I ditt f\u00f6retag finns det en policy att varje artefakt m\u00e5ste registreras p\u00e5 n\u00e5got s\u00e4tt i ett system f\u00f6r lagring av artefakter. Och det tar en viss tid. En person m\u00e5ste checka av att han, som release manager, har testat denna artefakt f\u00f6r att den \u00e4r redo f\u00f6r produktion. Om det tar 5-10-15 minuter, men du g\u00f6r utrullningar en g\u00e5ng i veckan, d\u00e5 inneb\u00e4r det att du en g\u00e5ng i veckan spenderar en halvtimme \u2013 en liten skatt.<\/em> <\/p>\n<\/p>\n
Om du g\u00f6r Continuous Integration 10 g\u00e5nger om dagen, s\u00e5 beh\u00f6ver du multiplicera 10 g\u00e5nger med 30 minuter. Och det \u00f6verskrider arbetsvolymen f\u00f6r denna release manager. Han blir helt enkelt tr\u00f6tt p\u00e5 det. Det finns st\u00e4ndiga kostnader f\u00f6r vissa metoder. Och s\u00e5 \u00e4r det.<\/em> <\/p>\n<\/p>\n
Och du m\u00e5ste antingen avskaffa denna regel s\u00e5 att du inte sysslar med s\u00e5dant nonsens, dvs. att du inte manuellt bed\u00f6mer \u00f6verensst\u00e4mmelse mellan n\u00e5got och n\u00e5got. Du litar helt och h\u00e5llet p\u00e5 en automatiserad upps\u00e4ttning tester f\u00f6r beredskap.<\/em> <\/p>\n<\/p>\n
Och om du beh\u00f6ver en bekr\u00e4ftelse fr\u00e5n n\u00e5gon, s\u00e5 att chefen godk\u00e4nner, och du inte r\u00f6r vid produktionen utan att Vasja s\u00e4ger att det \u00e4r okej, o.s.v. \u2013 allt detta st\u00e5r i v\u00e4gen f\u00f6r metoder. F\u00f6r om det finns relaterade aktiviteter som en sorts skatt, s\u00e5 \u00f6kar allt hundrafaldigt. D\u00e4rf\u00f6r kommer f\u00f6r\u00e4ndringen ofta inte att v\u00e4lkomnas av alla. Eftersom det \u00e4r sv\u00e5rt att \u00e4ndra m\u00e4nniskors vanor.<\/em> <\/p>\n<\/p>\n
N\u00e4r en person utf\u00f6r sitt vanliga arbete g\u00f6r han det n\u00e4stan utan att t\u00e4nka. Den kognitiva belastningen \u00e4r n\u00e4ra noll. Han str\u00e4var fram\u00e5t med det som redan \u00e4r f\u00e4rdigt, han har en checklista i huvudet, han har gjort det tusen g\u00e5nger. Och s\u00e5 fort du kommer och s\u00e4ger till honom: \"L\u00e5t oss avskaffa denna praktik och inf\u00f6ra en ny fr\u00e5n m\u00e5ndag\" blir det en betydande kognitiv belastning f\u00f6r honom. Den intr\u00e4ffar dessutom f\u00f6r alla p\u00e5 en g\u00e5ng.<\/em> <\/p>\n<\/p>\n
D\u00e4rf\u00f6r \u00e4r det enklaste, \u00e4ven om denna lyx inte alla har r\u00e5d med, n\u00e5got jag alltid g\u00f6r. Det \u00e4r f\u00f6ljande: N\u00e4r ett nytt projekt startar, trycks ofta alla opr\u00f6vade metoder in i det projektet. S\u00e5 l\u00e4nge projektet \u00e4r ungt riskerar vi inte mycket. Det finns ingen produktion \u00e4n, det g\u00e5r inte att f\u00f6rst\u00f6ra n\u00e5got. D\u00e4rf\u00f6r kan det anv\u00e4ndas som tr\u00e4ning. Denna metod fungerar. Men inte alla f\u00f6retag har m\u00f6jlighet att ofta starta s\u00e5dana projekt. \u00c4ven om det \u00e4r lite konstigt, eftersom det p\u00e5g\u00e5r en digital transformation \u00f6verallt, alla borde experimentera f\u00f6r att h\u00e4nga med konkurrenterna.<\/em> <\/p>\n<\/p>\n
H\u00e4r st\u00f6ter du p\u00e5 det faktum att du m\u00e5ste ha en f\u00f6rst\u00e5else f\u00f6r vad du beh\u00f6ver g\u00f6ra fr\u00e5n b\u00f6rjan. V\u00e4rlden \u00e4r inte perfekt, och produktionen \u00e4r inte perfekt heller. <\/p>\n
<\/p>\n
Ja, dessa saker \u00e4r kopplade till varandra.<\/em><\/p>\n<\/p>\n
F\u00f6retag har inte alltid en f\u00f6rst\u00e5else f\u00f6r att de m\u00e5ste g\u00e5 just dit. <\/p>\n
<\/p>\n
Det finns situationer d\u00e4r inga f\u00f6r\u00e4ndringar \u00e4r m\u00f6jliga \u00f6verhuvudtaget. Det \u00e4r en situation d\u00e4r st\u00f6rre press l\u00e4ggs p\u00e5 teamet. Teamet \u00e4r redan ganska utbr\u00e4nt. Det har ingen tid kvar f\u00f6r n\u00e5gra experiment. De jobbar hela dagen med funktioner. Och ledningen \u00e4r alltid otillfredsst\u00e4lld med funktionerna. Det kr\u00e4vs mer och mer. I en s\u00e5dan situation \u00e4r inga f\u00f6r\u00e4ndringar m\u00f6jliga. Teamet kan endast f\u00e5 veta att imorgon ska vi g\u00f6ra som vi gjorde ig\u00e5r, bara att vi beh\u00f6ver leverera lite fler funktioner. Inga \u00f6verg\u00e5ngar till n\u00e5gra metoder \u00e4r d\u00e4rf\u00f6r m\u00f6jliga. Det \u00e4r en klassisk situation d\u00e4r det inte finns tid att slipa en yxa, man m\u00e5ste hugga ner tr\u00e4d, s\u00e5 man hugger med en trubbig yxa. H\u00e4r finns det inga enkla r\u00e5d.<\/em> <\/p>\n<\/p>\n
(Dmitrij) Jag l\u00e4ser upp en klarg\u00f6rande kommentar fr\u00e5n chatten: \"Men det beh\u00f6vs ett stort testt\u00e4cke p\u00e5 olika niv\u00e5er. Hur mycket tid \u00e4gnas \u00e5t tester? Det verkar ganska dyrt, det tar mycket tid.\"<\/em><\/p>\n<\/p>\n
(Oleg) Det h\u00e4r \u00e4r en klassisk missuppfattning. Det borde finnas tillr\u00e4ckligt med tester s\u00e5 att ni sj\u00e4lva har f\u00f6rtroende. Continuous Integration \u00e4r inte en s\u00e5dan sak d\u00e4r 100 % av testerna k\u00f6rs f\u00f6rst och sedan b\u00f6rjar ni anv\u00e4nda denna praxis. Continuous Integration minskar den kognitiva belastningen genom att varje f\u00f6r\u00e4ndring ni ser med blotta \u00f6gat \u00e4r s\u00e5 uppenbar att ni f\u00f6rst\u00e5r \u2013 om den bryter n\u00e5got eller inte, \u00e4ven utan tester. Ni kan snabbt testa detta i huvudet, eftersom f\u00f6r\u00e4ndringarna \u00e4r sm\u00e5. \u00c4ven om ni endast har manuella testare \u00e4r det enklare f\u00f6r dem ocks\u00e5. Ni sl\u00e4pper en uppdatering och s\u00e4ger: \"Kolla, har n\u00e5got g\u00e5tt s\u00f6nder?\". De kontrollerar och s\u00e4ger: \"Nej, inget har g\u00e5tt s\u00f6nder\". Eftersom testaren vet var de ska titta. Ni har en commit kopplad till ett specifikt kodstycke. Och det exponerar ett konkret beteende.<\/em><\/p>\n<\/p>\n
H\u00e4r har du, f\u00f6rst\u00e5s, \u00f6verdrivit. <\/p>\n
<\/p>\n
(Dmitry) H\u00e4r h\u00e5ller jag inte med. Det finns en praxis \u2013 testdriven utveckling som faktiskt kommer att r\u00e4dda oss fr\u00e5n detta.<\/em> <\/p>\n<\/p>\n
(Oleg) Ja, jag har inte kommit s\u00e5 l\u00e5ngt \u00e4n. Den f\u00f6rsta illusionen \u00e4r att man m\u00e5ste skriva 100 % tester eller inte alls syssla med Continuous Integration. Det \u00e4r en l\u00f6gn. Det h\u00e4r \u00e4r tv\u00e5 parallella praktiker. Och de \u00e4r inte direkt beroende av varandra. Ert testt\u00e4cke b\u00f6r vara optimalt. Optimalt betyder att ni sj\u00e4lva \u00e4r s\u00e4kra p\u00e5 att den kvalitet av huvudkoden som kvarst\u00e5r efter er commit till\u00e5ter er att trycka p\u00e5 knappen \"Deploy\" p\u00e5 fredag kv\u00e4ll, \u00e4ven om ni \u00e4r berusade. Hur uppn\u00e5r ni detta? Genom granskningar, genom t\u00e4ckning, genom bra \u00f6vervakning.<\/em> <\/p>\n<\/p>\n
Bra \u00f6vervakning \u00e4r inte skillnad fr\u00e5n tester. Om ni k\u00f6r tester en g\u00e5ng p\u00e5 pre-prod, s\u00e5 kontrollerar de era anv\u00e4ndarscenarier en g\u00e5ng och s\u00e5 enkelt \u00e4r det. Men om ni k\u00f6r dem i en o\u00e4ndlig slinga, d\u00e5 \u00e4r det ert utbyggda \u00f6vervakningssystem som testar allt o\u00e4ndligt \u2013 om det har kraschat eller inte. I detta fall \u00e4r skillnaden bara i eng\u00e5ngs- eller flerg\u00e5ngsk\u00f6rning. En mycket bra upps\u00e4ttning tester..., som k\u00f6rs o\u00e4ndligt, \u00e4r \u00f6vervakning. Och korrekt \u00f6vervakning b\u00f6r vara s\u00e5.<\/em> <\/p>\n<\/p>\n
Och d\u00e4rf\u00f6r, hur ni exakt ska n\u00e5 detta tillst\u00e5nd d\u00e4r ni kan deploya p\u00e5 fredag kv\u00e4ll och g\u00e5 hem \u00e4r en annan fr\u00e5ga. Kanske \u00e4r ni helt enkelt en modig idiot.<\/em> <\/p>\n<\/p>\n
L\u00e5t oss g\u00e5 tillbaka lite till Continuous Integration. Vi har avvikit n\u00e5got till en annan komplex praktik. <\/p>\n
<\/p>\n
Och den andra illusionen \u00e4r att MVP s\u00e4gs vara n\u00e5got man m\u00e5ste g\u00f6ra snabbt, s\u00e5 tester beh\u00f6vs \u00f6verhuvudtaget inte. Det \u00e4r inte riktigt s\u00e5. Faktum \u00e4r att n\u00e4r du skriver en user story i MVP, s\u00e5 kan du utveckla den antingen helt p\u00e5 m\u00e5f\u00e5, dvs. du h\u00f6r att det finns en viss user story och springer direkt f\u00f6r att koda den, eller arbeta enligt TDD. Och enligt TDD, som erfarenheten visar, tar det inte l\u00e4ngre tid, dvs. tester \u00e4r en bieffekt. TDD-praktiken handlar inte om att testa. Trots namnet Test Driven Development handlar det \u00f6verhuvudtaget inte om tester. Det \u00e4r mer en arkitekturmetod. Det handlar om att skriva det som verkligen beh\u00f6vs och inte skriva det som inte beh\u00f6vs. Denna praktik fokuserar p\u00e5 n\u00e4sta iteration av dina tankar n\u00e4r det g\u00e4ller att skapa applikationens arkitektur.<\/em> <\/p>\n<\/p>\n
S\u00e5 det \u00e4r inte s\u00e5 enkelt att bli av med dessa illusioner. MVP och tester mots\u00e4ger inte varandra. Snarare tv\u00e4rtom, om du g\u00f6r MVP enligt TDD-praktiken, kommer du att g\u00f6ra det b\u00e4ttre och snabbare \u00e4n om du g\u00f6r det helt utan praktik och p\u00e5 m\u00e5f\u00e5.<\/em><\/p>\n<\/p>\n
Det \u00e4r en v\u00e4ldigt otydlig och komplex tanke. N\u00e4r du h\u00f6r att nu ska jag skriva ytterligare tester och samtidigt kommer jag att g\u00f6ra n\u00e5got snabbare, l\u00e5ter det helt orealistiskt. <\/p>\n
<\/p>\n
(Dmitrij) M\u00e5nga n\u00e4r de pratar om MVP, det \u00e4r bara f\u00f6r att folk \u00e4r f\u00f6r lata f\u00f6r att skriva n\u00e5got bra. Och det \u00e4r verkligen tv\u00e5 olika saker. Man b\u00f6r inte f\u00f6rvandla MVP till n\u00e5got d\u00e5ligt som inte fungerar.<\/em> <\/p>\n<\/p>\n
Ja, du har r\u00e4tt.<\/p>\n
<\/p>\n
Och pl\u00f6tsligt \u00e4r MVP i produktion.<\/em><\/p>\n<\/p>\n
F\u00f6r alltid. <\/p>\n
<\/p>\n
Och TDD l\u00e5ter v\u00e4ldigt ovanligt n\u00e4r man h\u00f6r att du skriver tester och verkar g\u00f6ra mer arbete. Det l\u00e5ter v\u00e4ldigt konstigt, men faktiskt g\u00f6r det att det g\u00e5r snabbare och ser b\u00e4ttre ut. N\u00e4r du skriver ett test t\u00e4nker du redan mycket p\u00e5 vilken kod och hur den kommer att kallas, samt vilket beteende vi f\u00f6rv\u00e4ntar oss av den. Du s\u00e4ger inte bara att jag har skrivit en funktion och den g\u00f6r n\u00e5got. Du t\u00e4nker f\u00f6rst p\u00e5 att den har vissa villkor, den kommer att kallas p\u00e5 ett visst s\u00e4tt. Du t\u00e4cker det med tester och fr\u00e5n det f\u00f6rst\u00e5r du hur dina gr\u00e4nssnitt i din kod kommer att se ut. Det p\u00e5verkar verkligen arkitekturen. Din kod blir automatiskt mer modul\u00e4r, eftersom du f\u00f6rst f\u00f6rs\u00f6ker f\u00f6rst\u00e5 hur du kommer att testa den, och f\u00f6rst d\u00e4refter skriver du den. <\/p>\n
<\/p>\n
Jag hade det s\u00e5 med TDD att jag vid ett tillf\u00e4lle anlitade en mentor i Ruby n\u00e4r jag fortfarande var Ruby-programmerare. Och han sa: \"L\u00e5t oss g\u00f6ra det med TDD.\" Jag t\u00e4nkte: \"\u00c5h nej, jag m\u00e5ste skriva n\u00e5got extra nu.\" Vi kom \u00f6verens om att jag skulle skriva all fungerande kod p\u00e5 Python med TDD under tv\u00e5 veckor. Efter tv\u00e5 veckor ins\u00e5g jag att jag aldrig ville g\u00e5 tillbaka. Genom att f\u00f6rs\u00f6ka till\u00e4mpa det \u00f6verallt under tv\u00e5 veckor f\u00f6rstod jag hur mycket enklare det blev att t\u00e4nka. Men det \u00e4r inte uppenbart, s\u00e5 jag rekommenderar till alla att om ni k\u00e4nner att TDD \u00e4r sv\u00e5rt, l\u00e5ngsamt och \u00f6verfl\u00f6digt, f\u00f6rs\u00f6k att h\u00e5lla p\u00e5 med det i tv\u00e5 veckor. F\u00f6r mig r\u00e4ckte det med tv\u00e5.<\/p>\n
<\/p>\n
(Dmitrij) Vi kan utveckla den h\u00e4r tanken utifr\u00e5n infrastrukturen. Innan vi s\u00e4tter ig\u00e5ng n\u00e5got nytt g\u00f6r vi en \u00f6vervakning och d\u00e4refter s\u00e4tter vi ig\u00e5ng. I det h\u00e4r fallet blir \u00f6vervakningen ett normalt test. Och det finns utveckling genom \u00f6vervakning. Men n\u00e4stan alla s\u00e4ger att det tar l\u00e5ng tid, jag orkar inte, jag gjorde ett provisoriskt utkast. Om vi g\u00f6r \u00f6vervakningen ordentligt, f\u00f6rst\u00e5r vi tillst\u00e5ndet f\u00f6r CI-systemet. I CI-systemet finns mycket \u00f6vervakning. Vi f\u00f6rst\u00e5r systemets tillst\u00e5nd, vi vet vad som finns inuti. Under utvecklingen bygger vi just systemet s\u00e5 att det n\u00e5r det \u00f6nskade tillst\u00e5ndet.<\/em> <\/p>\n<\/p>\n
Dessa metoder har l\u00e4nge varit k\u00e4nda. Vi diskuterade dem f\u00f6r fyra \u00e5r sedan. Men \u00f6ver fyra \u00e5r har n\u00e4stan ingenting f\u00f6r\u00e4ndrats.<\/em> <\/p>\n<\/p>\n
Men p\u00e5 denna not vill jag avsluta den officiella diskussionen.<\/em><\/p>\n<\/p>\n
Video (infogad som medieelement, men av n\u00e5gon anledning fungerar det inte):<\/p>\n
\nhttps:\/\/youtu.be\/zZ3qXVN3Oic<\/a><\/noindex> habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041e\u0431\u0441\u0443\u0434\u0438\u043c \u043f\u043e\u0447\u0435\u043c\u0443 CI-\u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b \u0438 CI \u2013 \u044d\u0442\u043e \u0441\u043e\u0432\u0441\u0435\u043c \u043f\u0440\u043e \u0440\u0430\u0437\u043d\u043e\u0435. \u041a\u0430\u043a\u0443\u044e \u0431\u043e\u043b\u044c CI \u043f\u0440\u0438\u0437\u0432\u0430\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c, \u043e\u0442\u043a\u0443\u0434\u0430 \u0432\u043e\u0437\u043d\u0438\u043a\u043b\u0430 \u0438\u0434\u0435\u044f, \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0438\u044f \u0447\u0442\u043e \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u043a\u0430\u043a \u043f\u043e\u043d\u044f\u0442\u044c \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u0435\u0441\u0442\u044c \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430, \u0430 \u043d\u0435 \u043f\u0440\u043e\u0441\u0442\u043e \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u043d\u044b\u0439 Jenkins. \u041c\u044b\u0441\u043b\u044c \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0434\u043e\u043a\u043b\u0430\u0434 \u043f\u0440\u043e Continuous Integration \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u0435\u0449\u0435 \u0433\u043e\u0434 \u043d\u0430\u0437\u0430\u0434, \u043a\u043e\u0433\u0434\u0430 \u044f \u0445\u043e\u0434\u0438\u043b \u043f\u043e \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u044f\u043c \u0438\u0441\u043a\u0430\u043b \u0440\u0430\u0431\u043e\u0442\u0443. \u041f\u043e\u043e\u0431\u0449\u0430\u043b\u0441\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":93886,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-93885","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Continous](\"\/wp-content\/uploads\/2020\/09\/ed8a32ae63b8dccfc8b4893ab27f1527.jpg\")
<\/p>\n