Tahattomasti vahingoittaminen Gitillä voi olla aivan liian helppoa. Silti paras tapa käyttää Mennä on aina kiistanalainen.

Tämä johtuu siitä, että Git itse kuvaa vain haarautumisen perustoiminnot, mikä jättää sen käyttötavat - eli haarautumismallit - käyttäjän mielipiteeksi. Git-haarautumismallit lupaavat lievittää kipua järjestämällä kaaoksen, joka väistämättä syntyy, kun ohjelmistokehittäjät tekevät muutoksia koodikantoihinsa.

Kuten monet kehittäjät, halusit jotain, joka 'vain toimisi', jotta voisit jatkaa todellista ohjelmistokehitystä. Joten otit Git virtaus , haarautuva malli, jota suositellaan usein Git-käyttäjille. Ehkä olit aluksella alun perin Git flown logiikalla, kunnes löysit sen kanssa joitain pilkkuja käytännössä. Tai ehkä Git flow ei tunnu tarpeeksi hyvältä, jotta voit hyväksyä sen. Loppujen lopuksi pelissä on lukemattomia muuttujia, eikä mikään yksittäinen haarautumismalli toimi hyvin kaikissa tilanteissa.

Hyviä uutisia! Muunnelma klassisesta Git-virtausmallista, parannettu Git-virtaus yksinkertaistaa Git flow -työnkulun yleisempiä liikkeitä säilyttäen samalla tärkeimmät edut.

Klassisen Git Flow -mallin loisto ja kurjuus

Olen ollut vahva Git flow: n puolestapuhuja siitä lähtien, kun huomasin sen erinomaisen kehitettäessä tuotetta, joka kehittyy merkittävät arvon lisäykset (toisin sanoen, julkaisut ).

Merkittävä arvon lisäys vaatii huomattavan paljon aikaa, kuten tyypillisesti käytettävät kahden viikon plus-sprintit Scrum -pohjainen kehitys. Jos kehitystiimi on jo lähettänyt tuotannon, voi olla ongelmia, jos seuraavan julkaisun laajuus kerääntyy samaan paikkaan, jossa tuotantokoodi asuu - esimerkiksi käyttämänsä Git-repon päähaarassa.

Vaikka tuote on vielä alkuvaiheessa - ts. Tuotanto ei ole käynnissä eikä tuotteella ole todellisia käyttäjiä - on hyvä, että tiimi pitää kaiken vain päähaaran sisällä. Itse asiassa se on enemmän kuin kunnossa: Tämä strategia mahdollistaa nopeimman kehityksen ilman suuria seremonioita. Mutta tuotantoympäristössä asiat muuttuvat; sitten todelliset ihmiset alkavat luottaa siihen, että tuote on vakaa.

Esimerkiksi, jos tuotannossa on kriittinen vika, joka on korjattava välittömästi, olisi suuri katastrofi, jos kehitystiimi joutuisi palauttamaan kaiken päähankkeessa tähän mennessä kertyneen työn pelkästään korjauksen käyttöönottamiseksi. Koodin käyttöönotto ilman asianmukaista testausta - riippumatta siitä, pidetäänkö koodia puolivalmiina vai hyvin kehittyneenä - ei selvästikään ole vaihtoehto.

Siellä haarautuvat mallit loistavat, mukaan lukien Git flow. Kaikkien hienostuneiden haarautumismallien tulisi vastata kysymyksiin siitä, miten eristää seuraava julkaisu järjestelmän tällä hetkellä käyttämästä versiosta, miten päivittää versio seuraavan version kanssa ja miten käyttöön hotfix-korjauksia kaikista kriittisistä virheistä nykyiseen versioon.

Git-virtausprosessi käsittelee näitä perustilanteita erottamalla 'pää' (tuotanto- tai 'nykyinen versio' -haara) ja 'kehittää' (kehitys- tai 'seuraava julkaisu' -haara) ja antamalla kaikki säännöt ominaisuus- / julkaisu / hotfix-haarojen käytöstä . Se ratkaisee tehokkaasti paljon päänsärkyä julkaisupohjaisten tuotteiden kehittämisen työnkulkuista.

Mutta vaikka klassiseen Git-virtausmalliin hyvin sopivat projektit, olen kokenut tyypillisiä ongelmia, joita se voi aiheuttaa:

