Og du svarede stadig ikke p\u00e5 sp\u00f8rgsm\u00e5let: \"Er Jenkins n\u00f8dvendigt eller ej?\"<\/em><\/p>\n<\/p>\n
Jenkins er faktisk ikke n\u00f8dvendigt i nogen tilf\u00e6lde. Hvis jeg skal v\u00e6re alvorlig, s\u00e5 vil v\u00e6rkt\u00f8jerne: Jenkins, Gitlab give dig bekvemmelighed. Du vil kunne se, om bygningen lykkedes eller ej. De kan hj\u00e6lpe dig, men de vil ikke give dig praksis. De kan kun give dig en cirkel \u2013 Ok, ikke Ok. Og det, hvis du stadig skriver tests, for hvis der ikke er tests, er det stort set meningsl\u00f8st. S\u00e5 det er n\u00f8dvendigt, fordi det er mere praktisk, men generelt kan man klare sig uden det, du vil ikke miste meget. <\/p>\n
<\/p>\n
Det vil sige, hvis du har praksis, s\u00e5 er det ikke n\u00f8dvendigt for dig?<\/em><\/p>\n<\/p>\n
Helt korrekt. Jeg anbefaler testen af Jez Humble. Jeg har en blandet f\u00f8lelse over for det sidste punkt. Men generelt, hvis du har tre ting, du merger konstant, du k\u00f8rer tests p\u00e5 commits i masteren, hurtigt reparerer builden i masteren, s\u00e5 er det muligt, at du ikke har brug for mere. <\/p>\n
<\/p>\n
Mens vi venter p\u00e5 sp\u00f8rgsm\u00e5l fra deltagerne, har jeg et sp\u00f8rgsm\u00e5l. Vi har lige talt om produktionskoden. Har du brugt det til infrastrukturskode? Er det samme kode, med de samme principper og livscyklus, eller er der andre livscykler og principper? Normalt, n\u00e5r alle taler om Continuous Integration og Development, glemmer folk ofte, at der ogs\u00e5 er infrastrukturskode. Og i den seneste tid bliver det mere og mere vigtigt. B\u00f8r vi bringe alle disse regler derind?<\/em><\/p>\n<\/p>\n
Det er ikke bare, at vi b\u00f8r, det ville v\u00e6re fantastisk, fordi det helt sikkert ogs\u00e5 vil forenkle livet. S\u00e5 snart vi arbejder med kode, ikke med scripts i bash, men vi har normal kode.<\/p>\n
<\/p>\n
Stop-stop, skripter i bash er ogs\u00e5 kode. Lad v\u00e6re med at r\u00f8re ved min gamle k\u00e6rlighed.<\/em> <\/p>\n<\/p>\n
Det er fint, jeg vil ikke tr\u00e6de ind i dine minder. Jeg har en personlig modvilje mod bash. Det g\u00e5r ofte galt p\u00e5 en grim og skr\u00e6mmende m\u00e5de. Og det g\u00e5r ofte uforudsigeligt galt, s\u00e5 jeg har ikke meget k\u00e6rlighed til det. Men ok, lad os antage, at du har kode i bash. M\u00e5ske forst\u00e5r jeg ikke det, og der findes gode testframeworks der. Jeg er bare ikke i det. Og vi f\u00e5r de samme fordele.<\/p>\n
<\/p>\n
N\u00e5r vi arbejder med infrastruktur som kode, f\u00e5r vi de samme problemer som udviklere. For et par m\u00e5neder siden stod jeg i en situation, hvor en kollega sendte mig en pull request p\u00e5 1.000 linjer i bash. Og du sidder fast i gennemgangen i 4 timer. Problemerne er de samme. Det er stadig kode. Og det er stadig samarbejde. Vi sidder fast med pull requests og sidder fast med de samme merge-konflikter i bash, for eksempel. <\/p>\n
<\/p>\n
Jeg ser i \u00f8jeblikket meget aktivt p\u00e5 at lave smuk infrastrukturprogrammering. Jeg har nu f\u00e5et Pulumi ind i infrastrukturen. Det er ren programmering. Det er endnu mere tiltalende, fordi jeg har alle mulighederne fra programmeringssproget, dvs. jeg har lavet smukke toggles med de samme if'er. Dvs. min \u00e6ndring er allerede i masteren. Alle kan se det. Andre ingeni\u00f8rer er opm\u00e6rksomme p\u00e5 det. Det har allerede haft indflydelse p\u00e5 noget. Men det er ikke sl\u00e5et til for al infrastruktur. Det er sl\u00e5et til for mine testmilj\u00f8er, for eksempel. S\u00e5 for at svare p\u00e5 dit sp\u00f8rgsm\u00e5l igen, ja, det er noget, der bestemt g\u00f8r vores liv lettere som ingeni\u00f8rer, der arbejder med kode. <\/p>\n
<\/p>\n
Er der nogen sp\u00f8rgsm\u00e5l endnu?<\/em> <\/p>\n<\/p>\n
Jeg har et sp\u00f8rgsm\u00e5l. Jeg vil gerne forts\u00e6tte diskussionen med Oleg. Generelt mener jeg, at du har ret; hvis en opgave tager dig en m\u00e5ned, s\u00e5 har du et problem med arkitekturen, et problem med analysen, dekomponeringen, planl\u00e6gningen osv. Men jeg f\u00e5r det indtryk, at hvis du begynder at leve efter Continuous Integration, s\u00e5 vil du begynde at l\u00f8se problemerne med planl\u00e6gningen, fordi du ikke kan undg\u00e5 det. <\/p>\n
<\/p>\n
(Oleg) Ja, det er korrekt. Med hensyn til arbejdsbyrden er denne praksis sammenlignelig med enhver anden alvorlig praksis, der \u00e6ndrer kulturen. Den sv\u00e6reste del ved at overvinde dette er vaner, is\u00e6r d\u00e5rlige vaner. Og hvis det kr\u00e6ver en betydelig \u00e6ndring af vanerne hos de omkringliggende: udviklere, ledelse, produktionschefer, s\u00e5 vil du m\u00f8de overraskelser.<\/em> <\/p>\n<\/p>\n
Hvilke overraskelser kan der v\u00e6re? Antag, at du har besluttet dig for at lave integration oftere. Og integrationen er knyttet til nogle andre ting, som for eksempel artefakter. Og i din virksomhed er der for eksempel en politik om, at hvert artefakt skal registreres p\u00e5 en eller anden m\u00e5de i et system til opbevaring af artefakter. Det tager noget tid. En person skal s\u00e6tte en markering for, at han som release manager har testet dette artefakt til klarhed til produktion. Hvis det tager 5-10-15 minutter, men du laver en udrulning \u00e9n gang om ugen, s\u00e5 er det ikke al for stor en skat at bruge en halv time p\u00e5 det en gang om ugen.<\/em> <\/p>\n<\/p>\n
Hvis du laver Continuous Integration 10 gange om dagen, skal du gange 10 med 30 minutter. Og det overstiger den arbejdsbyrde, som denne release manager har. Han bliver simpelthen tr\u00e6t af det. Der er faste omkostninger ved visse praksisser. Og det hele.<\/em> <\/p>\n<\/p>\n
Og du skal enten oph\u00e6ve denne regel, s\u00e5 du ikke besk\u00e6ftiger dig med s\u00e5dan noget fis, dvs. du tildeler ikke manuelt en grad af overensstemmelse fra noget til noget. Du stoler helt og holdent p\u00e5 et eller andet automatiseret testset til klarhed.<\/em> <\/p>\n<\/p>\n
Og hvis du har brug for nogen til at give dig et bevis, s\u00e5 chefen underskriver, og du ikke g\u00e5r ind i produktion uden at Vasja har sagt, at han giver tilladelse osv. \u2013 alt denne fis st\u00e5r i vejen for praksisser. Fordi hvis der er aktiviteter, der er forbundet som en skat, s\u00e5 bliver alt 100 gange sv\u00e6rere. Derfor vil et skift ofte ikke blive positivt modtaget af alle. Fordi det er sv\u00e6rt at \u00e6ndre folks vaner.<\/em> <\/p>\n<\/p>\n
N\u00e5r en person udf\u00f8rer sit s\u00e6dvanlige arbejde, g\u00f8r han det praktisk talt uden at t\u00e6nke over det. Den kognitive belastning er nul. Han arbejder blot p\u00e5 det f\u00e6rdige, han har allerede en tjekliste i hovedet, han har gjort dette tusind gange. Og s\u00e5 snart du kommer og siger til ham: \u00abLad os opsige denne praksis og fra mandag implementere en ny\u00bb, bliver det en stor kognitiv belastning for ham. Og denne belastning tr\u00e6der straks i kraft for alle.<\/em> <\/p>\n<\/p>\n
Derfor er det enkleste, men sandt, at ikke alle har r\u00e5d til denne luksus, men jeg g\u00f8r det altid s\u00e5dan. Hvis et nyt projekt starter, presses som regel alle uafpr\u00f8vede praksisser ind i dette projekt. Mens projektet stadig er ungt, risikerer vi ikke meget. Der er ingen produktion, der er ikke noget at \u00f8del\u00e6gge. S\u00e5 denne metode kan bruges som tr\u00e6ning. Denne tilgang virker. Men ikke alle virksomheder har mulighed for ofte at starte s\u00e5danne projekter. Selv om det ogs\u00e5 er lidt m\u00e6rkeligt, fordi der er masser af digital transformation lige nu, og alle b\u00f8r eksperimentere for at f\u00f8lge med konkurrenterne.<\/em> <\/p>\n<\/p>\n
Her st\u00f8der man p\u00e5 det faktum, at man f\u00f8rst skal have en forst\u00e5else af, hvad man skal g\u00f8re. Verden er ikke perfekt, produktion er heller ikke perfekt. <\/p>\n
<\/p>\n
Ja, disse ting er indbyrdes forbundet.<\/em><\/p>\n<\/p>\n
Virksomheden har heller ikke altid en forst\u00e5else af, at de skal bev\u00e6ge sig i den retning. <\/p>\n
<\/p>\n
Der er situationer, hvor ingen \u00e6ndringer er mulige overhovedet. Det er en situation, hvor teamet oplever st\u00f8rre pres. Teamet er allerede temmelig udbr\u00e6ndt. De har ikke noget overskud af tid til eksperimenter. De arbejder fra morgen til aften med at udvikle funktioner. Og ledelsen kr\u00e6ver stadig flere funktioner. Der kr\u00e6ves mere og mere. I en s\u00e5dan situation er der overhovedet ikke mulighed for nogen \u00e6ndringer. Teamet kan kun f\u00e5 besked p\u00e5, at i morgen skal vi g\u00f8re som i g\u00e5r, vi skal bare lave lidt flere funktioner. Ingen overgange til nogen praksisser er i denne forstand mulige. Det er en klassisk situation, hvor der ikke er tid til at slibe \u00f8ksen, man skal f\u00e6lde tr\u00e6er, og derfor f\u00e6lder man med en stump \u00f8kse. Her er der ingen nemme l\u00f8sninger.<\/em> <\/p>\n<\/p>\n
(Dmitry) Jeg vil l\u00e6se en pr\u00e6cisering fra chatten: \"Men der er behov for stor testd\u00e6kning p\u00e5 forskellige niveauer. Hvor meget tid bruges der p\u00e5 tests? Det virker lidt dyrt og tager meget tid.\"<\/em><\/p>\n<\/p>\n
(Oleg) Det er en klassisk misforst\u00e5else. Der skal v\u00e6re tilstr\u00e6kkeligt med tests, s\u00e5 du selv har tillid. Continuous Integration er ikke s\u00e5dan noget, hvor 100 % af tests skal v\u00e6re klar, f\u00f8r du begynder at anvende denne praksis. Continuous Integration reducerer din kognitive belastning, fordi hver \u00e6ndring, du kan se, er s\u00e5 \u00e5benlys, at du forst\u00e5r, om den vil bryde noget eller ej, selv uden tests. Du kan hurtigt teste det mentalt, fordi \u00e6ndringerne er sm\u00e5. Selv hvis du kun har manuelle testere, er det ogs\u00e5 lettere for dem. Du ruller det ud og siger: \"Tjek, er der noget, der er brudt?\" De tjekker og siger: \"Nej, der er ikke brudt noget.\" Fordi testeren ved, hvor de skal se. Du har \u00e9n commit, der er relateret til \u00e9t stykke kode. Og det eksploderer med en bestemt opf\u00f8rsel.<\/em><\/p>\n<\/p>\n
Her har du selvf\u00f8lgelig lidt pyntet p\u00e5 det. <\/p>\n
<\/p>\n
(Dmitry) Her er jeg ikke enig. Der findes en praksis \u2013 testdrevet udvikling, som netop kan redde dig fra dette.<\/em> <\/p>\n<\/p>\n
(Oleg) Jeg er ikke n\u00e5et dertil endnu. Den f\u00f8rste illusion er, at man skal skrive 100 % tests eller slet ikke besk\u00e6ftige sig med Continuous Integration. Det er forkert. Det er to parallelle praksisser. Og de afh\u00e6nger ikke direkte af hinanden. Din testd\u00e6kning skal v\u00e6re optimal. Optimal betyder, at du selv er sikker p\u00e5, at den kvalitet, som din master har efter commit, giver dig tillid til at trykke p\u00e5 \"Deploy\"-knappen fredag aften, selv n\u00e5r du er p\u00e5virket. Hvordan n\u00e5r du dertil? Gennem review, gennem d\u00e6kning, gennem god overv\u00e5gning.<\/em> <\/p>\n<\/p>\n
God overv\u00e5gning er ikke til at skelne fra tests. Hvis du k\u00f8rer tests \u00e9n gang p\u00e5 pre prod, s\u00e5 tjekker de alle dine bruger-scenarier \u00e9n gang og s\u00e5 er det det. Men hvis du k\u00f8rer dem i en uendelig l\u00f8kke, er det dit udvidede overv\u00e5gningssystem, der konstant tester \u2013 om systemet er nede eller ej. I dette tilf\u00e6lde er forskellen kun i engangs- eller gentagne tests. Et meget godt s\u00e6t tests\u2026, der k\u00f8res uendeligt, er egentlig overv\u00e5gning. Og korrekt overv\u00e5gning skal v\u00e6re s\u00e5dan.<\/em> <\/p>\n<\/p>\n
Og derfor, hvordan du pr\u00e6cist n\u00e5r til den tilstand, hvor du deployer fredag aften og s\u00e5 g\u00e5r hjem, er et andet sp\u00f8rgsm\u00e5l. M\u00e5ske er du bare en modig skr\u00e6dder.<\/em> <\/p>\n<\/p>\n
Lad os g\u00e5 lidt tilbage til Continuous Integration. Vi er tr\u00e5dt ind i en anden kompleks praksis. <\/p>\n
<\/p>\n
Og den anden illusion er, at MVP'en, det siges, skal laves hurtigt, og derfor er tests slet ikke n\u00f8dvendige. Det er ikke helt korrekt. N\u00e5r du skriver user stories til din MVP, kan du lave dem enten p\u00e5 en impulsiv m\u00e5de, dvs. h\u00f8re om en user story og straks begynde at kode den, eller arbejde efter TDD. Og if\u00f8lge erfaringerne fra TDD tager det ikke l\u00e6ngere tid, s\u00e5 tests er bare et biprodukt. TDC-praksis handler ikke om at teste. Selvom det kaldes Test Driven Development, omhandler det slet ikke tests. Det er snarere en arkitektonisk tilgang. Det handler om, hvordan man skriver det, der er n\u00f8dvendigt, og ikke skriver det, der ikke er n\u00f8dvendigt. Denne praksis fokuserer p\u00e5 den n\u00e6ste iteration af din tankegang i forhold til at skabe appens arkitektur.<\/em> <\/p>\n<\/p>\n
Derfor er det ikke s\u00e5 let at slippe af med disse illusioner. MVP og tests mods\u00e6tter ikke hinanden. Tv\u00e6rtimod, hvis du laver din MVP efter TDD-praksis, vil du g\u00f8re det bedre og hurtigere, end hvis du g\u00f8r det uden praksis, p\u00e5 impuls.<\/em><\/p>\n<\/p>\n
Det er en meget uheldig og kompleks tanke. N\u00e5r du h\u00f8rer, at jeg nu ogs\u00e5 skal skrive tests og alligevel vil g\u00f8re noget hurtigere, lyder det helt usandsynligt. <\/p>\n
<\/p>\n
(Dmitry) Mange, n\u00e5r de taler om MVP, er bare for dovne til at skrive noget ordentligt. Og det er trods alt forskellige ting. Man skal ikke g\u00f8re MVP til noget d\u00e5rligt, der ikke fungerer.<\/em> <\/p>\n<\/p>\n
Ja, du har ret.<\/p>\n
<\/p>\n
Og s\u00e5 pludselig MVP i produktion.<\/em><\/p>\n<\/p>\n
For altid. <\/p>\n
<\/p>\n
Og TDD lyder meget uvant, n\u00e5r man h\u00f8rer, at du skriver tests, og tilsyneladende laver mere arbejde. Det lyder meget m\u00e6rkeligt, men i virkeligheden g\u00e5r det hurtigere og ser bedre ud. N\u00e5r du skriver en test, t\u00e6nker du allerede meget over, hvilken kode der skal bruges, hvordan den vil blive kaldt, og hvilken adf\u00e6rd vi forventer af den. Du siger ikke bare, at jeg har skrevet en funktion, og den g\u00f8r noget. Du overvejer f\u00f8rst, hvilke betingelser den har, og hvordan den vil blive kaldt. Du d\u00e6kker det med tests, og ud fra dette forst\u00e5r du, hvordan dine interfaces i koden vil se ud. Det har en stor indflydelse p\u00e5 arkitekturen. Din kode bliver automatisk mere modul\u00e6r, fordi du f\u00f8rst pr\u00f8ver at forst\u00e5, hvordan du vil teste den, og f\u00f8rst derefter skriver du den. <\/p>\n
<\/p>\n
Jeg har haft det s\u00e5dan med TDD, at jeg p\u00e5 et tidspunkt hyrede en mentor til Ruby, da jeg stadig var Ruby-udvikler. Og han sagde: \u201eLad os g\u00f8re det med TDD.\u201d Jeg t\u00e6nkte: \u201e\u00c5h nej, skal jeg skrive noget ekstra.\u201d Vi blev enige om, at jeg i l\u00f8bet af to uger skulle skrive al min funktionelle kode p\u00e5 Python med TDD. Efter to uger inds\u00e5 jeg, at jeg ikke ville tilbage. Efter at have fors\u00f8gt at anvende det overalt i to uger, forst\u00e5r man, hvor meget lettere det er at t\u00e6nke klart. Men det er ikke indlysende, s\u00e5 jeg anbefaler alle, at hvis I f\u00f8ler, at TDD er kompliceret, tidskr\u00e6vende og un\u00f8dvendigt, s\u00e5 pr\u00f8v at holde fast i det i bare to uger. To uger var tilstr\u00e6kkeligt for mig.<\/p>\n
<\/p>\n
(Dmitrij) Vi kan udfolde denne tanke fra et perspektiv af infrastrukturdrift. F\u00f8r vi starter noget nyt, udf\u00f8rer vi overv\u00e5gning og derefter lancerer vi. I dette tilf\u00e6lde bliver vores overv\u00e5gning en normal testning. Og der er udvikling gennem overv\u00e5gning. Men n\u00e6sten alle siger, at det er tidskr\u00e6vende, jeg orker ikke det, jeg lavede et midlertidigt udkast. Hvis vi udf\u00f8rer overv\u00e5gningen ordentligt, forst\u00e5r vi tilstanden af CI-systemet. Og der er meget overv\u00e5gning i CI-systemet. Vi forst\u00e5r systemets tilstand, vi forst\u00e5r, hvad der foreg\u00e5r inden i det. Og under udviklingen laver vi netop systemet, s\u00e5 det n\u00e5r den \u00f8nskede tilstand.<\/em> <\/p>\n<\/p>\n
Disse praksisser har v\u00e6ret kendt i lang tid. Vi diskuterede det for omkring 4 \u00e5r siden. Men p\u00e5 de 4 \u00e5r er der n\u00e6sten ikke sket nogen forandringer.<\/em> <\/p>\n<\/p>\n
Men p\u00e5 denne note vil jeg foresl\u00e5, at vi afslutter den officielle diskussion.<\/em><\/p>\n<\/p>\n
Video (indsat som et medieelement, men af en eller anden grund fungerer det ikke):<\/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
![\"Continuous](\"\/wp-content\/uploads\/2020\/09\/ed8a32ae63b8dccfc8b4893ab27f1527.jpg\")
<\/p>\n