Ni diskutu kial CI-iloj kaj CI estas tute malsamaj aferoj.
Kian doloron CI celas solvi, de kie venis la ideo, kiaj estas la lastaj konfirmoj, ke ĝi funkcias, kiel kompreni, ke vi havas praktikon kaj ne nur instalis Jenkins.
La ideo fari raporton pri Daŭra Integriĝo aperis antaŭ unu jaro, kiam mi iris por intervjuoj kaj serĉis laboron. Mi parolis kun 10-15 kompanioj, nur unu el ili povis klare respondi kio estas CI kaj klarigi kiel ili rimarkis, ke ili ne havas ĝin. La ceteraj parolis nekompreneblajn sensencaĵojn pri Jenkins :) Nu, ni havas Jenkins, ĝi ja konstruas, CI! Dum la raporto, mi provos klarigi, kio efektive estas Kontinua Integriĝo kaj kial Jenkins kaj similaj iloj havas tre malfortan rilaton kun ĉi tio.
Do, kio kutime venas al la menso kiam vi aŭdas la vorton CI? Plej multaj homoj pensos pri Jenkins, Gitlab CI, Travis, ktp.
Eĉ se ni guglos ĝin, ĝi donos al ni ĉi tiujn ilojn.
Se vi konas demandi, tiam tuj post listigo de la iloj, ili diros al vi, ke CI estas kiam vi konstruas kaj rulas testojn en Tiro-Peto por kompromiso.
Daŭra Integriĝo ne temas pri iloj, ne pri asembleoj kun testoj en la branĉo! Kontinua Integrado estas la praktiko de tre ofta integriĝo de nova kodo kaj por uzi ĝin tute ne necesas bari Jenkins, GitLab, ktp.
Antaŭ ol ni eltrovi, kiel aspektas plenrajta CI, ni unue plonĝu en la kuntekston de la homoj, kiuj elpensis ĝin kaj sentas la doloron, kiun ili provis solvi.
Kaj ili solvis la doloron labori kune kiel teamo!
Ni rigardu ekzemplojn de la malfacilaĵoj alfrontataj de programistoj dum evoluado en teamoj. Ĉi tie ni havas projekton, majstran branĉon en git kaj du programistojn.
Kaj ili eklaboris, kiel ĉiuj jam delonge kutimis. Ni prenis taskon en la grandioza skemo de aferoj, kreis trajtobranĉon, kaj skribis la kodon.
Oni finis la funkcion pli rapide kaj kunfandis ĝin en la majstron.
La dua bezonis pli da tempo, ĝi poste kunfandiĝis kaj finiĝis kun konflikto. Nun, anstataŭ skribi la funkciojn, kiujn la komerco bezonas, la programisto elspezas sian tempon kaj energion solvante konfliktojn.
Ju pli malfacile estas kombini vian funkcion kun komuna majstro, des pli da tempo ni pasigas por ĝi. Kaj mi montris tion per sufiĉe simpla ekzemplo. Ĉi tio estas ekzemplo, kie estas nur 2 programistoj. Imagu, se 10 aŭ 15 aŭ 100 homoj en firmao skribas al unu deponejo. Vi freneziĝos por solvi ĉiujn ĉi tiujn konfliktojn.
Estas iomete malsama kazo. Ni havas majstron kaj iujn programistojn farantajn ion.
Ili kreis branĉeton.
Unu mortis, ĉio estis en ordo, li pasigis la taskon.
La dua programisto, dume, transdonis sian taskon. Ni diru, ke li sendis ĝin por revizio. Multaj kompanioj havas praktikon nomatan revizio. Unuflanke, ĉi tiu praktiko estas bona kaj utila, aliflanke, ĝi bremsas nin multmaniere. Ni ne eniros tion, sed jen bonega ekzemplo de tio, al kio malbona recenza rakonto povas konduki. Vi sendis tiran peton por revizio. Estas nenio pli por la programisto fari. Kion li komencas fari? Li komencas preni aliajn taskojn.
Dum ĉi tiu tempo, la dua programisto faris ion alian.
La unua plenumis la trian taskon.
Kaj post longa tempo, lia recenzo estis provita, kaj li provas interkonsenti. Kio do okazas? Ĝi kaptas grandegan nombron da konfliktoj. Kial? Ĉar dum lia tira peto pendas en la recenzo, multaj aferoj jam ŝanĝiĝis en la kodo.
Krom la rakonto kun konfliktoj, ekzistas rakonto kun komunikadoj. Dum via fadeno pendas en revizio, dum ĝi atendas ion, dum vi laboras pri funkcio dum longa tempo, vi ĉesas spuri kio alia ŝanĝiĝas en la koda bazo de via servo. Eble tio, kion vi provas solvi nun, estis jam solvita hieraŭ kaj vi povas preni iun metodon kaj reuzi ĝin. Sed vi ne vidos ĉi tion ĉar vi ĉiam laboras kun malmoderna branĉo. Kaj ĉi tiu malmoderna branĉo ĉiam rezultigas, ke vi devas solvi kunfandan konflikton.
Montriĝas, ke se ni laboras kiel teamo, t.e., ne unu persono pikas en la deponejo, sed 5-10 homoj, tiam ju pli longe ni ne aldonas nian kodon al la majstro, des pli ni suferas ĉar ni finfine bezonas. io tiam kunfandi ĝin. Kaj ju pli da konfliktoj ni havas, kaj ju pli malnova versio ni laboras, des pli da problemoj ni havas.
Fari ion kune estas dolora! Ni ĉiam malhelpas unu la alian.
Ĉi tiu problemo estis rimarkita antaŭ pli ol 20 jaroj. Mi trovis la unuan mencion pri la praktiko de Kontinua Integriĝo en Ekstrema Programado.
Ekstrema Programado estas la unua lerta kadro. La paĝo aperis en 96. Kaj la ideo estis uzi ian programajn praktikojn, planadon kaj aliajn aferojn, por ke la evoluo estu kiel eble plej fleksebla, por ke ni rapide respondu al ajnaj ŝanĝoj aŭ postuloj de niaj klientoj. Kaj ili komencis alfronti ĉi tion antaŭ 24 jaroj, ke se vi faras ion dum tre longa tempo kaj flanke, tiam vi pasigas pli da tempo pri tio ĉar vi havas konfliktojn.
Nun ni analizos la frazon "Kontinua Integriĝo" individue. Se ni tradukas ĝin rekte, ni ricevas kontinuan integriĝon. Sed kiom kontinua ĝi estas ne estas tre klara; ĝi estas tre malkontinua. Sed kiom da integriĝo ĝi havas ankaŭ ne estas tre evidenta.
Kaj tial mi nun donas al vi citaĵojn el Ekstrema Programado. Kaj ni analizos ambaŭ vortojn aparte.
Integriĝo - Kiel mi jam diris, ni strebas certigi, ke ĉiu inĝeniero laboru kun la plej aktuala versio de la kodo, por ke li klopodu aldoni sian kodon kiel eble plej ofte al komuna branĉo, por ke ĉi tiuj estu malgrandaj branĉoj. Ĉar se ili estas grandaj, tiam ni povas facile blokiĝi kun kunfandaj konfliktoj dum semajno. Ĉi tio estas precipe vera se ni havas longan disvolvan ciklon kiel akvofalo, kie la programisto foriris dum monato por tranĉi iun grandegan funkcion. Kaj li restos ĉe la integriga stadio por tre longa tempo.
Integriĝo estas kiam ni prenas nian branĉon kaj integras ĝin kun la majstro, ni kunfandas ĝin. Estas finfina opcio kiam ni estas transbaza programisto, kie ni strebas certigi, ke ni tuj skribu al la majstro sen ekstraj branĉoj.
Ĝenerale, integriĝo signifas preni vian kodon kaj treni ĝin en la majstron.
Kion ĉi tie signifas la vorto "kontinua", kion oni nomas kontinueco? Praktiko implicas, ke la programisto strebas integri sian kodon kiel eble plej rapide. Ĉi tiu estas lia celo kiam plenumas ajnan taskon - enigi lian kodon en majstron kiel eble plej rapide. En ideala mondo, programistoj farus ĉi tion ĉiujn kelkajn horojn. Tio estas, vi prenas malgrandan problemon kaj kunfandas ĝin en la majstron. Ĉio estas bonega. Jen kion vi strebas. Kaj ĉi tio devas esti farita senĉese. Tuj kiam vi faras ion, vi tuj metas ĝin en la majstron.
Kaj la programisto, kiu faras ion, respondecas pri tio, kion li faris por ke ĝi funkciu kaj ne rompi ion. Ĉi tie kutime aperas la testrakonto. Ni volas fari iujn provojn pri nia kommit, sur nia kunfandado, por certigi, ke ĝi funkcias. Kaj jen kie Jenkins povas helpi vin.
Sed kun rakontoj: ni faru la ŝanĝojn malgrandaj, ni lasu la taskojn esti malgrandaj, ni faru problemon kaj tuj provu iel enigi ĝin en la majstron - neniu Jenkins helpos ĉi tie. Ĉar Jenkins nur helpos vin fari testojn.
Vi povas fari sen ili. Ĉi tio tute ne damaĝos vin. Ĉar la celo de la praktiko estas mezuri kiel eble plej ofte, por ne perdi grandegan tempon pri iuj konfliktoj estontece.
Ni imagu, ke ial ni estas en 2020 sen Interreto. Kaj ni laboras loke. Ni ne havas Jenkins. Ĉi tio estas bone. Vi ankoraŭ povas daŭrigi kaj fari lokan branĉon. Vi skribis iom da kodo en ĝi. Ni plenumis la taskon en 3-4 horoj. Ni ŝanĝis al majstro, faris git-tiron kaj kunfandis nian branĉon tie. Preta. Se vi faras tion ofte, gratulon, vi havas Daŭran Integriĝon!
Kiaj pruvoj en la moderna mondo ekzistas, ke indas elspezi energion? Ĉar ĝenerale ĝi estas malfacila. Se vi provos labori tiel, vi komprenos, ke iom da planado nun estos tuŝita, vi devos dediĉi pli da tempo al malkomponaj taskoj. Ĉar se vi faros homon..., tiam vi ne povos rapide interkonsenti kaj, sekve, vi havos problemojn. Vi ne plu havos praktikon.
Kaj ĝi estos multekosta. Ne eblos labori tuj ekde morgaŭ uzante Daŭran Integriĝon. Necesos al vi ĉiuj tre longa tempo por alkutimiĝi al ĝi, necesos al vi tre longa tempo por alkutimiĝi al malkomponaj taskoj, daŭros tre longa tempo por alkutimiĝi al refari la reviziopraktikon, se vi havas unu. . Ĉar nia celo estas, ke ĝi degelu hodiaŭ. Kaj se vi faras revizion ene de tri tagoj, tiam vi havas problemojn kaj Daŭra Integriĝo ne funkcias por vi.
Sed ĉu ni havas signifan indicon nun, kiu diras al ni, ke investi en ĉi tiu praktiko havas sencon?
La unua afero, kiu venis al mia menso, estis Ŝtato de DevOps. Ĉi tio estas studo, kiun la infanoj faras dum 7 jaroj. Nun ili faras ĝin kiel sendependa organizo, sed sub Guglo.
Kaj ilia studo de 2018 montris korelacion inter kompanioj, kiuj provas uzi mallongdaŭrajn branĉojn, kiuj integriĝas rapide, ofte integriĝas kaj havas pli bonajn IT-efikecajn indikilojn.
Kio estas ĉi tiuj indikiloj? Ĉi tiuj estas 4 mezuroj, kiujn ili prenas de ĉiuj kompanioj en siaj demandaroj: ofteco de deplojo, tempodaŭro por ŝanĝoj, tempo por restarigi servon, ŝanĝa malsukcesa indico.
Kaj, unue, ekzistas ĉi tiu korelacio, ni scias, ke kompanioj, kiuj mezuras ofte, havas multe pli bonajn metrikojn. Kaj ili havas dividon de kompanioj en plurajn kategoriojn: ĉi tiuj estas malrapidaj kompanioj, kiuj produktas ion malrapide, meza, alta kaj elita. La elito estas Netflix, Amazon, kiuj estas superrapidaj, faras ĉion rapide, bele kaj efike.
La dua rakonto, kiu okazis antaŭ nur monato. Technology Radar havas bonegan artikolon pri Gitflow. Gitflow diferencas de ĉiuj aliaj pro tio, ke ĝiaj branĉoj estas longevivaj. Estas liberigaj branĉoj, kiuj vivas longe, kaj prezentas branĉojn, kiuj ankaŭ longe vivas. Ĉi tiu praktiko ĉe Technology Radar moviĝis al HOLD. Kial? Ĉar homoj alfrontas la doloron de integriĝo.
Se via branĉo vivas tre longe, ĝi blokiĝas, putriĝas, kaj ni komencas pasigi pli da tempo provante fari ian ŝanĝon al ĝi.
Kaj lastatempe la aŭtoro de Gitflow diris, ke se via celo estas Daŭra Integriĝo, se via celo estas, ke vi volas ruliĝi kiel eble plej ofte, tiam Gitflow estas malbona ideo. Li aparte aldonis al la artikolo, ke se vi havas backend kie vi povas strebi por tio, tiam Gitflow estas superflua por vi, ĉar Gitflow malrapidigos vin, Gitflow kreos problemojn por vi kun integriĝo.
Ĉi tio ne signifas, ke Gitflow estas malbona kaj ne devus esti uzata. Ĝi estas por aliaj okazoj. Ekzemple, kiam vi bezonas subteni plurajn versiojn de servo aŭ aplikaĵo, t.e. kie vi bezonas subtenon dum longa tempo.
Sed se vi parolas kun homoj, kiuj subtenas tiajn servojn, vi aŭdos multe da doloro pri la fakto, ke ĉi tiu versio estis 3.2, kiu estis antaŭ 4 monatoj, sed ĉi tiu riparo ne estis inkluzivita en ĝi kaj nun, por fari ĝin, vi devas fari multajn ŝanĝojn. Kaj nun ili estas denove blokitaj, kaj nun ili ludis dum unu semajno provante efektivigi iun novan funkcion.
Kiel Alexander Kovalev ĝuste notis en la babilejo, korelacio ne samas kiel kaŭzado. Ĉi tio estas vera. Tio estas, ne ekzistas rekta konekto, ke se vi havas Daŭran Integriĝon, tiam ĉiuj metrikoj estos bonegaj. Sed estas pozitiva korelacio, ke se unu estas unu, tiam plej verŝajne ankaŭ la alia estas. Ne fakto, sed plej verŝajne. Ĝi estas nur korelacio.
Ŝajnas, ke ni jam faras ion, ŝajnas, ke ni jam kunfandiĝas, sed kiel ni povas kompreni, ke ni ankoraŭ havas Daŭran Integradon, ke ni sufiĉe ofte kunfandiĝas?
Jez Humble estas la verkinto de Manlibro, Akceli, la retejo Continuous Delivery, kaj la libro Continuous Delivery. Li proponas ĉi tiun provon:
- La kodo de la inĝeniero venas al la majstro ĉiutage.
- Por ĉiu kompromiso vi faras unutestojn.
- La konstruo en la majstro falis, ĝi estis riparita en ĉirkaŭ 10 minutoj.
Li sugestas uzi tian teston por certigi, ke vi havas sufiĉe da praktiko.
Mi trovas ĉi-lastan iom polemika. Tio estas, se vi povas ripari ĝin en 10 minutoj, tiam vi havas Daŭran Integriĝon, ĝi sonas iom strange, laŭ mi, sed ĝi havas sencon. Kial? Ĉar se vi frostiĝas ofte, tio signifas, ke viaj ŝanĝoj estas malgrandaj. Se malgranda ŝanĝo signifas, ke via majstra konstruo estas rompita, tiam vi povas trovi ekzemplon rapide ĉar la ŝanĝo estas malgranda. Ĉi tie vi havis malgrandan kunfandiĝon, 20-30 linioj en ĝi ŝanĝiĝis. Kaj, sekve, vi povas rapide kompreni, kio estis la kialo, ĉar la ŝanĝoj estas etaj, vi havas tre malgrandan areon por serĉi la problemon.
Kaj eĉ se nia prod disfalas post la liberigo, tiam se ni havas la praktikon de Daŭra Integriĝo, estas multe pli facile por ni agi, ĉar la ŝanĝoj estas etaj. Jes, ĉi tio influos planadon. Ĉi tio doloros. Kaj, verŝajne, la plej malfacila afero en ĉi tiu praktiko estas alkutimiĝi al malkonstruo de taskoj, tio estas, kiel fari ĝin por ke vi povu preni ion kaj fari ĝin en kelkaj horoj kaj samtempe pasi revizion, se vi havas unu. Revizio estas aparta doloro.
Unuaj testoj estas nur asistanto, kiu helpas vin kompreni ĉu via integriĝo sukcesis kaj ĉu nenio rompiĝis. Miaopinie, ankaŭ ĉi tio ne estas tute deviga, ĉar ĉi tio ne estas la praktiko.
Ĉi tio estas mallonga enkonduko al Kontinua Integriĝo. Jen ĉio estas al ĉi tiu praktiko. Mi estas preta por demandoj.
Mi nur resumos denove mallonge:
- Kontinua Integriĝo ne estas Jenkins, ĝi ne estas Gitlab.
- Ĉi tio ne estas ilo, ĝi estas praktiko, ke ni kunfandas nian kodon en la majstron kiel eble plej ofte.
- Ni faras tion por eviti la grandegan doloron, kiu estiĝas kun kuniĝoj en la estonteco, tio estas, ni spertas iom da doloro nun por ne sperti pli en la estonteco. Jen la tuta afero.
- Flanke estas komunikado per kodo, sed mi tre malofte vidas tion, sed ankaŭ por tio ĝi estis desegnita.
Viaj demandoj
Kion fari kun nemalkomponitaj taskoj?
Malkomponi. Kio estas la problemo? Ĉu vi povas doni ekzemplon, ke ekzistas tasko kaj ĝi ne estas malkomponita?
Estas taskoj, kiuj ne povas esti malkomponitaj de la vorto "tute", ekzemple tiuj, kiuj postulas tre profundan kompetentecon kaj kiuj efektive povas esti solvitaj dum monato por atingi ian digesteblan rezulton.
Se mi komprenas vin ĝuste, tiam estas iu granda kaj kompleksa tasko, kies rezulto estos videbla nur post unu monato?
Jes tio pravas. Jes, eblos taksi la rezulton ne pli frue ol post unu monato.
Bone. Ĝenerale ĉi tio ne estas problemo. Kial? Ĉar ĉi-kaze, kiam ni parolas pri branĉetoj, ni ne parolas pri branĉeto kun trajto. Trajtoj povas esti grandaj kaj kompleksaj. Ili povas influi grandan nombron da komponantoj. Kaj eble ni ne povas fari ilin tute en unu branĉo. Ĉi tio estas bone. Ni nur bezonas rompi ĉi tiun rakonton. Se trajto ne estas tute preta, tio ne signifas, ke kelkaj pecoj de ĝia kodo ne povas esti kunfanditaj. Vi aldonis, ekzemple, migradon kaj estas kelkaj etapoj en la funkcio. Ni diru, ke vi havas etapon - faru migradon, aldonu novan metodon. Kaj vi jam povas mezuri ĉi tiujn aferojn ĉiutage.
Bone. Kio estas do?
Kio estas la signifo mortigi malgrandajn aferojn ĉiutage?
Jes.
Se ili rompas ion, vi tuj vidas ĝin. Vi havas malgrandan pecon, kiu rompis ion, estas pli facile por vi ripari ĝin. La punkto estas, ke kunfandi malgrandan pecon nun estas multe pli facila ol kunfandi ion grandan en kelkaj semajnoj. Kaj la tria punkto estas, ke aliaj inĝenieroj laboros kun la nuna versio de la kodo. Ili vidos, ke iuj migradoj estis aldonitaj ĉi tie, kaj tiam aperis iu metodo, kiun ili eble ankaŭ volas uzi. Ĉiuj vidos, kio okazas en via kodo. Estas por ĉi tiuj tri aferoj, ke oni faras praktikon.
Dankon, la afero estas fermita!
(Oleg Soroka) Ĉu mi rajtas aldoni? Vi diris ĉion ĝuste, mi nur volas aldoni unu frazon.
Do
Kun Daŭra Integriĝo, la kodo estas kunfandita en komunan branĉon ne kiam la funkcio estas tute preta, sed kiam la konstruo ĉesas rompiĝi. Kaj vi povas sekure kompromiti majstri tiom da fojoj tage kiel vi volas. La dua aspekto estas, ke se ial vi ne povas dividi la monatan taskon en taskojn dum almenaŭ tri tagoj, mi silentas ĉirkaŭ tri horoj, tiam vi havas grandegan problemon. Kaj la fakto ke vi ne havas Daŭran Integriĝon estas la plej malgranda el ĉi tiuj problemoj. Ĉi tio signifas, ke vi havas problemojn kun arkitekturo kaj nulaj inĝenieraj praktikoj. Ĉar eĉ se tio estas esploro, tiam ĉiukaze ĝi devas esti formulita en formo de hipotezoj aŭ ciklo.
Ni parolis pri 4-metrikoj, kiuj distingas sukcesajn kompaniojn de postrestataj. Ni ankoraŭ devas vivi por vidi ĉi tiujn 4 metrikojn. Se via averaĝa tasko bezonas monaton por plenumi, tiam mi unue fokusus ĉi tiun metrikon. Mi unue malaltigus ĝin al 3 tagoj. Kaj post tio mi ekpensis pri Daŭra.
Ĉu mi ĝuste komprenis vin, ke vi opinias, ke ĝenerale ne utilas investi en inĝenieristikajn praktikojn, se iu tasko daŭras monaton?
Vi havas Daŭran Integriĝon. Kaj ekzistas tia temo, ke en 10 minutoj vi povas aŭ ripari solvon aŭ refari ĝin. Imagu, ke vi elrulis ĝin. Plie, vi eĉ havas daŭran disfaldiĝon, vi eligis ĝin por prod kaj nur tiam rimarkis, ke io misfunkciis. Kaj vi devas refari ĝin, sed vi jam migris vian datumbazon. Vi jam havas la datumbazan skemon de la sekva versio, cetere vi ankaŭ havis ian sekurkopion, kaj la datumoj ankaŭ estis skribitaj tie.
Kaj kian alternativon vi havas? Se vi retroiras la kodon, tiam ĝi ne plu povas funkcii kun ĉi tiu ĝisdatigita datumbazo.
La bazo nur antaŭeniras, jes.
Homoj, kiuj havas malbonajn inĝenierajn praktikojn, plej verŝajne ankaŭ ne legis la dikan libron pri.... Kion fari kun la sekurkopio? Se vi restarigas de sekurkopio, tio signifas, ke vi perdas la datumojn, kiujn vi amasigis dum tiu momento. Ekzemple, ni laboris dum tri horoj kun la nova versio de la datumbazo, uzantoj registritaj tie. Vi rifuzas la malnovan sekurkopion ĉar la skemo ne funkcias kun la nova versio, do vi perdis ĉi tiujn uzantojn. Kaj ili estas malkontentaj, ili ĵuras.
Por regi la plenan gamon da praktikoj kiuj subtenas Daŭran Integriĝon kaj Daŭran Liveron, ne sufiĉas nur lerni kiel skribi.... Unue, povas esti multaj, ĝi estos nepraktika. Krome estas amaso da aliaj praktikoj kiel Scienca. Estas tia praktiko, GitHub popularigis ĝin samtempe. Jen kiam vi havas kaj malnovan kodon kaj novan kodon funkciantan samtempe. Jen kiam vi faras nefinitan funkcion, sed ĝi povas redoni iun valoron: aŭ kiel funkcio aŭ kiel Rest-API. Vi plenumas kaj la novan kodon kaj la malnovan kodon, kaj komparas la diferencon inter ili. Kaj se estas diferenco, tiam vi ensalutu ĉi tiun eventon. Tiel vi scias, ke vi havas novan funkcion preta ruliĝi super la malnova se vi ne havis diferencon inter la du dum certa tempo.
Estas centoj da tiaj praktikoj. Mi sugestus komenci per transbaza evoluo. Ŝi ne estas 100% pri Daŭra Integriĝo, sed la praktikoj estas la samaj, unu ne povas vivi bone sen la alia.
Ĉu vi donis transbase-disvolviĝon kiel ekzemplon, kie vi povas vidi praktikojn aŭ ĉu vi sugestas, ke homoj komencu uzi transbase-debelopment?
Rigardu, ĉar ili ne povos uzi ĝin. Por uzi ilin, vi devas legi multe. Kaj kiam persono demandas: "Kion fari kun trajto kiu daŭras monaton, tio signifas, ke li ne legis pri transbaza disvolviĝo." Mi ankoraŭ ne rekomendus ĝin. Mi konsilus koncentriĝi nur pri la temo kiel ĝuste arkitekture malkonstrui grandajn taskojn en pli malgrandajn. Ĉi tio estas la esenco de putriĝo.
Malkomponiĝo estas unu el la iloj de la arkitekto. Ni unue faras analizon, poste malkomponadon, poste sintezon, poste integriĝon. Kaj jen kiel ĉio funkcias por ni. Kaj ni ankoraŭ bezonas kreski al Daŭra Integriĝo per putriĝo. Demandoj aperas ĉe la unua etapo, kaj ni jam parolas pri la kvara etapo, t.e. ju pli ofte ni faras integriĝon, des pli bone. Ankoraŭ estas tro frue por fari ĉi tion; estus bone tranĉi vian monoliton unue.
Vi devas desegni kelkajn sagojn kaj kvadratojn sur iu diagramo. Vi ne povas diri, ke nun mi montros la arkitekturan diagramon de nova aplikaĵo kaj montros unu kvadraton, ene de kiu estas verda butono por la aplikaĵo. Ĉiukaze, estos pli da kvadratoj kaj sagoj. Ĉiu diagramo, kiun mi vidis, havis pli ol unu. Kaj malkomponiĝo, eĉ je la nivelo de grafika reprezentado, jam okazas. Tial, la kvadratoj povas esti sendependaj. Se ne, tiam mi havas grandajn demandojn por la arkitekto.
Estas demando de la babilejo: "Se revizio estas deviga kaj daŭras longan tempon, eble unu tagon aŭ pli?"
Vi havas problemojn kun praktiko. La revizio ne devus daŭri unu tagon aŭ pli. Ĉi tiu estas la sama rakonto al la antaŭa demando, nur iom pli milda. Se revizio daŭras dum unu tago, tiam plej verŝajne ĉi tiu revizio okazas tre granda ŝanĝo. Ĉi tio signifas, ke ĝi devas esti pli malgranda. En transbaza evoluo, kiun Oleg rekomendis, ekzistas rakonto nomata kontinua revizio. Ŝia ideo estas, ke ni intence faras tian malgrandan tiran peton, ĉar ni strebas kunfandiĝi konstante kaj iom post iom. Kaj tiel la tiri peto ŝanĝas unu abstraktadon aŭ 10 liniojn. Danke al ĉi tiu recenzo, ĝi prenas nin kelkajn minutojn.
Se la revizio daŭras tagon aŭ pli, io estas malĝusta. Unue, vi eble havas iujn problemojn kun la arkitekturo. Aŭ ĉi tio estas granda kodo, 1 linioj, ekzemple. Aŭ via arkitekturo estas tiel kompleksa ke homo ne povas kompreni ĝin. Ĉi tio estas iomete flanka problemo, sed ĝi ankaŭ devos esti solvita. Eble tute ne necesas revizio. Ni devas pensi ankaŭ pri ĉi tio. Revizio estas la afero, kiu malrapidigas vin. Ĝi havas siajn avantaĝojn ĝenerale, sed vi devas kompreni kial vi faras ĝin. Ĉu ĉi tio estas maniero por vi rapide transdoni informojn, ĉu ĉi tio estas maniero por vi starigi iujn normojn interne aŭ kio? Kial vi bezonas ĉi tion? Ĉar la revizio devas esti farita aŭ tre rapide aŭ tute nuligita. Estas kiel transbase deveploment - la rakonto estas tre bela, sed nur por maturaj uloj.
Koncerne la 4 metrikojn, mi ankoraŭ rekomendus forigi ilin por kompreni, al kio ĉi tio kondukas. Rigardu la nombrojn, rigardu la bildon, kiel malbona ĉio estas.
(Dmitry) Mi estas preta eniri diskuton pri tio kun vi. Nombroj kaj metrikoj ĉiuj estas bonegaj, praktikoj estas bonegaj. Sed vi devas kompreni ĉu la komerco bezonas ĝin. Estas entreprenoj, kiuj ne bezonas tian rapidon de ŝanĝo. Mi konas kompaniojn, kie ŝanĝoj ne povas esti faritaj ĉiujn 15 minutojn. Kaj ne ĉar ili estas tiel malbonaj. Ĉi tio estas tia vivociklo. Kaj por ke la branĉoj funkcios, la baskuliman funkcion, vi bezonas profundan scion.
Estas komplike. Se vi volas legi la rakonton pri la baskuliga funkcio pli detale, mi tre rekomendas ĝin . Kaj estas mirinda artikolo de Martin Fowler pri baskulimaj funkcioj: kiaj tipoj ekzistas, vivocikloj, ktp. La baskuliga funkcio estas komplika.
Kaj vi ankoraŭ ne respondis la demandon: "Ĉu Jenkins bezonas aŭ ne?"
Jenkins ne estas bezonata ĉiukaze vere. Tamen serioze, la iloj: Jenkins, Gitlab alportos al vi oportunon. Vi vidos, ke la asembleo estas kunmetita aŭ ne kunvenita. Ili povas helpi vin, sed ili ne donos al vi praktikon. Ili povas nur doni al vi cirklon - Ok, ne Ok. Kaj tiam, se vi ankaŭ skribas testojn, ĉar se ne estas testoj, tiam ĝi estas preskaŭ sencela. Tial ĝi bezonas, ĉar ĝi estas pli oportuna, sed ĝenerale vi povas vivi sen ĝi, vi ne perdos multon.
Tio estas, se vi havas praktikojn, ĉu tio signifas, ke vi ne bezonas ĝin?
Tio ĝustas. Mi rekomendas la teston Jez Humble. Tie mi havas ambivalentan sintenon al la lasta punkto. Sed ĝenerale, se vi havas tri aferojn, vi konstante kunfalas, vi faras testojn pri komitaĵoj en la majstro, vi rapide riparas la konstruon en la majstro, tiam eble vi ne bezonas ion alian.
Dum ni atendas demandojn de partoprenantoj, mi havas demandon. Ni nur parolis pri la produktokodo. Ĉu vi uzis ĝin por infrastruktura kodo? Ĉu ĝi estas la sama kodo, ĉu ĝi havas la samajn principojn kaj la saman vivociklon, aŭ ĉu ekzistas malsamaj vivocikloj kaj principoj? Kutime, kiam ĉiuj parolas pri Daŭra Integriĝo kaj Disvolviĝo, ĉiuj forgesas, ke ekzistas ankaŭ infrastruktura kodo. Kaj lastatempe estis pli kaj pli da ĝi. Kaj ĉu ĉiuj ĉi reguloj estu alportitaj tien?
Eĉ ne tiel devus esti, estus bonege ĉar ĝi same faciligus la vivon. Tuj kiam ni laboras kun kodo, ne kun bash-skriptoj, sed ni havas normalan kodon.
Haltu, haltu, bash-skripto ankaŭ estas kodo. Ne tuŝu mian malnovan amon.
Bone, mi ne piedpremos viajn memorojn. Mi havas personan malŝaton por bash. Ĝi rompiĝas malbela kaj timiga la tutan tempon. Kaj ĝi ofte rompiĝas neantaŭvideble, tial mi ne ŝatas ĝin. Sed bone, ni diru, ke vi havas bash-kodon. Eble mi vere ne komprenas kaj ekzistas normalaj testaj kadroj tie. Mi simple ne scias. Kaj ni ricevas la samajn avantaĝojn.
Tuj kiam ni laboras kun infrastrukturo kiel kodo, ni ricevas ĉiujn samajn problemojn kiel programistoj. Antaŭ kelkaj monatoj mi alfrontis situacion, kie kolego sendis al mi tiran peton por 1 linioj en bash. Kaj vi pendigas ĉe la recenzo dum 000 horoj. La samaj problemoj ekestas. Ĝi ankoraŭ estas kodo. Kaj ĝi ankoraŭ estas kunlaboro. Ni blokiĝas kun la tirpeto kaj ni restas kun la fakto, ke ni solvas la samajn kunfandikonfliktojn en la sama bato, ekzemple.
Mi nun tre aktive rigardas ĉi tiun tutan aferon pri la plej bela infraprogramado. Mi nun alportis Pulumi en la infrastrukturon. Ĉi tio estas programado en sia plej pura formo. Tie estas eĉ pli agrable, ĉar mi havas ĉiujn kapablojn de programlingvo, t.e. mi faris belan baskulon el la bluo per la samaj se kaj ĉio estas en ordo. Tio estas, mia ŝanĝo jam estas en la majstro. Ĉiuj povas jam vidi lin. Aliaj inĝenieroj scias pri ĝi. Ĝi jam influis ion tie. Tamen, ĝi ne estis ebligita por ĉiuj infrastrukturoj. Ĝi ŝaltis por miaj testbenkoj, ekzemple. Tial, por respondi vian demandon denove, estas necese. Ĝi faciligas la vivon al ni, kiel inĝenieroj laborantaj kun kodo, same.
Se iu alia havas demandojn?
Mi havas demandon. Mi volas daŭrigi la diskuton kun Oleg. Ĝenerale mi opinias, ke vi pravas, ke se tasko bezonas monaton por plenumi, tiam vi havas problemon pri arkitekturo, vi havas problemon pri analizo, malkomponiĝo, planado ktp. Sed mi havas la senton, ke se vi komencas provante vivi laŭ Daŭra Integriĝo, tiam vi komencos korekti la doloron per planado, ĉar vi ne foriros de ĝi aliloke.
(Oleg) Jes, ĝuste. Ĉi tiu praktiko estas komparebla en fortostreĉo al iu alia serioza kulturŝanĝa praktiko. La plej malfacila afero por venki estas kutimoj, precipe malbonaj kutimoj. Kaj se por efektivigi ĉi tiun praktikon, necesas serioza ŝanĝo en la kutimoj de tiuj ĉirkaŭ vi: programistoj, administrado, produktestro, tiam surprizoj atendas vin.
Kiaj surprizoj povus esti? Ni diru, ke vi decidas, ke vi integriĝos pli ofte. Kaj vi havas iujn aliajn aferojn ligitajn al integriĝo, ekzemple artefaktoj. Kaj en via kompanio, ekzemple, ekzistas politiko, ke ĉiu artefakto devas esti iel prikalkulita en iu speco de artefakto-stokado-sistemo. Kaj necesas iom da tempo. Persono devas marki la skatolon, ke li, kiel eldonadministranto, testis ĉi tiun artefakton por certigi, ke ĝi estas preta por eldonado en produktado. Se necesas 5-10-15 minutoj, sed vi faras la aranĝon unufoje semajne, tiam pasigi duonhoron unufoje semajne estas malgranda imposto.
Se vi faras Daŭran Integriĝon 10 fojojn tage, tiam 10 fojojn devas esti multobligitaj per 30 minutoj. Kaj ĉi tio superas la kvanton da labortempo de ĉi tiu eldona administranto. Li nur laciĝas de fari ĝin. Estas fiksaj kostoj por iuj praktikoj. Tio estas ĉio.
Kaj vi devas aŭ nuligi ĉi tiun regulon, por ke vi ne plu faru tian rubon, t.e. vi ne mane atribuas gradon por respondi al io. Vi fidas tute je iu aŭtomatigita aro de pretaj testoj.
Kaj se vi bezonas pruvon de iu, por ke la estro subskribu ĝin, kaj vi ne eniru en produktadon sen Vasja diri, ke li permesas tion ktp. - ĉio ĉi sensencaĵo malhelpas la praktikiston. Ĉar se estas iuj agadoj asociitaj kun imposto, tiam ĉio pliiĝas 100 fojojn. Tial, la ŝanĝo ofte ne estos salutita kun ĝojo de ĉiuj. Ĉar la kutimoj de homoj estas malfacile ŝanĝeblaj.
Kiam homo faras sian kutiman laboron, li faras ĝin preskaŭ sen pensi. Ŝia kogna ŝarĝo estas nula. Li nur ludas per ĝi, li jam havas kontrolon en la kapo, li faris ĝin milfoje. Kaj tuj kiam vi venas kaj diras al li: "Ni nuligi ĉi tiun praktikon kaj enkonduku novan ekde lundo", por li ĝi fariĝas potenca kogna ŝarĝo. Kaj ĝi venas al ĉiuj samtempe.
Sekve, la plej simpla afero, kvankam ne ĉiuj povas pagi ĉi tiun lukson, sed ĉi tio estas kion mi ĉiam faras, ĉi tio estas la sekva. Se nova projekto komenciĝas, tiam kutime ĉiuj neprovitaj praktikoj estas tuj ŝtopitaj en ĉi tiun projekton. Dum la projekto estas juna, ni vere riskas nenion. Ankoraŭ ne ekzistas Prod, estas nenio por detrui. Tial ĝi povas esti uzata kiel trejnado. Ĉi tiu aliro funkcias. Sed ne ĉiuj kompanioj havas la ŝancon komenci tiajn projektojn ofte. Kvankam ĉi tio ankaŭ estas iom stranga, ĉar nun estas kompleta cifereca transformo, ĉiuj devas lanĉi eksperimentojn por teni kun konkurantoj.
Ĉi tie vi venas al la konkludo, ke vi unue devas kompreni tion, kion vi devas fari. La mondo ne estas ideala, kaj prod ankaŭ ne estas ideala.
Jes, ĉi tiuj aferoj estas interligitaj.
Komercoj ankaŭ ne ĉiam komprenas, ke ili devas iri ĉi tiun vojon.
Estas situacio, en kiu tute ne eblas ŝanĝoj. Ĉi tio estas situacio kie estas pli da premo sur la teamo. La teamo jam estas sufiĉe elĉerpita. Ŝi ne havas liberan tempon por iuj eksperimentoj. Ili laboras pri funkcioj de mateno ĝis vespero. Kaj la administrado havas pli kaj malpli da funkcioj. Pli kaj pli estas postulataj. En tia situacio, neniuj ŝanĝoj estas eblaj. Oni povas nur diri al la teamo, ke morgaŭ ni faros la samon kiel hieraŭ, ni nur bezonas fari iom pli da funkcioj. En ĉi tiu senco, neniuj transiroj al iuj praktikoj estas eblaj. Ĉi tio estas klasika situacio, kiam ne estas tempo por akrigi la hakilon, arboj devas esti tranĉitaj, do ili tranĉas ĝin per obtuza hakilo. Ne estas simplaj konsiletoj ĉi tie.
(Dmitry) Mi legos klarigon el la babilejo: "Sed ni bezonas multan testan priraportadon je malsamaj niveloj. Kiom da tempo estas asignita por testoj? Ĝi estas iom multekosta kaj prenas multan tempon."
(Oleg) Ĉi tio estas klasika miskompreniĝo. Devus ekzisti sufiĉe da testoj por ke vi estu certa. Daŭra Integriĝo ne estas afero, kie 100% de la testoj estas faritaj unue kaj nur tiam vi komencas apliki ĉi tiun praktikon. Daŭra Integriĝo reduktas vian kognan ŝarĝon pro la fakto, ke ĉiu el la ŝanĝoj, kiujn vi vidas per viaj okuloj, estas tiel evidenta, ke vi komprenas, ĉu ĝi rompos ion aŭ ne, eĉ sen provoj. Vi povas rapide testi ĉi tion en via kapo ĉar la ŝanĝoj estas malgrandaj. Eĉ se vi havas nur manajn testilojn, estas pli facile ankaŭ por ili. Vi elruliĝis kaj diris: "Rigardu, ĉu io estas rompita?" Ili kontrolis kaj diris: "Ne, nenio estas rompita." Ĉar la testinto scias kien serĉi. Vi havas unu kommit asociita kun unu peco de kodo. Kaj ĉi tio estas ekspluatata per specifa konduto.
Ĉi tie vi, kompreneble, plibeligis.
(Dmitry) Mi ne konsentas ĉi tie. Estas praktiko - test-movita evoluo, kiu savos vin de ĉi tio.
(Oleg) Nu, mi ankoraŭ ne alvenis al tiu punkto. La unua iluzio estas, ke vi devas skribi 100% de la testoj aŭ vi tute ne bezonas fari Daŭran Integriĝon. Ĝi ne estas vera. Ĉi tiuj estas du paralelaj praktikoj. Kaj ili ne estas rekte dependaj. Via testa kovrado devas esti optimuma. Optimuma - ĉi tio signifas, ke vi mem certas, ke la kvalito de la majstro, en kiu via majstro restis post la devoto, permesas vin memfide premi la butonon "Deploji" en ebria vendredo vespere. Kiel vi atingas ĉi tion? Per revizio, per kovrado, per bona monitorado.
Bona monitorado estas nedistingebla de testoj. Se vi faras testojn unufoje pri antaŭprodukto, tiam ili unufoje kontrolas ĉiujn viajn uzantskriptojn kaj jen ĝi. Kaj se vi kuras ilin en senfina buklo, tiam ĉi tiu estas via deplojita monitora sistemo, kiu senfine testas ĉion - ĉu ĝi kraŝis aŭ ne. En ĉi tiu kazo, la sola diferenco estas ĉu ĝi estas farita unufoje aŭ dufoje. Tre bona aro da testoj... kuranta senfine, ĉi tio estas monitorado. Kaj taŭga monitorado devus esti tia.
Kaj tial, kiel precize vi atingos ĉi tiun staton kiam vi pretiĝos vendrede vespere kaj iros hejmen, estas alia demando. Eble vi estas nur aŭdaca fripono.
Ni reiru iomete al Daŭra Integriĝo. Ni forkuris en iomete malsaman kompleksan praktikon.
Kaj la dua iluzio estas, ke MVP, ili diras, devas esti farita rapide, do provoj tie tute ne necesas. Ne certe tiamaniere. La fakto estas, ke kiam vi skribas uzantrakonton en MVP, vi povas aŭ disvolvi ĝin sur la pilko, tio estas, vi aŭdis, ke estis ia uzantrakonto kaj tuj kuris por kodi ĝin, aŭ vi povas labori uzante TDD. Kaj laŭ TDD, kiel praktiko montras, ĝi ne daŭras pli longe, t.e. provoj estas kromefiko. La praktiko de TDD ne temas pri testado. Malgraŭ tio, kion oni nomas Test Driven Development, tute ne temas pri testoj. Ĉi tio ankaŭ estas prefere arkitektura aliro. Ĉi tio estas aliro por skribi ĝuste tion, kio estas bezonata kaj ne skribi tion, kio ne estas bezonata. Ĉi tio estas praktiko koncentriĝi pri la sekva ripeto de via pensado pri kreado de aplika arkitekturo.
Tial, ne estas tiel facile forigi ĉi tiujn iluziojn. MVP kaj testoj ne kontraŭdiras unu la alian. Eĉ, prefere, male, se vi faras MVP uzante TDD-praktikon, tiam vi faros ĝin pli bone kaj pli rapide ol se vi faros ĝin tute sen praktiko, sed sur pilko.
Ĉi tio estas tre nekomprenebla kaj kompleksa ideo. Kiam vi aŭdas, ke nun mi skribos pli da testoj kaj samtempe mi faros ion pli rapide, tio sonas absolute neadekvate.
(Dmitry) Multaj homoj ĉi tie, kiam ili nomas MVP, homoj estas tro maldiligentaj por skribi ion normalan. Kaj ĉi tiuj ankoraŭ estas malsamaj aferoj. Ne necesas igi MVP iun malbonan aferon, kiu ne funkcias.
Jes, jes, vi pravas.
Kaj tiam subite MVP en prod.
Por ĉiam kaj eterne.
Kaj TDD sonas tre nekutima kiam vi aŭdas, ke vi skribas testojn kaj ŝajnas fari pli da laboro. Ĝi sonas tre strange, sed fakte ĝi fariĝas pli rapide kaj pli bela tiamaniere. Kiam vi skribas teston, vi jam multe pensas en via kapo pri kia kodo estos nomata kaj kiel, kaj ankaŭ kian konduton ni atendas de ĝi. Vi ne simple diras, ke mi skribis iun funkcion kaj ĝi faras ion. Unue vi pensis, ke ŝi havas tiajn kaj tiajn kondiĉojn, oni alvokos ŝin en tia kaj tia maniero. Vi kovras ĉi tion per testoj kaj el tio vi komprenas kiel viaj interfacoj aspektos en via kodo. Ĉi tio havas grandegan efikon sur arkitekturo. Via kodo aŭtomate fariĝas pli modula, ĉar vi unue provas kompreni kiel vi provos ĝin, kaj nur poste skribos ĝin.
Kio okazis al mi kun TDD estis, ke iam mi dungis Ruby-mentoron kiam mi ankoraŭ estis Ruby-programisto. Kaj li diras: "Ni faru ĝin laŭ TDD." Mi pensis: "Diable, nun mi devas skribi ion kroman." Kaj ni konsentis, ke ene de du semajnoj mi skribus la tutan funkciantan kodon en Python uzante TDD. Post du semajnoj, mi konstatis, ke mi ne volas reiri. Post du semajnoj de provado apliki ĉi tion ĉie, vi rimarkas kiom pli facile fariĝis por vi eĉ nur pensi. Sed ĉi tio ne estas evidenta, do mi rekomendas al ĉiuj, ke se vi havas la senton, ke TDD estas malfacila, temporaba kaj nenecesa, provu resti kun ĝi nur du semajnojn. Du sufiĉis por mi.
(Dmitry) Ni povas vastigi ĉi tiun ideon de la vidpunkto de infrastruktura operacio. Antaŭ ol ni lanĉas ion novan, ni faras monitoradon kaj poste lanĉas. En ĉi tiu kazo, monitorado fariĝas normala testado por ni. Kaj estas evoluo per monitorado. Sed preskaŭ ĉiuj diras, ke ĝi estas longa, mi estas mallaborema, mi faris provizoran skizon. Se ni faris normalan monitoradon, ni komprenas la staton de la CI-sistemo. Kaj la CI-sistemo havas multan monitoradon. Ni komprenas la staton de la sistemo, ni komprenas kio estas en ĝi. Kaj dum evoluo, ni nur faras la sistemon por ke ĝi atingu la deziratan staton.
Ĉi tiuj praktikoj estas konataj delonge. Ni diskutis ĉi tion antaŭ ĉirkaŭ 4 jaroj. Sed en 4 jaroj preskaŭ nenio ŝanĝiĝis.
Sed pri ĉi tiu noto, mi proponas fini la oficialan diskuton.
Video (enigita kiel amaskomunikila elemento, sed ial ne funkcias):
fonto: www.habr.com