• Git-virtaus on monimutkainen, ja siinä on kaksi pitkäikäistä haaraa, kolmen tyyppisiä väliaikaisia ​​haaroja ja tiukat säännöt siitä, kuinka oksat käsittelevät toisiaan. Tällainen monimutkaisuus tekee virheistä todennäköisempiä ja lisää niiden korjaamiseen tarvittavaa työtä.
• Julkaisu- ja hotfix-haarat edellyttävät 'kaksinkertaista sulauttamista' - kerran pää-, sitten kehitystyöhön. Toisinaan voit unohtaa tehdä molemmat. Voit tehdä Gitin virtauksen haarautumisesta helpompaa komentosarjoilla tai VCS GUI -työasemaohjelman laajennuksilla, mutta sinun on ensin määritettävä ne jokaiselle projektissa mukana olevan kehittäjän jokaiselle koneelle.
• CI / CD-työnkulkuissa päädyt yleensä kahteen julkaisun viimeiseen koontiversioon - yksi itse haaran uusimmasta sitoutumisesta ja toinen yhdistämissitoumuksesta pääohjelmaan. Tarkkaan ottaen sinun tulee käyttää päälaitetta, mutta nämä kaksi ovat yleensä identtisiä, mikä aiheuttaa sekaannusta.

Syötä Enhanced Git Flow

Ensimmäistä kertaa käytin tehostettua Git-virtausta viheralueella, suljetun lähdekoodin projektissa. Työskentelin yhden muun kehittäjän kanssa, ja olimme työskennelleet projektin suhteen sitoutumalla suoraan päähaaraan.

Huomaa: Tuotteen ensimmäiseen julkiseen julkaisuun asti on ehdottoman järkevää sitouttaa kaikki muutokset suoraan päähaaraan - vaikka olisitkin Git flow: n puolestapuhuja - kehitystyönkulun nopeuden ja yksinkertaisuuden vuoksi. Koska tuotantoa ei vielä ole, ei ole mahdollista tuotantovirhettä, jonka tiimin on korjattava ASAP. Kaiken haaroittumisen taika, jonka klassinen Git-virtaus merkitsee, on siis tässä vaiheessa ylenmääräistä.

Sitten pääsimme lähelle alkuperäistä julkaisua ja sovimme, että sen jälkeen emme olisi enää mukavia sitoutua suoraan päähaaraan. Olimme siirtyneet melko nopeasti, ja liiketoiminnan prioriteetit eivät jättäneet paljon tilaa vakaan kehitysprosessin luomiselle - ts. Sellaiselle, jolla oli tarpeeksi automatisoituja testejä, jotta voimme luottaa siihen, että päähaaramme pysyi julkaisuvalmis tilassa.

Se näytti olevan kelvollinen tapaus klassiselle Git-virtausmallille. Kun erilliset pää- ja kehityshaarat ja riittävä aika merkittävien lisäysvälien välillä, luotettiin siihen, että enimmäkseen manuaalinen laadunvalvonta tuottaa riittävän hyviä tuloksia. Kun kannatin Git-virtausta, kollegani ehdotti jotain vastaavaa, mutta joillakin keskeisillä eroilla.

Aluksi työnsin taaksepäin. Minusta tuntui, että jotkut klassisen Git-virtauksen ehdotetuista 'korjaustiedostoista' olivat hieman liian vallankumouksellisia. Luulin, että he saattavat rikkoa pääidean, ja koko lähestymistapa puuttuu. Mutta tarkemmin ajatellen tajusin, että nämä tweaksit eivät todellakaan hajota Git-virtausta. Samaan aikaan he tekevät siitä paremman Git-haarautumismallin ratkaisemalla kaikki edellä mainitut kipupisteet.

Menestyksen jälkeen muokatulla lähestymistavalla kyseisessä projektissa olen käyttänyt sitä toisessa suljetun lähdekoodin projektissa, jonka takana on pieni tiimi. Olin ajoittain koodikannan pysyvä omistaja ja ulkoistettu kehittäjä. Tämän projektin aikana menimme tuotantoon kuuden kuukauden kuluttua, ja siitä lähtien olemme käyttäneet CI- ja E2E-testejä yli vuoden ajan, ja julkaisut julkaistaan ​​joka kuukausi.

