Laten we bespreken waarom CI-tools en CI totaal verschillende dingen zijn.
Welke pijn moet CI oplossen, waar komt het idee vandaan, wat zijn de laatste bevestigingen dat het werkt, hoe kun je begrijpen dat je een praktijk hebt en niet alleen Jenkins hebt geïnstalleerd.
Het idee om een reportage te maken over Continuous Integration ontstond een jaar geleden, toen ik op sollicitatiegesprek ging en op zoek was naar een baan. Ik heb met 10 tot 15 bedrijven gesproken, maar slechts één van hen kon duidelijk antwoorden wat CI is en uitleggen hoe ze zich realiseerden dat ze het niet hadden. De rest praatte onverstaanbare onzin over Jenkins :) Nou, we hebben Jenkins, het bouwt wel, CI! Tijdens het rapport zal ik proberen uit te leggen wat Continuous Integration eigenlijk is en waarom Jenkins en soortgelijke tools hier een zeer zwakke relatie mee hebben.
Wat komt er meestal in je op als je het woord CI hoort? De meeste mensen zullen denken aan Jenkins, Gitlab CI, Travis, etc.
Zelfs als we het googlen, levert het ons deze hulpmiddelen op.
Als je bekend bent met vragen, zullen ze je onmiddellijk na het opsommen van de tools vertellen dat CI is wanneer je tests bouwt en uitvoert in een Pull Request voor een commit.
Bij Continuous Integration gaat het niet om tools, niet om assemblages met tests in een branch! Continue integratie is de praktijk van zeer frequente integratie van nieuwe code en om deze te gebruiken is het helemaal niet nodig om Jenkins, GitLab, enz. af te schermen.
Voordat we uitzoeken hoe een volwaardige CI eruit ziet, duiken we eerst in de context van de mensen die het bedacht hebben en voelen we de pijn die ze probeerden op te lossen.
En ze hebben de pijn van het samenwerken als team opgelost!
Laten we eens kijken naar voorbeelden van de moeilijkheden waarmee ontwikkelaars worden geconfronteerd bij het ontwikkelen in teams. Hier hebben we een project, een masterbranch in git en twee ontwikkelaars.
En ze gingen aan het werk zoals iedereen al lang gewend was. We namen een taak in het grote geheel, creëerden een feature branch en schreven de code.
Eén voltooide de functie sneller en voegde deze samen met de master.
De tweede had meer tijd nodig, fuseerde later en eindigde met een conflict. In plaats van de functies te schrijven die het bedrijf nodig heeft, besteedt de ontwikkelaar nu zijn tijd en energie aan het oplossen van conflicten.
Hoe moeilijker het is om uw functie te combineren met een gemeenschappelijke master, hoe meer tijd we eraan besteden. En ik liet dit zien met een vrij eenvoudig voorbeeld. Dit is een voorbeeld waarbij er slechts twee ontwikkelaars zijn. Stel je voor dat 2, 10 of 15 mensen in een bedrijf naar één repository schrijven. Je zult gek worden als je al deze conflicten oplost.
Er is een iets ander geval. We hebben een master en een paar ontwikkelaars die iets doen.
Ze hebben een takje gemaakt.
Eén stierf, alles was in orde, hij slaagde voor de taak.
De tweede ontwikkelaar heeft inmiddels zijn taak ingeleverd. Stel dat hij het ter beoordeling heeft verzonden. Veel bedrijven hebben een praktijk die beoordeling wordt genoemd. Aan de ene kant is deze praktijk goed en nuttig, aan de andere kant vertraagt het ons in veel opzichten. We zullen daar niet op ingaan, maar hier is een goed voorbeeld van waar een slecht recensieverhaal toe kan leiden. U heeft een pull-verzoek ter beoordeling ingediend. De ontwikkelaar hoeft niets meer te doen. Wat begint hij te doen? Hij begint andere taken op zich te nemen.
Gedurende deze tijd deed de tweede ontwikkelaar iets anders.
De eerste voltooide de derde taak.
En na een lange tijd werd zijn recensie getest en probeert hij tot overeenstemming te komen. Dus wat is er aan de hand? Het vangt een groot aantal conflicten op. Waarom? Want terwijl zijn pull-request in de review hing, waren er al veel dingen veranderd in de code.
Naast het verhaal met conflicten is er een verhaal met communicatie. Terwijl uw draad ter beoordeling hangt, terwijl deze ergens op wacht, terwijl u lange tijd aan een functie werkt, houdt u op met bijhouden wat er nog meer verandert in de codebasis van uw service. Misschien is wat je nu probeert op te lossen gisteren al opgelost en kun je een methode gebruiken en deze opnieuw gebruiken. Maar dit zie je niet omdat je altijd met een verouderde branch werkt. En deze verouderde branch zorgt er altijd voor dat je een merge-conflict moet oplossen.
Het blijkt dat als we als team werken, d.w.z. niet één persoon rondsnuffelt in de repository, maar vijf tot tien mensen, hoe langer we onze code niet aan de master toevoegen, hoe meer we lijden omdat we uiteindelijk iets en voeg het dan samen. En hoe meer conflicten we hebben, en hoe oudere versies we gebruiken, hoe meer problemen we hebben.
Samen iets doen is pijnlijk! Wij zitten elkaar altijd in de weg.
Dit probleem werd meer dan 20 jaar geleden opgemerkt. Ik vond de eerste vermelding van de praktijk van continue integratie in Extreme Programming.
Extreme Programming is het eerste agile raamwerk. De pagina verscheen in 96. En het idee was om een soort programmeerpraktijk, planning en andere dingen te gebruiken, zodat de ontwikkeling zo flexibel mogelijk zou zijn, zodat we snel konden reageren op eventuele veranderingen of vereisten van onze klanten. En ze begonnen dit 24 jaar geleden onder ogen te zien, dat als je iets heel lang en aan de zijlijn doet, je er meer tijd aan besteedt omdat je conflicten hebt.
Nu zullen we de uitdrukking “Continu Integratie” individueel analyseren. Als we het rechtstreeks vertalen, krijgen we een continue integratie. Maar hoe continu het is, is niet erg duidelijk; het is zeer discontinu. Maar hoeveel integratie het heeft, is ook niet erg duidelijk.
En daarom geef ik je nu citaten van Extreme Programming. En we zullen beide woorden afzonderlijk analyseren.
Integratie - Zoals ik al zei, streven we ernaar om ervoor te zorgen dat elke engineer met de meest actuele versie van de code werkt, zodat hij ernaar streeft zijn code zo vaak mogelijk toe te voegen aan een gemeenschappelijke branch, zodat dit kleine branches zijn. Want als ze groot zijn, kunnen we gemakkelijk een week lang met fusieconflicten blijven zitten. Dit is vooral het geval als we een lange ontwikkelingscyclus hebben, zoals een waterval, waarbij de ontwikkelaar een maand weg ging om een grote feature te maken. En hij zal heel lang in de integratiefase blijven steken.
Integratie is wanneer we onze branch nemen en deze integreren met de master, we mergen deze. Er is een ultieme optie als we een transbase-ontwikkelaar zijn, waarbij we ernaar streven om ervoor te zorgen dat we onmiddellijk naar de master schrijven zonder extra vertakkingen.
Over het algemeen betekent integratie dat u uw code naar de master sleept.
Wat wordt hier bedoeld met het woord “continu”, wat continuïteit wordt genoemd? De praktijk houdt in dat de ontwikkelaar ernaar streeft zijn code zo snel mogelijk te integreren. Dit is zijn doel bij het uitvoeren van welke taak dan ook: zijn code zo snel mogelijk in de master laten verschijnen. In een ideale wereld zouden ontwikkelaars dit om de paar uur doen. Dat wil zeggen, je neemt een klein probleem en voegt het samen in de master. Alles is geweldig. Dit is waar je naar streeft. En dit moet continu gebeuren. Zodra je iets doet, stop je het meteen in de master.
En de ontwikkelaar die iets maakt, is verantwoordelijk voor wat hij heeft gedaan om het te laten werken en niets kapot te maken. Dit is waar het testverhaal meestal naar voren komt. We willen een aantal tests uitvoeren op onze commit, op onze merge, om er zeker van te zijn dat deze werkt. En dit is waar Jenkins u kan helpen.
Maar met verhalen: laten we de veranderingen klein maken, laten we de taken klein laten, laten we een probleem maken en onmiddellijk proberen het op de een of andere manier in de meester in te bedden - geen Jenkins zal hier helpen. Omdat Jenkins je alleen helpt bij het uitvoeren van tests.
Je kunt het zonder hen doen. Dit zal je helemaal geen pijn doen. Omdat het doel van de praktijk is om zo vaak mogelijk te meten, om in de toekomst niet veel tijd te verspillen aan eventuele conflicten.
Laten we ons voorstellen dat we om de een of andere reden in 2020 zonder internet zitten. En we werken lokaal. Wij hebben geen Jenkins. Dit is goed. U kunt nog steeds doorgaan en een lokale afdeling maken. Je hebt er wat code in geschreven. We voltooiden de taak in 3-4 uur. We zijn overgestapt naar master, hebben een git pull gedaan en onze branch daar samengevoegd. Klaar. Als je dit vaak doet, gefeliciteerd, dan heb je Continuous Integration!
Welk bewijs in de moderne wereld is er dat het de moeite waard is om energie aan te besteden? Omdat het over het algemeen moeilijk is. Als je op deze manier probeert te werken, zul je begrijpen dat een deel van de planning nu wordt beïnvloed, je zult meer tijd moeten besteden aan het ontbinden van taken. Want als je dat doet, man..., dan zul je niet snel tot overeenstemming kunnen komen en zul je dus in de problemen komen. Je zult geen praktijk meer hebben.
En het zal duur zijn. Vanaf morgen is het niet meer mogelijk om met Continuous Integration te werken. Het zal heel lang duren voordat jullie eraan gewend zijn, het zal heel lang duren voordat jullie gewend zijn aan het ontbinden van taken, het zal heel lang duren om gewend te raken aan het opnieuw uitvoeren van de beoordelingspraktijk, als je die hebt . Omdat het ons doel is om het vandaag te laten smelten. En doe je binnen drie dagen een review, dan heb je problemen en werkt Continuous Integration niet voor jou.
Maar hebben we op dit moment enig relevant bewijsmateriaal dat ons vertelt dat investeren in deze praktijk zinvol is?
Het eerste waar ik aan dacht was State of DevOps. Dit is een onderzoek dat de jongens al 7 jaar uitvoeren. Nu doen ze het als onafhankelijke organisatie, maar dan onder Google.
En hun onderzoek uit 2018 toonde een verband aan tussen bedrijven die proberen kortlevende vestigingen te gebruiken die snel integreren, vaak integreren en betere IT-prestatie-indicatoren hebben.
Wat zijn deze indicatoren? Dit zijn vier maatstaven die ze van alle bedrijven gebruiken in hun vragenlijsten: implementatiefrequentie, doorlooptijd voor wijzigingen, tijd om de service te herstellen, aantal mislukte wijzigingen.
En in de eerste plaats is er deze correlatie: we weten dat bedrijven die regelmatig meten, veel betere statistieken hebben. En ze hebben bedrijven onderverdeeld in verschillende categorieën: dit zijn langzame bedrijven die iets langzaam produceren, medium performer, high performer en elite. De elite zijn Netflix en Amazon, die supersnel zijn, alles snel, mooi en efficiënt doen.
Het tweede verhaal, dat nog maar een maand geleden plaatsvond. Technology Radar heeft een geweldig artikel over Gitflow. Gitflow verschilt van alle anderen doordat de takken een lange levensduur hebben. Er zijn releasetakken die lang meegaan, en featuretakken die ook lang leven. Deze praktijk bij Technology Radar is verhuisd naar HOLD. Waarom? Omdat mensen geconfronteerd worden met de pijn van integratie.
Als je tak heel lang meegaat, loopt hij vast, gaat rotten en gaan we meer tijd besteden aan het proberen er een of andere verandering in aan te brengen.
En onlangs zei de auteur van Gitflow dat als je doel continue integratie is, als je doel is dat je zo vaak mogelijk wilt rollen, Gitflow een slecht idee is. Hij voegde apart aan het artikel toe dat als je een backend hebt waar je dit naar kunt streven, dan is Gitflow voor jou overbodig, want Gitflow vertraagt je, Gitflow zorgt voor problemen met de integratie voor je.
Dit betekent niet dat Gitflow slecht is en niet gebruikt mag worden. Het is voor andere gelegenheden. Bijvoorbeeld wanneer u meerdere versies van een dienst of applicatie moet ondersteunen, dat wil zeggen wanneer u gedurende langere tijd ondersteuning nodig heeft.
Maar als je praat met mensen die dergelijke diensten ondersteunen, zul je veel pijn horen over het feit dat deze versie 3.2 was, wat 4 maanden geleden was, maar deze oplossing was er niet in opgenomen en nu, om het te maken, je moet een aantal wijzigingen aanbrengen. En nu zitten ze weer vast, en nu zijn ze al een week aan het rommelen met het implementeren van een nieuwe functie.
Zoals Alexander Kovalev terecht opmerkte in de chat, is correlatie niet hetzelfde als causaliteit. Dit is waar. Dat wil zeggen, er is geen direct verband dat als u Continuous Integration heeft, alle statistieken geweldig zullen zijn. Maar er is een positieve correlatie: als de één het één is, dan is de ander hoogstwaarschijnlijk dat ook. Geen feit, maar hoogstwaarschijnlijk. Het is slechts een correlatie.
Het lijkt erop dat we al iets doen, het lijkt erop dat we al aan het fuseren zijn, maar hoe kunnen we begrijpen dat we nog steeds Continue Integratie hebben, dat we heel vaak fuseren?
Jez Humble is de auteur van Handbook, Accelerate, de Continuous Delivery-website en het boek Continuous Delivery. Hij biedt deze test aan:
- De ingenieurscode komt elke dag bij de master terecht.
- Voor elke commit voer je unit tests uit.
- De inbouw in de master viel weg en was in ongeveer 10 minuten gerepareerd.
Hij stelt voor om een test als deze te gebruiken om er zeker van te zijn dat je voldoende oefent.
Dat laatste vind ik een beetje controversieel. Dat wil zeggen, als je het binnen 10 minuten kunt repareren, dan heb je continue integratie. Het klinkt naar mijn mening een beetje vreemd, maar het is logisch. Waarom? Want als je vaak bevriest, betekent dit dat je veranderingen klein zijn. Als een kleine verandering betekent dat uw masterbuild kapot is, kunt u snel een voorbeeld vinden omdat de verandering klein is. Hier had je een kleine samenvoeging, er veranderden 20-30 regels in. En dienovereenkomstig kun je snel begrijpen wat de reden was, omdat de veranderingen klein zijn, je een heel klein gebied hebt om naar het probleem te zoeken.
En zelfs als ons product na de release uit elkaar valt, is het veel gemakkelijker voor ons om actie te ondernemen als we de praktijk van Continuous Integration beoefenen, omdat de veranderingen klein zijn. Ja, dit heeft gevolgen voor de planning. Dit zal pijn doen. En waarschijnlijk is het moeilijkste in deze praktijk om te wennen aan het opsplitsen van taken, dat wil zeggen: hoe je het moet doen, zodat je iets kunt doen en het binnen een paar uur kunt doen en tegelijkertijd een beoordeling kunt doorstaan, als jij hebt er een. Recensie is een aparte pijn.
Unit-tests zijn slechts een hulpmiddel dat u helpt te begrijpen of uw integratie succesvol is geweest en of er niets kapot is gegaan. Naar mijn mening is dit ook niet geheel verplicht, omdat dit niet de praktijk is.
Dit is een korte introductie tot continue integratie. Dat is alles wat deze praktijk te bieden heeft. Ik ben klaar voor vragen.
Ik vat het nog een keer kort samen:
- Continue integratie is niet Jenkins, het is niet Gitlab.
- Dit is geen hulpmiddel, het is een praktijk waarbij we onze code zo vaak mogelijk in de master samenvoegen.
- We doen dit om de enorme pijn te vermijden die ontstaat bij fusies in de toekomst, dat wil zeggen dat we nu een beetje pijn ervaren om in de toekomst niet meer te ervaren. Dat is het hele punt.
- Aan de zijkant is er communicatie via code, maar ik zie dit zelden, maar dit is ook waarvoor het is ontworpen.
vragen
Wat te doen met niet-ontbonden taken?
Ontleden. Wat is het probleem? Kun je een voorbeeld geven dat er een taak is en deze niet is ontleed?
Er zijn taken die niet kunnen worden ontleed uit het woord ‘volledig’, bijvoorbeeld taken die een zeer diepgaande expertise vereisen en die feitelijk in de loop van een maand kunnen worden opgelost om een verteerbaar resultaat te bereiken.
Als ik je goed begrijp, is er dan een grote en complexe taak waarvan het resultaat pas over een maand zichtbaar zal zijn?
Ja dat klopt. Ja, het resultaat kan niet eerder dan over een maand worden geëvalueerd.
Prima. Over het algemeen is dit geen probleem. Waarom? Want als we het in dit geval over twijgen hebben, hebben we het niet over een takje met een kenmerk. Functies kunnen groot en complex zijn. Ze kunnen een groot aantal componenten beïnvloeden. En misschien kunnen we ze niet helemaal in één branche doen. Dit is goed. We moeten dit verhaal gewoon ontrafelen. Als een feature nog niet helemaal klaar is, betekent dit niet dat sommige delen van de code niet kunnen worden samengevoegd. Je hebt bijvoorbeeld migratie toegevoegd en er zijn enkele fasen in de functie. Laten we zeggen dat je een fase hebt: voer een migratie uit, voeg een nieuwe methode toe. En deze dingen kun je nu al elke dag meten.
Prima. Wat is het punt dan?
Wat heeft het voor zin om elke dag kleine dingen te doden?
Да.
Als ze iets kapot maken, zie je het meteen. Je hebt een klein stukje dat iets gebroken heeft, het is gemakkelijker voor je om het te repareren. Het punt is dat het nu veel gemakkelijker is om een klein stukje samen te voegen dan iets groots over een paar weken. En het derde punt is dat andere ingenieurs met de huidige versie van de code zullen werken. Ze zullen zien dat hier enkele migraties zijn toegevoegd, en dan is er een methode verschenen die ze misschien ook willen gebruiken. Iedereen zal zien wat er in uw code gebeurt. Voor deze drie dingen wordt geoefend.
Bedankt, het probleem is gesloten!
(Oleg Soroka) Mag ik toevoegen? Je hebt alles correct gezegd, ik wil slechts één zin toevoegen.
Так.
Met Continuous Integration wordt de code samengevoegd in een gemeenschappelijke vertakking, niet wanneer de functie volledig gereed is, maar wanneer de build niet meer kapot gaat. En je kunt je veilig inzetten om het zo vaak per dag onder de knie te krijgen als je wilt. Het tweede aspect is dat als je om de een of andere reden de maandelijkse taak niet gedurende minstens drie dagen in taken kunt opsplitsen, ik zwijg ongeveer drie uur, dan heb je een enorm probleem. En het feit dat u geen Continuous Integration heeft, is het minste van deze problemen. Dit betekent dat je problemen hebt met architectuur en nul-engineeringpraktijken. Want ook al is het onderzoek, dan moet het in ieder geval geformuleerd worden in de vorm van hypothesen of een cyclus.
We hadden het over vier maatstaven die succesvolle bedrijven onderscheiden van achterblijvende bedrijven. We moeten nog leven om deze 4 statistieken te zien. Als het een maand duurt om uw gemiddelde taak te voltooien, zou ik me eerst op deze statistiek concentreren. Ik zou het eerst verlagen naar 4 dagen. En daarna begon ik na te denken over Continu.
Heb ik u goed begrepen dat u denkt dat het over het algemeen geen zin heeft om in technische praktijken te investeren als een taak een maand in beslag neemt?
U beschikt over continue integratie. En er is zo'n onderwerp dat je binnen 10 minuten een oplossing kunt repareren of terugdraaien. Stel je voor dat je het uitrolt. Bovendien heb je zelfs continue inzet, je hebt het uitgerold naar prod en merkte toen pas dat er iets mis ging. En u moet het terugdraaien, maar u hebt uw database al gemigreerd. Je hebt al het databaseschema van de volgende versie, bovendien had je ook een soort back-up en werden de gegevens daar ook geschreven.
En welk alternatief heb je? Als u de code terugdraait, kan deze niet meer werken met deze bijgewerkte database.
De basis gaat alleen maar vooruit, ja.
Mensen met slechte technische praktijken hebben het dikke boek over... waarschijnlijk ook niet gelezen. Wat te doen met de back-up? Als u herstelt vanaf een back-up, betekent dit dat u de gegevens kwijtraakt die u op dat moment heeft verzameld. We hebben bijvoorbeeld drie uur gewerkt met de nieuwe versie van de database, gebruikers registreerden zich daar. U weigert de oude back-up omdat het schema niet werkt met de nieuwe versie, waardoor u deze gebruikers kwijt bent. En ze zijn ontevreden, zweren ze.
Om het volledige scala aan praktijken die Continuous Integration en Continuous Delivery ondersteunen onder de knie te krijgen, is het niet voldoende om alleen maar te leren schrijven. Ten eerste kunnen er veel zijn, het zal onpraktisch zijn. Bovendien zijn er nog een heleboel andere praktijken, zoals Scientific. Er bestaat zo'n praktijk, GitHub heeft het ooit gepopulariseerd. Dit is wanneer zowel de oude als de nieuwe code tegelijkertijd worden uitgevoerd. Dit is wanneer je een onvoltooide feature maakt, maar deze kan een bepaalde waarde retourneren: als functie of als Rest API. Je voert zowel de nieuwe code als de oude code uit en vergelijkt het verschil daartussen. En als er een verschil is, logt u deze gebeurtenis. Op deze manier weet je dat je een nieuwe functie klaar hebt staan om bovenop de oude uit te rollen als je al een bepaalde tijd geen discrepantie tussen de twee hebt gehad.
Er zijn honderden van dergelijke praktijken. Ik zou willen voorstellen om te beginnen met transbase-ontwikkeling. Ze staat niet 100% achter Continuous Integration, maar de praktijken zijn hetzelfde, de een kan niet goed zonder de ander.
Heb je transbase-ontwikkeling als voorbeeld gegeven waar je praktijken kunt zien of stel je voor dat mensen transbase-debelopment gaan gebruiken?
Kijk maar eens, want ze kunnen het niet gebruiken. Om ze te kunnen gebruiken, moet je veel lezen. En als iemand vraagt: “Wat te doen met een functie die een maand in beslag neemt, betekent dit dat hij niet heeft gelezen over transbase-ontwikkeling.” Ik zou het nog niet aanraden. Ik zou adviseren om je uitsluitend te concentreren op het onderwerp hoe je grote taken architectonisch correct in kleinere taken kunt opsplitsen. Dit is de essentie van ontbinding.
Ontleding is een van de instrumenten van de architect. We doen eerst analyse, dan ontleding, dan synthese, dan integratie. En zo verloopt alles voor ons. En we moeten nog steeds doorgroeien naar continue integratie door middel van ontbinding. Er rijzen vragen in de eerste fase, en we hebben het al over de vierde fase, d.w.z. hoe vaker we aan integratie doen, hoe beter. Het is nog te vroeg om dit te doen; het zou leuk zijn om eerst je monoliet om te hakken.
U moet een aantal pijlen en vierkanten op een diagram tekenen. Je kunt niet zeggen dat ik nu het architectuurdiagram van een nieuwe applicatie zal laten zien en één vierkant zal laten zien, waarbinnen een groene knop voor de applicatie staat. Er komen in ieder geval meer vierkanten en pijlen. Elk diagram dat ik zag had er meer dan één. En decompositie, zelfs op het niveau van grafische representatie, vindt al plaats. Daarom kunnen de vierkanten onafhankelijk worden gemaakt. Zo niet, dan heb ik grote vragen voor de architect.
Er komt een vraag uit de chat: “Als een review verplicht is en lang duurt, misschien een dag of langer?”
Je hebt problemen met oefenen. De beoordeling mag niet een dag of langer duren. Dit is hetzelfde verhaal als de vorige vraag, alleen iets zachter. Als een recensie een dag duurt, dan is er hoogstwaarschijnlijk sprake van een hele grote verandering. Dit betekent dat het kleiner gemaakt moet worden. Bij transbase-ontwikkeling, die Oleg aanbeveelde, is er een verhaal dat continue beoordeling wordt genoemd. Haar idee is dat we expres zo'n klein pull-verzoek doen, omdat we ernaar streven om voortdurend en beetje bij beetje samen te voegen. En dus verandert het pull-verzoek één abstractie of 10 regels. Dankzij deze review kost het ons een paar minuten.
Als de beoordeling een dag of langer duurt, is er iets mis. Ten eerste heb je mogelijk wat problemen met de architectuur. Of dit is een groot stuk code, bijvoorbeeld 1 regels. Of uw architectuur is zo complex dat iemand het niet kan begrijpen. Dit is een enigszins zijwaarts probleem, maar het zal ook opgelost moeten worden. Misschien is een herziening helemaal niet nodig. Wij moeten hier ook over nadenken. Recensie is datgene wat je vertraagt. Het heeft over het algemeen zijn voordelen, maar je moet begrijpen waarom je het doet. Is dit een manier voor u om snel informatie over te brengen, is dit een manier voor u om intern een aantal normen te stellen of zo? Waarom heb je dit nodig? Omdat de beoordeling óf heel snel moet gebeuren, óf helemaal moet worden geannuleerd. Het is net als transbase-ontwikkeling: het verhaal is heel mooi, maar alleen voor volwassen jongens.
Wat de vier statistieken betreft, zou ik nog steeds aanraden deze te verwijderen om te begrijpen waar dit toe leidt. Kijk naar de cijfers, kijk naar de foto, hoe erg alles is.
(Dmitry) Ik ben bereid hierover met u in discussie te gaan. Cijfers en statistieken zijn allemaal geweldig, de praktijk is geweldig. Maar u moet begrijpen of het bedrijf het nodig heeft. Er zijn bedrijven die zo’n snelheid van verandering niet nodig hebben. Ik ken bedrijven waar niet ieder kwartier wijzigingen doorgevoerd kunnen worden. En niet omdat ze zo slecht zijn. Dit is zo’n levenscyclus. En om de vertakkingen te laten functioneren, de schakelfunctie, heb je diepgaande kennis nodig.
Het is gecompliceerd. Als je het verhaal over de schakelfunctie in meer detail wilt lezen, raad ik je dit ten zeerste aan . En er is een prachtig artikel van Martin Fowler over toggle-functies: welke soorten er zijn, levenscycli, enz. De toggle-functie is ingewikkeld.
En je hebt nog steeds geen antwoord gegeven op de vraag: “Is Jenkins nodig of niet?”
Jenkins is in ieder geval niet echt nodig. Maar serieus, de tools: Jenkins, Gitlab zullen je gemak bieden. U zult zien dat het geheel gemonteerd of niet gemonteerd is. Ze kunnen je helpen, maar ze geven je geen oefening. Ze kunnen je alleen een cirkel geven - Ok, niet Ok. En als je dan ook nog testen schrijft, want als die er niet zijn, dan heeft het vrijwel geen zin. Daarom is het nodig omdat het handiger is, maar over het algemeen kun je zonder leven, je verliest niet veel.
Dat wil zeggen: als je praktijken hebt, betekent dat dan dat je het niet nodig hebt?
Dat is juist. Ik raad de Jez Humble-test aan. Wat dat laatste betreft heb ik een ambivalente houding. Maar over het algemeen geldt dat als je drie dingen hebt, je constant merget, je tests uitvoert op commits in de master, je de build snel repareert in de master, en dan heb je misschien niets anders nodig.
Terwijl we wachten op vragen van deelnemers, heb ik een vraag. We hadden het net over de productcode. Heb je het gebruikt voor infrastructuurcode? Is het dezelfde code, heeft het dezelfde principes en dezelfde levenscyclus, of zijn er verschillende levenscycli en principes? Als iedereen het heeft over continue integratie en ontwikkeling, vergeet iedereen meestal dat er ook infrastructuurcode bestaat. En de laatste tijd is dat steeds meer het geval. En moeten al deze regels daar gebracht worden?
Zelfs niet dat het zo zou moeten zijn, het zou geweldig zijn omdat het het leven op dezelfde manier gemakkelijker zou maken. Zodra we met code werken, niet met bash-scripts, maar met normale code.
Stop, stop, een bash-script is ook code. Raak mijn oude liefde niet aan.
Oké, ik zal je herinneringen niet vertrappen. Ik heb een persoonlijke hekel aan bash. Het breekt de hele tijd lelijk en eng. En het breekt vaak onvoorspelbaar, daarom vind ik het niet leuk. Maar oké, laten we zeggen dat je bash-code hebt. Misschien begrijp ik het echt niet en zijn er normale testframeworks beschikbaar. Ik ben gewoon niet op de hoogte. En we krijgen dezelfde voordelen.
Zodra we met infrastructuur als code werken, krijgen we allemaal dezelfde problemen als ontwikkelaars. Een paar maanden geleden kwam ik een situatie tegen waarin een collega mij een pull-verzoek stuurde voor 1 regels in bash. En je blijft 000 uur bij de recensie hangen. Er doen zich dezelfde problemen voor. Het is nog steeds code. En het is nog steeds een samenwerking. We lopen vast met het pull-verzoek en we komen vast te zitten met het feit dat we bijvoorbeeld dezelfde merge-conflicten in dezelfde bash oplossen.
Ik ben nu heel actief bezig met dit hele gedoe over de mooiste infraprogrammering. Ik heb Pulumi nu in de infrastructuur gebracht. Dit is programmeren in zijn puurste vorm. Daar is het nog leuker, omdat ik alle mogelijkheden van een programmeertaal heb, d.w.z. ik heb uit het niets een mooie schakelaar gemaakt met dezelfde ifs en alles is in orde. Dat wil zeggen, mijn wisselgeld zit al in de master. Iedereen kan hem al zien. Andere ingenieurs weten ervan. Daar heeft het al iets beïnvloed. Het was echter niet voor alle infrastructuren ingeschakeld. Het ging bijvoorbeeld aan voor mijn testbanken. Daarom is het noodzakelijk om uw vraag nogmaals te beantwoorden. Het maakt het leven voor ons, als ingenieurs die met code werken, op dezelfde manier gemakkelijker.
Mocht iemand nog vragen hebben?
Ik heb een vraag. Ik wil de discussie met Oleg voortzetten. Over het algemeen denk ik dat je gelijk hebt: als een taak een maand in beslag neemt, dan heb je een probleem met architectuur, een probleem met analyse, ontleding, planning, enz. Maar ik heb het gevoel dat als je begint Als je probeert te leven volgens Continuous Integration, dan begin je de pijn te corrigeren met planning, omdat je er nergens anders aan ontkomt.
(Oleg) Ja, dat klopt. Deze praktijk is qua inspanning vergelijkbaar met elke andere serieuze cultuurveranderende praktijk. Het moeilijkste om te overwinnen zijn gewoonten, vooral slechte gewoonten. En als om deze praktijk te implementeren een serieuze verandering in de gewoonten van de mensen om u heen nodig is: ontwikkelaars, management, productiemanager, dan wachten er verrassingen op u.
Welke verrassingen kunnen er zijn? Stel dat u besluit vaker te gaan inburgeren. En je hebt nog een aantal andere dingen die verband houden met integratie, bijvoorbeeld artefacten. En in uw bedrijf bestaat er bijvoorbeeld het beleid dat elk artefact op de een of andere manier moet worden verwerkt in een soort artefactopslagsysteem. En het kost wat tijd. Iemand moet het vakje aanvinken dat hij, als releasemanager, dit artefact heeft getest om er zeker van te zijn dat het klaar is voor release in productie. Als het 5-10-15 minuten duurt, maar je doet de opmaak één keer per week, dan is een half uur per week een kleine belasting.
Als u 10 keer per dag Continuous Integration uitvoert, moet 10 keer worden vermenigvuldigd met 30 minuten. En dit overschrijdt de hoeveelheid werktijd van deze releasemanager. Hij wordt er gewoon moe van om het te doen. Voor sommige praktijken gelden vaste kosten. Dat is alles.
En je moet deze regel annuleren, zodat je niet langer zulke rotzooi doet, dat wil zeggen dat je niet handmatig een graad toewijst die ergens mee correspondeert. U vertrouwt volledig op een aantal geautomatiseerde gereedheidstests.
En als je bewijs van iemand nodig hebt, zodat de baas het ondertekent, en je niet in productie gaat zonder dat Vasya zegt dat hij het toestaat, enz. - al deze onzin staat de beoefenaar in de weg. Want als er bepaalde activiteiten aan een belasting verbonden zijn, wordt alles honderd keer groter. Daarom zal de verschuiving vaak niet door iedereen met vreugde worden begroet. Omdat de gewoonten van mensen moeilijk te veranderen zijn.
Wanneer iemand zijn gebruikelijke werk doet, doet hij dat vrijwel zonder na te denken. Haar cognitieve belasting is nul. Hij speelt er gewoon mee, hij heeft al een checklist in zijn hoofd, hij heeft het al duizend keer gedaan. En zodra je hem komt vertellen: ‘Laten we deze oefening stopzetten en vanaf maandag een nieuwe introduceren’, wordt het voor hem een krachtige cognitieve belasting. En het komt voor iedereen tegelijk.
Daarom is het eenvoudigste, hoewel niet iedereen deze luxe kan betalen, maar dit is wat ik altijd doe, dit is het volgende. Als er een nieuw project start, worden doorgaans alle ongeteste praktijken meteen in dit project gepropt. Hoewel het project nog jong is, riskeren we eigenlijk niets. Er is nog geen Prod, er valt niets te vernietigen. Daarom kan het als training worden gebruikt. Deze aanpak werkt. Maar niet alle bedrijven hebben vaak de mogelijkheid om dergelijke projecten te starten. Hoewel dit ook een beetje vreemd is, omdat er nu een complete digitale transformatie plaatsvindt, moet iedereen experimenten lanceren om de concurrentie bij te houden.
Hier kom je tot de conclusie dat je eerst moet begrijpen wat je moet doen. De wereld is niet ideaal, en producten zijn ook niet ideaal.
Ja, deze dingen zijn met elkaar verbonden.
Bedrijven begrijpen ook niet altijd dat ze deze kant op moeten.
Er is een situatie waarin helemaal geen verandering mogelijk is. Dit is een situatie waarin de druk op het team groter is. Het team is al behoorlijk opgebrand. Ze heeft geen vrije tijd voor experimenten. Ze werken van 's ochtends tot 's avonds aan functies. En het beheer heeft steeds minder functies. Er is steeds meer nodig. In een dergelijke situatie zijn er helemaal geen veranderingen mogelijk. Het team kan alleen worden verteld dat we morgen hetzelfde zullen doen als gisteren, we moeten alleen wat meer features maken. In die zin zijn er geen overgangen naar welke praktijk dan ook mogelijk. Dit is een klassieke situatie waarin er geen tijd is om de bijl te slijpen, bomen moeten worden gekapt, dus kappen ze met een botte bijl. Er zijn hier geen eenvoudige tips.
(Dmitry) Ik zal een verduidelijking voorlezen uit de chat: “Maar we hebben veel testverslaggeving op verschillende niveaus nodig. Hoeveel tijd wordt er uitgetrokken voor tests? Het is een beetje duur en kost veel tijd.”
(Oleg) Dit is een klassieke misvatting. Er moeten voldoende tests zijn om u vertrouwen te geven. Continue integratie is niet iets waarbij eerst 100% van de tests wordt gedaan en pas daarna deze praktijk begint toe te passen. Continue Integratie vermindert uw cognitieve belasting vanwege het feit dat elk van de veranderingen die u met uw ogen ziet zo duidelijk is dat u begrijpt of iets kapot gaat of niet, zelfs zonder tests. Je kunt dit snel in je hoofd testen omdat de veranderingen klein zijn. Zelfs als je alleen handmatige testers hebt, is het voor hen ook gemakkelijker. Je rolde naar buiten en zei: "Kijk, is er iets kapot?" Ze controleerden het en zeiden: "Nee, er is niets kapot." Omdat de tester weet waar hij moet kijken. Er is één commit gekoppeld aan één stukje code. En dit wordt uitgebuit door specifiek gedrag.
Hier wordt u uiteraard verfraaid.
(Dmitry) Ik ben het hier niet mee eens. Er is een praktijk-testgestuurde ontwikkeling, die u hiervan zal redden.
(Oleg) Nou, op dat punt ben ik nog niet aangekomen. De eerste illusie is dat je 100% van de tests moet schrijven, anders hoef je helemaal geen Continuous Integration te doen. Het is niet waar. Dit zijn twee parallelle praktijken. En ze zijn niet direct afhankelijk. Uw testdekking moet optimaal zijn. Optimaal - dit betekent dat u er zelf zeker van bent dat de kwaliteit van de master waarin uw master na de commit is gebleven, u in staat stelt om op een dronken vrijdagavond met vertrouwen op de knop "Deploy" te drukken. Hoe bereik je dit? Door review, door berichtgeving, door goede monitoring.
Goede monitoring is niet te onderscheiden van testen. Als je één keer tests uitvoert op pre-prod, controleren ze al je gebruikersscripts één keer en dat is alles. En als je ze in een eindeloze lus laat draaien, dan is dit je geïmplementeerde monitoringsysteem, dat alles eindeloos test - of het nu gecrasht is of niet. In dit geval is het enige verschil of het één of twee keer wordt gedaan. Een zeer goede reeks tests... die eindeloos worden uitgevoerd, dit is monitoring. En een goede monitoring zou zo moeten zijn.
En daarom is het een andere vraag hoe je deze toestand precies zult bereiken als je je op vrijdagavond klaarmaakt en naar huis gaat. Misschien ben je gewoon een brutale klootzak.
Laten we even teruggaan naar continue integratie. We kwamen terecht in een iets andere, complexe praktijk.
En de tweede illusie is dat MVP, zeggen ze, snel moet gebeuren, dus daar zijn tests helemaal niet nodig. Zeker niet op die manier. Feit is dat wanneer je een gebruikersverhaal in een MVP schrijft, je het óf ter plekke kunt ontwikkelen, dat wil zeggen, je hebt gehoord dat er een soort gebruikersverhaal was en meteen bent gaan coderen, óf je kunt met TDD werken. En volgens TDD duurt het, zoals de praktijk laat zien, niet langer, d.w.z. tests zijn een bijwerking. De praktijk van TDD gaat niet over testen. Ondanks wat Test Driven Development heet, gaat het helemaal niet om testen. Dit is ook eerder een architectonische benadering. Dit is een benadering om precies te schrijven wat nodig is en niet te schrijven wat niet nodig is. Dit is een praktijk waarbij u zich concentreert op de volgende iteratie van uw denken in termen van het creëren van een applicatiearchitectuur.
Daarom is het niet zo eenvoudig om van deze illusies af te komen. MVP en tests spreken elkaar niet tegen. Sterker nog, als je MVP doet met behulp van TDD-oefeningen, dan zul je het beter en sneller doen dan wanneer je het doet zonder enige oefening, maar op een bal.
Dit is een zeer niet voor de hand liggend en complex idee. Als je hoort dat ik nu meer tests ga schrijven en tegelijkertijd iets sneller ga doen, klinkt dat absoluut ontoereikend.
(Dmitry) Veel mensen hier zijn, als ze MVP bellen, te lui om iets normaals te schrijven. En dit zijn nog steeds verschillende dingen. Het is niet nodig om van MVP iets slechts te maken dat niet werkt.
Ja, ja, je hebt gelijk.
En dan plotseling MVP in productie.
Voor altijd.
En TDD klinkt heel ongebruikelijk als je hoort dat je toetsen schrijft en meer werk lijkt te doen. Het klinkt heel vreemd, maar eigenlijk wordt het zo sneller en mooier. Als je een test schrijft, denk je in je hoofd al veel na over welke code gaat heten en hoe, en welk gedrag we ervan verwachten. Je zegt niet alleen dat ik een functie heb geschreven en dat deze iets doet. Eerst dacht je dat ze zulke en die aandoeningen had, dat er op die en die manier een beroep op haar zou worden gedaan. Je bedekt dit met tests en hierdoor begrijp je hoe je interfaces er in je code uit zullen zien. Dit heeft een enorme impact op de architectuur. Je code wordt automatisch modulairer, omdat je eerst probeert te begrijpen hoe je hem gaat testen, en hem dan pas schrijft.
Wat mij overkwam bij TDD was dat ik op een gegeven moment een Ruby-mentor inhuurde toen ik nog een Ruby-programmeur was. En hij zegt: “Laten we het doen volgens TDD.” Ik dacht: “Verdorie, nu moet ik nog iets extra’s schrijven.” En we spraken af dat ik binnen twee weken alle werkende code in Python zou schrijven met behulp van TDD. Na twee weken besefte ik dat ik niet meer terug wilde. Na twee weken proberen dit overal toe te passen, besef je hoeveel gemakkelijker het voor je is geworden om zelfs maar na te denken. Maar dit is niet vanzelfsprekend, dus ik raad iedereen aan om, als je het gevoel hebt dat TDD moeilijk, tijdrovend en onnodig is, het maar twee weken vol te houden. Twee waren voor mij genoeg.
(Dmitry) We kunnen dit idee uitbreiden vanuit het oogpunt van infrastructuuroperatie. Voordat we iets nieuws lanceren, doen we monitoring en lanceren we vervolgens. In dit geval wordt monitoring voor ons een normale test. En er is sprake van ontwikkeling door middel van monitoring. Maar bijna iedereen zegt dat het lang duurt, ik ben lui, ik heb een tijdelijke versie gemaakt. Als we normale monitoring hebben uitgevoerd, begrijpen we de status van het CI-systeem. En het CI-systeem kent veel monitoring. We begrijpen de toestand van het systeem, we begrijpen wat erin zit. En tijdens de ontwikkeling zorgen we ervoor dat het systeem de gewenste staat bereikt.
Deze praktijken zijn al langer bekend. Wij hebben dit ongeveer 4 jaar geleden besproken. Maar in 4 jaar tijd is er vrijwel niets veranderd.
Maar wat dit betreft stel ik voor om de officiële discussie te beëindigen.
Video (ingevoegd als media-element, maar werkt om de een of andere reden niet):
Bron: www.habr.com