Kuinka saada jatkuva integraatio oikealle

Salaisuus, joka toimitetaan täydellä kaasulla, ei koske työkalujasi

Nathaniel Tetteh julkaisussa Unsplash. Näin saavutat jatkuvan integraation.

Olen toiminut ohjelmistokehitysliiketoiminnassa useiden vuosien ajan. Asuminen Berliinissä auttaa minua pitämään yhteyttä valtavaan startup-yhteisöön.

Haluan puhua eri yritysten ihmisten kanssa nähdäksesi, miten heidän prosessinsa näyttävät ja mikä on heidän kulttuurinsa suhteessa joukkueisiin, koodauskäytäntöihin ja laatustandardeihin.

Jatkuvasta integroinnista keskustelun yhteydessä havaitsen mallin, joka on useammin kuin ei. Ei ole harvinaista, että kehittäjät puhuvat siitä ikään kuin kyse olisi vain Jenkinsistä tai Travisista tai mistä tahansa heidän käyttämästään työkalusta.

Jatkuva integraatio tarkoittaa ilmeisesti monissa ympäristöissä yksinkertaisesti työkalun käyttöä, joka tarkistaa viimeisimmän sitoutumisen ja muuttuu punaiseksi tai vihreäksi kuin joulupuu testituloksesta riippuen.

En ole samaa mieltä.

On olemassa perustavanlaatuisia käytäntöjä ja prosesseja, jotka ovat ennen minkä tahansa työkalun käyttämistä ja jotka muodostavat jatkuvan integraation perustan.

Ilman niitä CI ei yksinkertaisesti ole mahdollista.

Tässä postituksessa luetellaan joitain niistä. Mielestäni ne ovat hyvä lähtökohta todellisen jatkuvan integraation saavuttamiselle.

Jos olet joukkueessa, joka kamppailee toimittamisen suhteen tai et pysty hallitsemaan koodauspyrkimyksiäsi joukkueesi ikäisensä kanssa, tämä viesti on sinulle.

Ei ominaisuushaaraa

Kun joukkueet joutuvat kehittämään uutta ominaisuutta, heidän tekemänsä yleinen virhe on avata ominaisuushaaro arkistossaan ja alkaa heittää monia sitoumuksia sen sisälle.

Ajatuksena on eristää itsensä koko projektin laajuisista kehitysprosessien rajoituksista, kunnes ominaisuus on valmis ja ne voidaan yhdistää takaisin masteriksi.

Ominaisuushaaran git-työnkulun edustaminen

Tämän käytännön ajatus on enemmän tai vähemmän ”jos työskentelemme suoraan masterin kanssa ja master on kytketty julkaisusykliin, vapautamme puolituki-ominaisuuden tai jotain, joka ei vielä toimi. Vielä pahempaa, voisimme rikkoa jotain, koska emme ole vielä täysin testanneet koodiamme ”.

Vaikka tämä käytäntö saattaa kuulostaa varovaiselta ja turvallisuuteen suuntautuneelta, se on täysin päinvastainen.

Useimmiten kuin lopputulos on rikki julkaisu heti, kun yhdistät ominaisuushaaran takaisin. Ainoat vaihtoehtosi tässä vaiheessa ovat a) peruuttaa sitoutuminen tai b) korjata julkaisu kuumakorjaamalla.

Jos olet epäonninen, molemmat voivat olla kalliita ja alttiita virheille.

Jos julkaisuprosessiasi ei ole riittävän automatisoitu, niin suuren sitoumuksen palauttaminen voi maksaa sinulle esimerkiksi tietokantarakenteen manuaalisen palauttamisen. Ja mitä teet, jos muutat tuhoisasti tietojasi?

Kuumakiinnitys ei myöskään ole yhtä riskialtista. Käyttäjäkokemuksen häiriöiden minimoimiseksi sinun on vapautettava korjaustiedosto mahdollisimman pian. Ja me kaikki tiedämme, että aikapaine ei tule lainkaan harkittuun kehitykseen. Riski on lisätä virheitä virheiden päälle ja pahentaa tilannetta hyväksyttävän rajan yli.

Miksi ominaisuushaarat eivät toimi

Syy siihen, miksi ominaisuushaarat eivät toimi, on yksinkertainen: et saa jatkuvaa palautetta kehittämisen aikana.

Kun sinä ja tiimisi ette anna sidosryhmällesi mahdollisuutta valvoa jatkuvasti meneillään olevaa työtäsi, menetät yhteyden todellisuuteen.