Kokemukseni tästä uudesta haarautumisesta oli niin myönteistä, että halusin jakaa sen muiden kehittäjien kanssa auttaakseni heitä kiertämään klassisen Git-virtauksen haittoja.

Yhtäläisyyksiä Classic Git Flow: Kehityksen eristäminen

Työn eristämiseen parannetussa Git-virtauksessa on edelleen kaksi pitkäikäistä haaraa, pää- ja kehityskohteet. (Käyttäjillä on edelleen hotfix- ja julkaisuominaisuuksia - painottaen 'ominaisuuksia', koska nämä eivät ole enää haaroja. Tarkastelemme yksityiskohtia erot-osiossa.)

Klassisten Git flow -ominaisuuksien haaroille ei ole virallista nimeämisjärjestelmää. Voit vain haarautua kehityksestä ja sulautua takaisin kehittämään, kun ominaisuus on valmis. Joukkueet voivat käyttää mitä tahansa haluamaansa nimityskäytäntöä tai yksinkertaisesti toivoa, että kehittäjät käyttävät kuvaavampia nimiä kuin 'oma haara'. Sama pätee parannettuun Git-virtaukseen.

Kaikki kehityshaaraan kertyneet ominaisuudet johonkin raja-arvoon asti muokkaavat uutta julkaisua.

Squash sulautuu

Suosittelen voimakkaasti squash-yhdistämisen käyttämistä ominaisuushaaroille, jotta historia pysyy hyvänä ja lineaarisena suurimman osan ajasta. Ilman sitä sitoutuvat kaaviot (GUI-työkaluista tai git log --graph) alkavat näyttää huolimattomilta, kun joukkue jongleeraa jopa kourallisella ominaisuushaaralla:

Mutta vaikka olisitkin kunnossa tämän skenaarion visuaalien kanssa, on toinenkin syy puristuksiin. Tee historianäkymiä törmäämättä - molemmat tavalliset git log (ilman --graph) ja myös GitHub - kerro melko epäjohdonmukaisia ​​tarinoita yksinkertaisimmillakin yhdistämisskenaarioilla:

Squash-yhdistämisen varoitus on, että alkuperäinen ominaisuushaaran historia katoaa. Mutta tämä huomautus ei koske edes, jos käytät esimerkiksi GitHubia paljastaa koko alkuperäisen historian ominaisuushaarasta vetopyynnön kautta, joka oli sulautettu, jopa sen jälkeen, kun ominaisuushaara itse poistettiin.

Eroja Classic Git Flow: julkaisuihin ja hotfix-korjauksiin

Käydään läpi julkaisusykli, koska (toivottavasti) se on tärkein asia, jonka teet. Kun pääsemme siihen pisteeseen, jossa haluaisimme vapauttaa kehityksessä kertyneen, se on ehdottomasti pääjoukko. Sen jälkeen alkaa suurimmat erot klassisen ja parannetun Git-virtauksen välillä.

Enhanced Git Flow -julkaisut

Jokainen parannetun Git-virtauksen sisältävän julkaisun tekemisen vaihe eroaa klassisesta Git-virtausprosessista:

1. Julkaisut perustuvat pikemminkin pää- kuin kehitystyöhön. Merkitse päähaaran nykyinen kärki jotain mielekästä. Hyväksyin tunnisteet nykyisen päivämäärän perusteella ISO 8601 -muodossa, johon on lisätty ”v” - esim. v2020-09-09 .
   • Jos päivässä sattui olemaan useita julkaisuja - esimerkiksi hotfix-korjauksia -, muotoon saattoi olla kiinnitetty järjestysnumero tai kirjain tarpeen mukaan.
   • Huomaa, että tunnisteet eivät yleensä vastaa julkaisupäiviä. He vain pakottavat Gitin pitämään viitteen siitä, miltä päähaara näytti seuraavan julkaisuprosessin alkaessa.
