Haarakepohjaisessa versiossa meidän täytyy puhua seuraavasta kaaviosta, joka havainnollistaa täydellisesti konfiguraation hallintaprosessin kokonaisuutta. Ensinnäkin tämä kaavio on kirjoitettu Git-mallin pohjalta, mutta todellisuudessa Git ja Subversion ovat kehittäneet versionhallinnan käsitteen, mutta Git tekee laadullisen harppauksen eteenpäin Subversioniin verrattuna haarahallinnassa ja hajautetussa suorituskyvyssä (mutta tämä ei ole tämän artikkelin pääpaino).
Ennen kuin esittelemme tämän graafin periaatteen, puhutaan kahdesta eri strategiasta yleiseen versionhallintaan: toinen on "pioneer-runko, stabiili haara" ja toinen "stabiili selkäranka, pioneerihaara". Kuten nimikin kertoo, kyseessä on vakaa versio (tuotantoversio), joko runko- tai haaralla. Perinteisten VSS:ää käyttävien projektitiimien tapauksessa on vaikea sanoa, mihin tilaan se kuuluu, pääasiassa siksi, että VSS:llä ei ole haarahallinnan strategiaa, joten monet projektitiimit perustavat kaksi (tai kolme) versiokirjastoa, jotka vastaavat tuotanto- ja kehitysympäristöä, ja tämä on tietysti myös eräänlaista haarahallinnan muotoa. Jos kuitenkin vaihdat Subversioniin tai Gitiin versionhallintatyökaluna, useimmat tiimit käyttävät vakaata trunk-tilaa, eli tavaratila (kuorma-auto tai master) vastaa vakaata tuotantoympäristöä ja merkitsee eri julkaisut tuotantoversion osoittamiseksi. Henkilökohtaisesti uskon, että vakaa runkopohjainen koodimalli pitäisi olla tällä hetkellä ehdoton valtavirran koodin versionhallintaratkaisu. Yllä oleva kuva on tavanomainen "vakaa selkärangan" hallintamalli.
mestari: Vastaava Subversion on kuorma-auto。 Tuotantoversion mukaisesti se on merkitty kerran jokaisessa julkaisussa.
Release Branch (tunnetaan myös nimellä integraatiohaara): Kunhan tuotanto on päivitetty, se täytyy ensin yhdistää julkaisuhaaraan (integraatiohaara). Se muistuttaa jonkin verran sitä, mitä projektitiimi tällä hetkellä kutsuu "esituotannoksi" ja "simuloiduksi ympäristöksi".
Develop Branch (Dev Branch tai Dev Branch): Kehitysympäristön kohtaama ympäristö.
Feature Branch (Feature Branch): Jotkut itsenäiset funktiot voidaan erottaa erillisestä kehityshaarasta. Tämä on lähinnä siksi, että joidenkin ominaisuuksien päivittäminen voi kestää suhteellisen kauan, jotta julkaisu ja haarat eivät hidastuisi.
Hotfixes -haara (bugikorjaushaara): Tässä bugi on pääasiassa tuotantobugi.
Kun runko ja haarat on esitelty, minun täytyy esitellä näiden haarojen generoinnin ja yhdistymisen suunta.
Master on tuotantoversio, ja runko hyväksyy vain kaksi haara yhdistämiseen, toinen on julkaisuhaara (integraatiohaara) ja toinen hotfixes-haara. Muita haaroja ei voi yhdistää tuotantohaaraksi.
Julkaisuhaara luodaan alun perin samaan aikaan tuotannon kanssa, mikä on täsmälleen sama kuin tuotanto. Hän hyväksyy vain kehityshaaran yhdistymisen siihen. Toisin sanoen, hän ei hyväksy yhdistämistä suoraan ominaisuushaarasta tai bugikorjaushaarasta.
Kehityshaara, kehityshaara, kuten integraatiohaara, on sama kuin tuotantoympäristö tiettynä ajankohtana. Kehityksen edetessä kehitysosastolle tullaan kuitenkin luomaan uusia ominaisuuksia. Dev-teoria hyväksyy vain kahden haaran yhdistämisen, toinen on hotfixit ja toinen ominaisuushaara.
ominaisuushaara, joka alkaa tietystä pisteestä (versiosta) dev-haaran kanssa, ominaisuushaara lopulta yhdistyy kehityshaaraan.
Esitelläänpä lyhyesti versionhallintamenetelmä skenaarion muodossa
Oletetaan, että tuotantoversio on jaettu haaroihin (dev, hotfixes, release), ja tässä vaiheessa dev alkaa kehittää yhteensä kymmentä funktiota. Kun 8 kymmenestä ominaisuudesta oli kehitetty, testaustiimi alkoi puuttua sisäiseen testaukseen, ja konfiguraatiojärjestelmänvalvoja otti dev-haaran käyttöön kehitysympäristöön testattavaksi jatkuvan integraation työkalujen avulla (erillinen aihe tässä). Kun testivarmistuksessa todettiin, että kaksi toimintoa olivat täysin sopimattomia ja ne piti tehdä uudelleen, kuten yksinkertainen vakuutusvakuutus ja korvauspalautus, kaksi ominaisuushaara erotettiin kehityksestä, jotka vastaavat yksinkertaista vakuutusvakuutusta ja korvauspalautusta, ja dev-haarassa vastaava koodi piti myös perua (manuaalinen käyttö tässä). Kun testitiimi toteaa, ettei dev branch -testissä ole ongelmaa, se täyttää UAT:n vaatimukset, joten konfiguraatiojärjestelmänvalvoja yhdistää dev-haaran julkaisuhaaraan ja käyttää jatkuvan integraation työkaluja julkaistakseen haaran esituotantoympäristössä ja luovuttaakseen sen käyttäjälle testattavaksi. Kun käyttäjävahvistus havaitsee ongelman, kehittäjä muokkaa kehityshaaran ja yhdistää sen julkaisuhaaraan (tässä alkuperäisessä kuvassa se on suoraan muokattu julkaisuhaaraan, mielestäni tämä ei ole hyvä, suosittelen että kehittäjä kohtaa vain kehityshaaran), kun verifiointi-julkaisun tarkistusprosessi yhtäkkiä huomaa vakavan bugin rakennusympäristössä, joka täytyy korjata välittömästi, sitä muutetaan kiireellisesti hotfixes-haarassa ja se käynnistetään kiireellisesti sen jälkeen, kun se on varmistettu oikeudesta. Samaan aikaan hotfixes-haara yhdistetään dev-haaraan (tässä se on pääosin manuaalinen, koska tuotantoversio on jo hyvin erilainen kuin dev-versio, eikä automaattista yhdistämistä voi usein toteuttaa), ja sitten dev yhdistetään julkaisuun. Jonkin ajan kuluttua vaatimuksen palautustoimintoa ei välttämättä enää tarvita ja se täytyy peruuttaa, joten vaatimuksen palautustoiminto poistetaan. Toinen ominaisuus on helppo vakuuttaa, ja se on kehitetty ja yhdistetty kehityshaaraan uudelleen seuraavan verkkoversion käyttöönottoa varten.
Yllä oleva skenaario sisältää käytännössä rutiinikehityksen, purkamisen, hätäpäivitykset ja muut skenaariot päivittäisessä kehitysprosessissa.
|
Julkaistu 8.4.2018 10.25.39
|
|
|
|