Sinulla ei ole muuta tapaa vahvistaa kehitystäsi kuin antaa käyttäjän jatkuvasti kirjautua sisään.

Tässä tapauksessa on olemassa suuri virhe, jonka monet kehittäjät ansaitsevat. Usko on, että jos he testaavat koodinsa riittävästi joko kirjoittamalla testejä tai napsauttamalla manuaalisesti, he voivat olla varmoja siitä, että juuri kehittämäsi toimii vain ™.

Tämä on virhe, ja sitä on vältettävä hinnalla millä hyvänsä.

Sikäli kuin voit kehittäjänä yrittää ajatella käyttäjän (käyttäjien) tapaan, et yksinkertaisesti ole. Käyttötapoja ei huomioida eikä niitä toteuteta. Käyttäytymistä ei tule ennakoida, sillä se avasi oven piileviin virheisiin. Liiketoimintaa tai syviä prosesseja ei paljasteta.

Toisin sanoen ohjelmistosi ei toteuta parhaimmillaan todellisuutta. Tai se on helposti rikki eikä se vain toimi, pahimmassa tapauksessa. Molemmissa tapauksissa se näyttää väärin käyttäjän silmissä.

Vaikka Feature Branch -malli saattaa kuulostaa varovaiselta ja turvallisuuteen suuntautuneelta, se on täysin päinvastainen.

Käytä toimintovaihtoehtoja

Ensimmäinen, helppo askel saavuttaa korkea CI-taso on käyttää toimintovaihtoehtoja.

Ominaisuuden vaihtaminen on sovelluksen kokoonpanolippu, joka voi ottaa tietyn ominaisuuden käyttöön ja poistaa sen käytöstä.

Tämä tekniikka on hulluin helppo toteuttaa. Kooditietokannassasi se näyttää enemmän tai vähemmän tältä.

Ominaisuuden vaihtamisen käytön edut ovat seuraavat:

  • voit kytkeä ominaisuuden pois käytöstä tuotannossa tarvitsematta vapauttaa sitä uudelleen. Tämä on hyödyllistä, kun ilmoitetaan kriittinen virhe ja haluat estää käyttäjiä pääsemästä vialliseen ominaisuuteen.
  • voit ottaa ominaisuuden käyttöön kanarian ympäristössä ja antaa sen pois käytöstä. Tämän avulla varhaisessa vaiheessa käyttäjät voivat testata ominaisuutta ja kehitysryhmä kerätä hyödyllistä palautetta ennen virallista julkaisua;
  • voit ottaa ominaisuuden käyttöön suljetussa ympäristössä ja antaa esimerkiksi tuotepäällikölle tarkistaa tekniikan tason, vaikka ominaisuus ei olisi vielä valmis.

On vielä yksi etu, joka avataan, kun aloitat ominaisuuksien vaihtamisen.

Koska ominaisuutesi voidaan sammuttaa tuotannossa, kunnes se on valmis ja vakaa, voit nyt aloittaa sitoumusten yhdistämisen suoraan päähaaroosi.

Pieni sitoutuu suoraan mestarille

On pari pätevää syytä yhdistää sitoumuksesi suoraan päälliköksi noudattamalla tätä mallia.

”Hyppää kala” -fuusiomalli.

Kuka teki tämän?

Ensimmäinen syy on, että saat puhtaamman historian koodistasi. Tiedät tarkalleen, kuka teki mitä. Tämä auttaa paljon, kun muut kehittäjät tarvitsevat selvityksiä koodin tiettyyn osaan.

Ominaisuushaaroilla kaikki toimeksiannot puristetaan yhdeksi ennen yhdistämistä, joten tiedot menetetään ja vain yksi kehittäjä ottaa kaikki (git) syyt.

Helppo yhdistäminen, vähemmän konflikteja, turvallisempi palautuminen

Mitä suurempi ominaisuushaara, sitä suurempi on mahdollisuus, että yhdistät ristiriidat.

Yhdistämisristiriidat voivat olla erittäin tuskallisia, koska niiden ratkaiseminen on puhtaasti manuaalista ja erittäin virhealtista prosessia.

Lisäksi, kun kohtaat yhdistämisristiriitoja, sinun on todennäköisesti muokattava hieman sovelluslogiikkaasi. Tämä tehdään tyypillisesti lennossa rebastoitaessa. Annan sinun kuvitella, mikä voi olla koodauksen laadullinen tulos, kun aivosi ovat keskellä toista tehtävää.