2. Työnnä tunnistetta käyttämällä git push origin .
3. Sen jälkeen pieni yllätys: poista paikallinen päähaara . Älä huoli, koska aiomme palauttaa sen pian.
   • Kaikki tärkeimmät sitoutuminen ovat edelleen turvallisia - suojelimme niitä roskien keräämisestä merkitsemällä edelliselle vaiheelle main. Jokainen näistä sitoumuksista - jopa hotfix-korjaukset, kuten käsittelemme pian - on myös osa kehitystä.
   • Varmista vain, että vain yksi henkilö joukkueessa tekee tämän jokaiselle julkaisulle; se on niin kutsuttu 'julkaisupäällikkö' -rooli. Julkaisupäällikkö on yleensä kokenein ja / tai vanhin tiimin jäsen, mutta joukkue olisi viisasta välttää tiettyä tiimin jäsentä ottamasta tätä roolia pysyvästi. On järkevämpää levittää tietoa tiimin keskuudessa pahamaineisuuden lisäämiseksi väyläkerroin .
4. Luo uusi paikallinen päähaara sivuliikkeesi kehitystyön yhteydessä .
5. Työnnä tätä uutta rakennetta painamalla git push --force , koska etärepo ei hyväksy niin dramaattista muutosta niin helposti. Jälleen, tämä ei ole niin vaarallista kuin se voi tuntua tässä yhteydessä, koska:
   • Siirrämme vain päähaaran osoittimen sitoutumisesta toiseen.
   • Vain yksi tiimin jäsen tekee tämän muutoksen kerrallaan.
   • Arjen kehitystyö tapahtuu kehitystoimialalla, joten et häiritse kenenkään työtä siirtymällä päähän tällä tavalla.
6. Sinulla on uusi julkaisusi! Ota se käyttöön lavastusympäristössä ja testaa se. (Keskustelemme alla olevista kätevistä CI / CD-malleista.) Kaikki korjaukset menevät suoraan päähaaraan, ja se alkaa poiketa kehityshaarasta sen vuoksi.
   • Samaan aikaan voit alkaa työskennellä uuden julkaisun parissa kehityshaarassa, sama etu kuin perinteisessä Git-virtauksessa.
   • Siinä valitettavassa tapauksessa, että hotfix-korjausta tarvitaan tällä hetkellä tuotannossa olevaan tuotteeseen (ei tulevaan julkaisuvaiheeseen) tässä vaiheessa, on lisätietoja tästä tilanteesta jäljempänä kohdassa 'Korjausten korjaaminen aktiivisen julkaisun aikana ...'.
7. Kun uuden julkaisusi katsotaan olevan riittävän vakaa, ottaa lopullinen versio käyttöön tuotantoympäristössä ja tee yksi squash-yhdistelmä pääkehitystä kehitettäväksi poimia kaikki korjaukset.

Korjatut parannetut Git Flow -ominaisuudet

Hotfix-korjaustapauksia on kaksi. Jos teet hotfix-korjausta kun aktiivista julkaisua ei ole Toisin sanoen tiimi valmistelee uutta julkaisua kehityshaarassa - se on helppoa: sitoutu pääkäyttöön, ota muutokset käyttöön ja testaa vaiheistuksessa, kunnes ne ovat valmiita, ja ota sitten käyttöön tuotantoon.

Viimeisenä vaiheena, valitse kirsikkasi sitoumus pääkeskuksesta kehittääksesi, jotta seuraava julkaisu sisältää kaikki korjaukset. Jos päätät tehdä useita hotfix-korjauksia, säästät vaivaa - varsinkin jos IDE tai muu Git-työkalu voi helpottaa sitä - luomalla ja asentamalla korjaustiedoston sen sijaan, että poimit kirsikoita useita kertoja. Yritetään sulattaa pääyhdistelmä kehittymään alkuperäisen julkaisun jälkeen todennäköisesti johtaa ristiriitoihin kehityshaarassa saavutetun itsenäisen edistymisen kanssa, joten en suosittele sitä.

Korjausten korjaaminen aktiivisen vapautuksen aikana - toisin sanoen, kun pakotat vain työnnettyä päälaitetta ja valmistelet edelleen uutta julkaisua, on parannetun Git-virtauksen heikoin osa. Julkaisusyklin pituudesta ja selvitettävän ongelman vakavuudesta riippuen pyrki aina sisällyttämään korjaukset uuteen julkaisuun - se on helpoin tapa edetä eikä häiritse työnkulkua lainkaan.

Jos tämä on ei-go-sinun on otettava käyttöön korjaus nopeasti, etkä voi odottaa uuden julkaisun valmistumista, valmistaudu sitten hieman monimutkaiseen Git-menettelyyn:

1. Luo haara - kutsumme sitä uudeksi julkaisuksi, mutta tiimisi voi hyväksyä minkä tahansa nimeämiskäytännön täällä - samalla sitoutumisella kuin nykyinen pääkärki. Työnnä uusi julkaisu.
2. Poista ja luo paikallinen päähaara aiemmin luotua tagia varten nykyiselle aktiiviselle julkaisulle. Pakota työntö pää.
3. Ota käyttöön tarvittavat korjaukset pääkäyttöön, käyttöönotto vaiheistettuun ympäristöön ja testaus. Aina kun se on valmis, ota käyttöön tuotantoon.
4. Edistä muutoksia nykyisestä pääversiosta uuteen julkaisuun joko kirsikkanäppäimen tai korjaustiedoston avulla.
5. Tämän jälkeen tee uudelleen vapautustapa: Merkitse nykyisen pääkärjen kärki ja työnnä tunnistetta, poista ja luo uusi päähakemisto uuden vapautushaaran kärjestä ja pakota työntöpää.
   1. Et todennäköisesti tarvitse edellistä tunnistetta, joten voit poistaa sen.
   2. Uuden julkaisun haara on nyt tarpeeton, joten voit myös poistaa sen.
6. Sinun pitäisi nyt olla hyvä mennä tavalliseen tapaan uuden julkaisun kanssa. Viimeistele levittämällä hätäkorjauskorjaukset pääkehityksestä kirsikan poiminnan tai korjaustiedoston avulla.

Asianmukaisella suunnittelulla, riittävän korkealla koodilaadulla sekä terveellä kehityksellä ja laadunvalvontakulttuurilla tiimisi ei todennäköisesti tarvitse käyttää tätä menetelmää. Oli järkevää kehittää ja testata tällainen katastrofisuunnitelma Git-virran parantamiseksi joka tapauksessa - mutta en ole koskaan tarvinnut käyttää sitä käytännössä.

CI / CD-asetukset parannetun Git Flow -laitteen päällä

Kaikki projektit eivät vaadi erillistä kehitysympäristöä. Voi olla tarpeeksi helppoa luoda kehittyneitä paikallisia kehitysympäristöjä jokaiselle kehittäjäkoneelle.

Omistettu kehitysympäristö voi kuitenkin edistää terveellisempää kehityskulttuuria. Testien suorittaminen, testien kattavuuden mittaaminen ja monimutkaisuusmittareiden laskeminen kehityshaaralla vähentää usein virheiden kustannuksia tarttumalla niihin hyvissä ajoin ennen kuin ne päätyvät lavastukseen.

Huomasin, että jotkut CI / CD-mallit ovat erityisen hyödyllisiä yhdistettynä parannettuun Git-virtaukseen:

• Jos tarvitset kehitysympäristöä, määritä käyttöliittymä rakentamaan, testaamaan ja ottamaan käyttöön sen jälkeen, kun olet sitoutunut kehittämishaaraan. Sovi myös E2E-testaukseen, jos sinulla on se ja jos se on järkevää sinun tapauksessasi.
• Määritä käyttöliittymä rakentamaan, testaamaan ja ottamaan käyttöön vaiheittainen ympäristö jokaisessa päähaaran sitoutumisessa. E2E-testaus on myös tässä vaiheessa varsin hyödyllistä.
  • Voi tuntua turhalta käyttää E2E-testausta molemmissa paikoissa, mutta muista, että hotfix-korjauksia ei tapahdu kehityksessä. E2E: n käynnistäminen pääkäyttäjille testaa hotfix-korjaukset ja jokapäiväiset muutokset ennen kuin ne menevät ulos, mutta myös sitoutumisen kehittäminen käynnistää virheet aikaisemmin.
• Määritä käyttöliittymä tavalla, joka antaa tiimillesi mahdollisuuden rakentaa rakennuksia pääkäytöstä tuotantoympäristöön manuaalisen pyynnön perusteella.

Tällaiset mallit ovat suhteellisen yksinkertaisia, mutta tarjoavat tehokkaan koneiston päivittäisen kehitystoiminnan tukemiseksi.

Parannettu Git Flow -malli: parannukset ja mahdolliset rajoitukset

Parannettu Git-virtaus ei ole kaikille. Se hyödyntää kiistanalaista taktiikkaa voiman työntämiseksi päähaaraa, joten puristit voivat paheksua sitä. Käytännössä ei kuitenkaan ole mitään vikaa.