Näin monta kertaa kehittäjien sanovan: “En tiedä mitä tapahtui. Ratkaisin eräitä ristiriitoja ja sekaisin sotkun aikana. Ehkä gitillä on joitain vikoja, mutta epäilen voimakkaasti, että se voi sekoittaa rebase-aikana.

Pienemmät sitoumukset antavat sinun olla turvallisella puolella ja välttää monimutkaisia ​​palautumisia. Ristiriidat ovat minimaaliset ja triviaalit, koska myös muutoksen pintalaajennus on liian.

Pienempiä sitoutumisia on myös helpompi palauttaa psykologisen tekijän takia. Kun työskentelet isojen piirroshaarojen kanssa, raukeama kustannustehokkuutesi torjuu rationaalista harkintasi. Olet vastahakoinen tai pelkäät jopa palauttaa tällaisen määrän koodia.

”Parempi yrittää korjata se. Korjaus on minimaalinen verrattuna koodin määrään. Kaiken tekemämme työn jälkeen ei tarvitse palauttaa kaikkea ”- Kuulostaako sanoilta sinulle tutulta?

Lopulta pienten sitoumusten tulisi olla riittävän pieniä, jotta yksi joukkueen jäsen voi yhdistää jotain mestariksi vähintään kerran päivässä.

Optimoi samanaikainen kehitys

Tässä kohtaa ohjelmistosuunnittelu todella vastaa jatkuvaa integraatiota.

Jopa työskentelemällä erillisten ominaisuushaarojen parissa, ryhmän jäsenet voivat estää toisiaan, jos he eivät jaa ominaisuuden kehitystä tarpeeksi huolellisesti.

On ironista, että suunnittelemme ohjelmistomme irrotettavaksi ja moduulimme olemaan toisistaan ​​riippumattomia, kun taas kehitysprosessimme suunnittelu jättää paljon toivomisen varaa.

Tällainen näyttää tyypillinen yhden ominaisuuden kehitystehtävien aikajakauma.

Guybrushin on aina odotettava, että Elaine suorittaa tehtävänsä loppuun, muuten hän ei voi alkaa työskennellä. Stan on jumissa, kunnes LeChuck ja Elaine toimittavat osansa ja LeChuckille lopulta jää vain yksi tehtävä.

Valitettavasti ominaisuuden kehittämiseen ei ole hopeaa luota, jotta jokainen joukkueen jäsen voisi työskennellä rinnalla jonkin tehtävän kanssa.

Mikä tässä ehdottomasti auttaa, on tarkastella ominaisuutta ohjelmistosuunnittelun näkökulmasta ja yrittää ymmärtää, missä leikkausviivat ovat. Puhun pohjimmiltaan rajapintojen etsimisestä ennen kuin aloitan yhteisten alueiden kehittämisen.

Hyödyllinen heuristiikka on esimerkiksi se, että jos kahden kehittäjän on työskenneltävä kahdella vierekkäisellä alueella, sanotaan esimerkiksi etuosan komponentti ja sen taustan vastine, he voivat sopia etukäteen käyttöliittymästä, jota he käyttävät kahden osan kommunikointiin.

Toinen joukkue voisi sen sijaan soveltaa "kuka saapuu ensin päättää käyttöliittymäsääntöä", jossa kaksi tai useampi kehittäjä aloittaa työskentelyn itsenäisesti ja ensimmäinen, joka saapuu yhteyspisteen määritelmään, määrittelee sen.

Asioita voidaan silti muuttaa, kun muut saapuvat sinne ja näkevät, että määritelmä ei sovi täysin heidän käyttötapaansa. Mutta ainakaan ketään ei ole estetty tällä välin, ja käyttöliittymän parantamisen tarve herättää todennäköisesti terveen keskustelun ryhmän jäsenten keskuudessa ja mielenkiintoisia oivalluksia ominaisuuden suunnittelussa.

johtopäätös

Jatkuva integrointi ei koske työkalusi.

Jatkuva integrointi tarkoittaa sitä, kuinka suunnittelut kehitysprosessisi.

Se vie aikaa ja vaivaa, jotta se toimii sujuvasti.

Tämä tarkoittaa erilaisten synkronointistrategioiden ymmärtämistä ja soveltamista paitsi ryhmän jäsenten lisäksi myös jokaisen ominaisuuden kehittämiseen osallistuvan henkilön keskuudessa.

Sitoumuksesi tarkistaminen testiautomaatioputken suhteen on vain kirsikka päällä.