Kuten mainittiin, hotfix-korjaukset ovat haastavampia julkaisun aikana, mutta silti mahdollisia. Kun laadunvalvontaan, testikattavuuteen jne. Kiinnitetään asianmukaista huomiota, sen ei pitäisi tapahtua liian usein, joten näkökulmastani se on pätevä kompromissi parannetun Git-virtauksen yleisten hyötyjen suhteen verrattuna klassiseen Git-virtaukseen. Olisin erittäin kiinnostunut kuulemaan, kuinka parannetut Git-virtahinnat suuremmissa tiimeissä ja monimutkaisemmissa projekteissa, joissa hotfix-korjaukset voivat olla yleisempiä.

Myönteinen kokemukseni parannetusta Git-virtausmallista pyörii myös lähinnä suljetun lähdekoodin kaupallisten projektien ympärillä. Se voi olla ongelmallista avoimen lähdekoodin projektille, jossa vetopyynnöt perustuvat usein lähdekoodin vanhaan julkaisujohdantoon. Tämän ratkaisemiseksi ei ole teknisiä esteitä - se saattaa vain edellyttää odotettua enemmän ponnisteluja. Olen tyytyväinen lukijoiden palautteeseen, jolla on paljon kokemusta avoimen lähdekoodin tilassa parannetun Git-virtauksen sovellettavuudesta tällaisissa tapauksissa.

Erityiset kiitokset ApeeScape-kollegalle Antoine Pham avainroolistaan ​​parannetun Git-virtauksen taustalla olevan idean kehittämisessä.

---

Lisätietoja ApeeScape Engineering -blogista:

• Runkopohjainen kehitys vs. Git Flow
• Git-työnkulut ammattilaisille: Hyvä Git-opas

---

Kuten a Microsoft Gold -kumppani , ApeeScape on eliittisi Microsoft-asiantuntijoiden verkosto. Rakenna korkean suorituskyvyn omaavia tiimejä tarvitsemiesi asiantuntijoiden kanssa - missä tahansa ja juuri silloin, kun tarvitset niitä!

Perustietojen ymmärtäminen

Mikä on Git flow?

Git flow on haarautuva malli Git-versionhallintajärjestelmälle (VCS). Haarautumismalli perustuu Git-perustoimintoihin ja määrittelee käyttötavat, joiden tarkoituksena on mahdollistaa vankka versionhallinta. Vincent Driessen ilmoitti julkisesti Git Flow -blogiartikkelista vuonna 2010, ja se on pysynyt suosittuna siitä lähtien.

Mikä on Git-virtauksen haarautumisstrategia?

Git-virtauksen haarautumisstrategia on erinomainen, kun kehitetään tuotetta, joka kehittyy merkittävissä arvon lisäyksissä. Se tekee niin erottamalla pää- (tuotanto- tai 'nykyinen versio' -haara) ja 'kehittää' (kehitys- tai 'seuraava julkaisu' -haara) ja antamalla kaikki tarvittavat säännöt auttajahaarojen käytöstä.

Kuinka voin käyttää Git-virtausta?

Käytät Git-virtausta noudattamalla sen määrittelemää mallia. Tämän avulla tiimisi saa vastauksia kysymyksiin siitä, kuinka seuraava julkaisu eristetään tällä hetkellä tuotannossa olevasta järjestelmän versiosta, kuinka tämä versio päivitetään seuraavalla versiolla ja kuinka kaikkien kriittisten virheiden hotfix-korjaukset otetaan käyttöön nykyiseen versioon.

Pitäisikö minun käyttää Git flow -ohjelmaa?

Käytätkö Git flow -ohjelmaa vai ei, riippuu projektistasi. Tärkein vastattava kysymys on: 'Onko yleisellä kehitystyönkululla riittävästi automaattista laadunvarmistusta pitääkseen päähaara vapaana valmiina?' Jos vastaus on kieltävä, tällainen projekti hyötyy todennäköisesti Git-virtauksesta.

Mikä on paras Git-työnkulku?

Parhaan Git-työnkulun ei ole olemassa, koska vastaus riippuu tietystä projektikontekstista. Jotkut projektit hyötyvät Git-virtauksesta tai sen muunnelmasta, kun taas toiset ovat parempia runkopohjaisen kehitystavan avulla.