Skip to content

Tietomallien kehittäminen ja ylläpito

Jump to bottom
Ilkka Rinne edited this page Jan 24, 2023 · 6 revisions

Muokattaessa erillisessä GitHub-repossa ylläpidettävää UML-tietomallia Enterpise Architect:illa (EA) kannattaa toimia seuraavien ohjeiden mukaan, jotta EA:ssa tehtävät muutokset tulevat hallitusti GitHubiin osana Rakennetun ympäristön tietomallien hallintamallin mukaista muutosprosessia.

Seuraavassa oletetaan, että repoa hallitaan OneFlow-menetelmän develop + master -variaation mukaisesti, eli siinä on kaksi pitkä-aikaista haaraa (main/master ja develop), ja kukin kehitystoimenpide tehdään omassa väliaikaisessa feature-haarassaan, joka mergetään takaisin develop-haaraan ja poistetaan kun muutos on valmis. Julkaisuversiot tehdään omissa väliaikaisissa release-haaroissaan halutun develop-commitin kohdalta, viedään versionumero-tageineen takaisiin develop-haaraan, poistetaan release-haara, ja siirretään main-haaran osoitin tehdyn release-tagin kohdalle.

Tässä oletetaan myös, että kaikki tietomallirepot ovat keskitetysti hallittuja sykefi-GitHub -organisaation alla.

Kehityssyklin ylätason vaiheet

Tietomallien kehitysprosessi kulkee seuraavasti:

  1. Muutos- tai lisäystarve kirjataan tietomallirepon issueksi, ja siitä käydään tarpeellinen keskustelu siellä.
  2. Muutostarve käsitellään Rakennetun ympäristön tiedon yhteentoimivuuden yhteistyöryhmä Semanttisen yhteentoimivuuden teemaryhmässä. Mikäli muutosta pidetään tarkoituksenmukaisena, ryhmä antaa sen toteuttamisen toimeksi soveltuvalle aliryhmälle.
  3. Kehittäjätaho tekee oman forkin tietomallireposta ja työstää muutokset omissa feature-haaroissaan ja dokumentoi tehdyt muutokset tietomallin muutosloki-sivulle, ks. Kehittäjän työskentely tietomallin muutoksen parissa.
  4. Kun tietyn muutoksen työ on valmis, kehittäjä tekee feature-haarasta pull requestin päärepon develop-haaraan.
  5. Tietomallirepon hallinnoija arvio muutoksen teknisesti ja pyytää tarvittaessa muutoksia kehittäjätaholta.
  6. Kun muutos on teknisesti kunnossa repon hallinnoija hyväksyy pull requestin ja yhdistää muutoksen repon develop-haaraan, ja päivittää sen näkyville ko. tietomallin dev-versiona Rakennetun ympäristön tietomallit-sivustolla, ks. Tietomallimuutoksen hyväksyminen forkista päärepoon.
  7. Muutoksen toteuttamisesta vastuussa oleva Semanttisen yhteentoimivuuden teemaryhmän aliryhmä käsittelee muutoksen toteutuksen sekä päättää sille julkaisuversion ja muutoksen merkittävyyden käyttäen semanttista versionumerointipolitiikka (major/minor/patch). Samassa julkaisuversiossa on yleensä mukana useita muutoksia, mikäli kyseessä ei ole korjauspäivitys. Käsittelyssä voidaan hyödyntää Rakennetun ympäristön tietomallit -sivulle julkaistua dev-versiota tietomallista, jossa ehdotettu muutos on kuvattu.
  8. Kun Semanttisen yhteentoimivuuden teemaryhmässä on päätetty uudesta julkaisuversiosta ja siihen sisällytettävistä muutoksista, tekee tietomallirepon hallinnoija reposta uuden julkaisuversion, ks. Julkaisuversion luominen.
  9. Julkaisuversio julkaistaan lopullisen versionnumeronsa mukaisena pysyvänä versionaan Rakennetun ympäristön tietomallit -sivustolla, ks. Julkaisuversion julkaisu sivustolla. Tietomallin dev-versio voi myös edelleen lisäksi olla näkyvillä osoittaen develop-haaran uusimpaan muutokseen.
  10. Päivitetään tietomalli Yhteentoimivuusalustan Tietomallit-työkalussa vastaamaan uusinta julkaisuversiota. Tähän saadaan toivottavasti tulevaisuudessa UML-mallin tuonti/päivitystoiminnallisuus käyttäen XMI-tiedostomuotoa. Siihen asti päivitys pitää tehdä käsin Tietomallit-työkalun käyttöliittymän avulla.

Kehittäjän työskentely tietomallin muutoksen parissa

Alla käytetään Tonttijakosuunnitelman repoa esimerkkinä, jos muokkaa muuta tietomallia, niin muuta repojen osoitteet ja tiedostonimet vastaamaa niitä.

Valmistelut ja muutoshaaran luonti

  1. Tee oma fork pääreposta, esim. https://github.com/sykefi/Tonttijakosuunnitelman-tietomalli. Näin voit hallita tehtäviä muutoksia kokonaisuudessaan ilman päärepon muuttamiseen vaadittavia oikeuksia.
  2. Kloonaa forkattu git-repo omalle koneellesi jos sinulla ei vielä ole sitä: 
    $ cd <oma_git_juurihakemisto>
$ git clone https://github.com/<oma-gh-tunnus>/Tonttijakosuunnitelman-tietomalli.git
  3. Vaihda repo develop-haaraan ja päivitä mahdolliset muutokset pääreposta: 
    $ git checkout develop
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.
# Varmistaa, että paikallinen develop on ajantasalla päärepon develop-haaran kanssa: 
$ git pull https://github.com/sykefi/Tonttijakosuunnitelman-tietomalli.git develop
  4. Aloita uusi paikallinen feature-haara (korvaa <uusi_muutos> muutosta kuvaavalla nimellä) 
    $ git checkout -b feature/<uusi_muutos> develop
  5. Kloonaa paikalliset repot kaikista riippuvuuksien repoista ja päivitä niiden sisältö niihin release -tageihin, joita haluat käyttää riippuvuutena (riippuvuuksien versiot on dokumentoitu muutosloki.md-tiedostoon): 
    $ cd <oma_git_juurihakemisto>
$ git clone https://github.com/sykefi/ry-yhteiset.git
$ git clone https://github.com/sykefi/kaavatietomalli.git
$ cd ry-yhteiset
$ git checkout v1.0.0
$ cd ../kaavatietomalli
$ git checkout v2.0.0
    (korvaa release-tagit "v1.0.0" ja "v2.0.0" todellisilla riippuvuusversioilla).

UML-mallin muokkaus EA:lla

Tässä ohjeessa käytetään Enterprise Architect versiota 15.

  1. Varmista, että olet oikean repon feature-haarassa: 
    $ cd <oma_git_juurihakemisto>/Tonttijakosuunnitelman-tietomalli
$ git checkout feature/<uusi_muutos>
  2. Avaa muokattavan tietomallin eap-tiedosto hakemistosta looginenmalli/uml.
  3. Varmista, että projektin riippuvuudet (kuten RY-yhteiset-paketti) on ajantasalla tuomalla sen halutun riippuvuusversion XMI-tiedosto vastaavan paketin päälle EA:ssa (Publish/Import XML/Import Package from XMI). XMI-tiedostot löydät kloonaamistasi riippuvuus-repoista, niiden hakemistoista looginenmalli/uml (Kuva 1). Mikäli paketin nimen loppuun tulee punainen kolmio (Package control), käy poistamassa ko. paketti kontrolloiduista paketeista (Publish/Package Control/Package Control.., poista rasti kohdasta "Control package"). Näin et vahingossa tallenna siihen tehtyjä muutoksia tästä projektista.
  4. Tee tarvittavat muutokset UML-pakettiin, joka sisältää muokattavan tietomallin luokat. Huom! Älä muokkaa riippuvuuksina olevia paketteja tai niiden luokkia. Mikäli riippuvuuksiin pitää tehdä muutoksia, tee ne ko. paketin omassa GitHub-repossa, ja päivitä riippuvuus XMI-tuonnilla ks. edellinen kohta.
  5. Tallenna muokattu paketti XMI-muodossa (Publish/Package Control/Save to File) (Kuva 2). Mikäli tulee virhe, paketti ei ehkä ole asetettu kontrolloiduksi: Publish/Package Control/Package Control.., "XMI Filename"-kohtaan looginenmalli/uml/<tietomallin>.xml -tiedoston polku, "XMI Type": "Enterprise Architect XMI 1.2".
  6. Tallenna projekti eap-muodossa (CTRL-S tai Command-S).
  7. Tyhjennä EA:n generoima edellisen version HTML-dokumentaatio. HUOM! Älä poista tiedostoa looginenmalli/uml/doc/index.md 
    $ git rm -r looginenmalli/uml/doc/EARoot/ looginenmalli/uml/doc/css/ looginenmalli/uml/doc/js/ looginenmalli/uml/doc/images/
    Ilman tätä vaihetta vanhoja tiedostoja saattaa jäädä versionhallintaan roikkumaan.
  8. Generoi EA:lla uusi HTML-dokumentaatio hakemistoon looginenmalli/uml/doc/ (Publish/HTML/Standard HTML Report), "Package": Rakennettu ymparisto", "Output to": hakemisto, johon ko. repo on kloonattu ja sen alihakemisto looginenmalli/uml/doc/. Varmista, että olet generoimassa dokumentaatiota oikeaan tuloshakemistoon. Eri repojen hakemistot menevät helposti sekaisin ja EA muistaa hakemiston, johon generoit edellisen kerran (Kuva 3).
  9. Sulje EA-ohjelma. Tämä varmistaa, että EA on kirjoittanut kaiken eap-tiedostoon.
  10. Tarkista, että HTML-raportin oletuskaavion polku on oikein tiedostossa looginenmalli/uml/doc/index.md:
    1. Avaa tiedosto looginenmalli/uml/doc/index.html.
    2. Etsi body-tagin rivi <body onload="initLoad(this,'toc.html','<kaavion_polku>')"....
    3. Kopioi initLoad-funktiokutsun toinen argumentti <kaavion_polku> tiedoston looginenmalli/uml/doc/index.md riville defaultDiagram: "<kaavion_polku>".
    4. Tallenna muutokset.
  11. Tarkista, että muutokset näyttävät oikeilta (alla esimerkki): 
    $ git status
On branch feature/<uusi_muutos>
 
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
    deleted:    looginenmalli/uml/doc/EARoot/EA1.html
    deleted:    looginenmalli/uml/doc/EARoot/EA1/EA10.png
    deleted:    looginenmalli/uml/doc/EARoot/EA1/EA11.html
 ...
 Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git restore <file>..." to discard changes in working directory)
    modified:   looginenmalli/uml/ry-yhteiset.eap
    modified:   looginenmalli/uml/ry-yhteiset.xml

 Untracked files:
 (use "git add <file>..." to include in what will be committed)
    looginenmalli/uml/doc/EARoot/
    looginenmalli/uml/doc/css/
    looginenmalli/uml/doc/images/
    looginenmalli/uml/doc/js/
  12. Lisää ja commitoi tehdyt muutokset 
    $ git add looginenmalli/uml/*.eap looginenmalli/uml/*.xml looginenmalli/uml/doc/
$ git commit -m "<tehtyjen muutosten kuvausteksti kompaktisti>"
  13. Varmista, että paikallinen develop-haarasi on ajan tasalla päärepon develop-haaran kanssa: 
    $ git checkout develop
$ git pull https://github.com/sykefi/Tonttijakosuunnitelman-tietomalli.git develop
    Mikäli pull-operaatio tuotti muutoksia paikalliseen tietomalliin, on päärepon develop-haaraan tehty muutoksia sen jälkeen kun feature-haara tehtiin. Tarkista huolellisesti, että et tahattomasti ylikirjoita tehtyjä muutoksia omilla muutoksillasi. Voit avata muokatun develop-haaran eap-tiedoston (tai tuoda XMI-tiedosto) EA:ssa ja viedä sen Publish/Export-XML/Export XML for Current Package -toiminnolla erilliseen työtiedostoon. Sen jälkeen siirry taas feature/<uusi_muutos> -haaraan, avaa sen mukainen malli EA:lla ja käytä Import-XML/Merge Model XMI into Current Package -toimintoa. Kun muutokset on yhdistetty, commitoi yhdistyt muutokset feature/<uusi_muutos> -haaraan.

Kuva 1: Riippuvuuden päivittäminen XMI-tuonnilla Kuva 1: Riippuvuuden päivittäminen XMI-tuonnilla.

Kuva 2: XMI-tiedoston vieminen package control -toiminnolla Kuva 2: XMI-tiedoston vieminen package control -toiminnolla.

Kuva 3: HTML-raportin generointi Kuva 3: HTML-raportin generointi.

Muutosten tarjoaminen päärepoon

  1. Jos feature-haara on olemassa vain paikallisesti, eikä sitä ole vielä työnnetty forkaamaasi etärepoon, tee feature-haaraan rebase (muuttaa feature-haaraan tehdyt commitit kuten ne kaikki olisi tehty develop-haaraan kärkeen, jolloin muutoshistoria ei mene sekaisin muiden saman aikaan tehtyjen muutosten kanssa). Huom! Älä ikinä käytä rebasea, jos olet työntänyt feature-haarasi etärepoon siten, että muilla on siihen pääsy, tai jos olet tehnyt siitä pull requestin, ks. Golden rule of rebasing.

    $ git checkout feature/<uusi_muutos>
# yliajaa kaikki develop-haarassa mahdollisesti olevat muutokset, jotka on tehty
# sen jälkeen kun feature-haara on luotu.
# develop-haaran mahdolliset muutokset pitää olla tässä vaiheessa yhdistetty EA:lla 
# feature-haaran malliin. XML/HTML-tiedostojen muutosten rivipohjainen yhdistäminen
# ei yleensä onnistu gitillä. Huomaa, että "theirs" vastaa rebasessa mergen "ours" -strategiaa:
$ git rebase -s theirs develop

    Mikäli feature-haara on olemassa forkatussa etärepossa, ja erityisesti, jos siitä on jo tehty pull request päärepoon, tee rebasen sijaan merge develop-haarasta feature-haaraan, sillä rebase poistaa ja lisää tehdyt commitit uudelleen eri kohtaan ja eri tunnuksilla, mikä sotkee pull requestin.

    $ git checkout feature/<uusi_muutos>
# yliajaa kaikki develop-haarassa mahdollisesti olevat muutokset,
# develop-haaran mahdolliset muutokset pitää olla tässä vaiheessa yhdistetty EA:lla
# feature-haaran malliin. XML/HTML-tiedostojen muutosten rivipohjainen yhdistäminen
# ei yleensä onnistu gitillä:
$ git merge -s ours develop

  2. Työnnä muutettu feature-haara omaan forkattuun etärepoosi talteen

    $ git push -u origin feature/<uusi_muutos>

  3. Tee pull request forkkisi feature/<uusi_muutos>-haarasta päärepon develop-haaraan. Linkkaa pull request päärepon ko. muutostarpeen kuvaavaan seikkaan.

  4. Päärepon admin arvioi muutoksen ja hyväksyy sen mahdollisten muutosten jälkeen päärepon develop-haaraan, mistä se viedään seuraavaan sopivaan julkaisuversioon. Jos teet vielä muutoksia feature-haaran, ja sinun pitää yhdistää muutoksia muista haaroista, muista käyttää merge-, ei rebase -strategiaa (esim. git pull ei git pull --rebase tai git fetch && git merge ei git fetch && git rebase).

  5. Kun pull request on hyväksytty ja muutokset yhdistetty päärepon develop-haaraan, päivitä oman forkkisi develop-haara ajantasalle.

    $ git checkout develop
$ git pull https://github.com/sykefi/Tonttijakosuunnitelman-tietomalli.git develop
$ git push origin develop

  6. Kun olet tarkistanut muutoksen, voit poistaa feature-haaran sekä paikallisesti että omasta forkistasi:

    $ git branch -d feature/<uusi_muutos>
$ git push -d origin feature/<uusi_muutos>

  7. Halutessasi voi päivittää myös oman forkkisi main/master -haaran ajantasalle mahdollisten päähaarän julkaisujen kanssa:

    $ git checkout main
$ git pull https://github.com/sykefi/Tonttijakosuunnitelman-tietomalli.git main
$ git push origin main

Tietomallimuutoksen hyväksyminen forkista päärepoon

  1. Kun valmiin muutoksen pull request saapuu develop-haaraan, tietomallirepon hallinnnoija tarkastaa sen teknisesti ja pyytää tarvittaessa muutoksia. Pull requesteja muihin haaroihin ei hyväksytä.
  2. Kun pull request on hyväksyttävässä tilassa, tietomallirepon hallinnnoija hyväksyy sen.
  3. Uusi develop-haaran tila päivitetään näkyville Rakennetun ympäristön tietomallit -sivuston ko. tietomallin dev-versioksi (esimerkissä tonttijakosuunnitelma, korvaa vastaavasti):
    1. Kloonaa tarvittaessa ry-tietomallit-repo: 
      $ cd <oma_git_juurihakemisto>
$ git clone https://github.com/sykefi/ry-tietomallit.git
    2. Jos ko. tietomallista ei ole sivustolla vielä yhtään versiota, tee sille uusi hakemisto ja tietomallimodulille yaml-kuvaustiedosto _data/modules/-hakemistoon: 
      $ cd <oma_git_juurihakemisto>/ry-tietomallit
$ mkdir docs/tonttijakosuunnitelma
$ touch docs/_data/modules/tonttijakosuunnitelma.yml
      Laadi tietomallimodulin yaml-kuvaus kuten kuvattu erillisessa ohjeessa.
    3. Jos tietomallista ei ole dev-versiota sivustolla (hakemistoa docs/tonttijakosuunnitelma/dev ei ole), tee se uutena git-submodulina: 
      $ cd <oma_git_juurihakemisto>/ry-tietomallit
$ git submodule add https://github.com/sykefi/Tonttijakosuunnitelman-tietomalli.git docs/tonttijakosuunnitelma/dev
$ git submodule set-branch --branch develop docs/tonttijakosuunnitelma/dev
$ cd docs/tonttijakosuunnitelma/dev
$ git checkout develop
      Päivitä tietomallimodulin yaml-kuvausta sisältämään uuden dev-version.
    4. Mikäli tietomallin dev-versiolle on jo submodule, päivitä sen sisältö osoittamaan develop-haaran uuteen kärkeen: 
      $ cd <oma_git_juurihakemisto>/ry-tietomallit/docs/tonttijakosuunnitelma/dev
$ git checkout develop
$ git pull origin develop
    5. Lisää ja commitoi uusi/päivitetty submodule ja tietomallimodulin yaml-kuvaus: 
      $ cd <oma_git_juurihakemisto>/ry-tietomallit
$ git add .gitmodules docs/_data/modules/tonttijakosuunnitelma.yml docs/tonttijakosuunnitelma/dev
$ git commit -m "Lisätty/Päivitetty tietomallimodulin tonttijakosuunnitelma dev-versio"
$ git push
    6. Tarkista että päivitetyn/uuden dev-haaran dokumentaatio tulee näkyviin Rakennetun ympäristön tietomallit -sivustolla. Sivuston generoinnissa menee pushauksen jälkeen muutama minuutti.
  4. Tiedota Semanttisen yhteentoimivuuden teemaryhmän aliryhmälle, että ehdotettu muutos on nyt tarkasteltavissa.

Uuden julkaisuversion teko tietomallista

Kun Semanttisen yhteentoimivuuden teemaryhmässä on päätetty uudesta julkaisuversiosta ja siihen sisällytettävistä muutoksista, tekee tietomallirepon hallinnoija tietomallireposta uuden release-version ja julkaisee sen Rakennetun ympäristön tietomallit -sivustolla.

Julkaisuversion luominen

  1. Tutki mikä develop-haaran commit sisältää kaikki ko. julkaisuun (tässä versio 2.1.0) halutut muutokset (oletataan tässä esimerkissä että se on 9efc5d)
  2. Tee uusi release haara ko. commitista: 
    $ git checkout -b release/2.1.0 9efc5d
  3. Tarkista, että julkaistavan tietomallin versionnumero on oikein dokumentaatiossa ja muutoslokissa. Tarkista muutenkin, että muutosloki on kunnossa ja kaikki muutokset kuvattu. Commitoi mahdolliset muutokset.
  4. Tee versiotägi ja merge takaisin develop-haaraan: 
    $ git tag v2.1.0
$ git checkout develop
$ git merge release/2.1.0
  5. Työnnä uusi tägi etärepoon ja poista paikallinen release-haara: 
    $ git push --tags origin develop
$ git branch -d release/2.1.0
  6. Siirrä master/main-haara osoittamaan uuteen release-tägiin: 
    $ git checkout main
$ git merge --ff-only v2.1.0
$ git push origin main

Julkaisuversion julkaisu sivustolla

Julkaisuversion tägäämisen jälkeen se voidaan julkaista Rakennetun ympäristön tietomallit -sivustolla (esimerkissä tonttijakosuunnitelma, versio 2.1.0, korvaa vastaavasti).

  1. Kloonaa tarvittaessa ry-tietomallit-repo: 
    $ cd <oma_git_juurihakemisto>
$ git clone https://github.com/sykefi/ry-tietomallit.git
  2. Jos ko. tietomallista ei ole sivustolla vielä yhtään versiota, tee sille uusi hakemisto ja tietomallimodulille yaml-kuvaustiedosto _data/modules/-hakemistoon: 
    $ cd <oma_git_juurihakemisto>/ry-tietomallit
$ mkdir docs/tonttijakosuunnitelma
$ touch docs/_data/modules/tonttijakosuunnitelma.yml
    Laadi tietomallimodulin yaml-kuvaus kuten kuvattu erillisessa ohjeessa.
  3. Tee uusi git-submodule julkaisuversiolle: 
    $ cd <oma_git_juurihakemisto>/ry-tietomallit
$ git submodule add https://github.com/sykefi/Tonttijakosuunnitelman-tietomalli.git docs/tonttijakosuunnitelma/v2.1.0
$ cd docs/tonttijakosuunnitelma/v2.1.0
$ git checkout v2.1.0
    Päivitä tietomallimodulin yaml-kuvausta sisältämään uuden dev-version.
  4. Lisää ja commitoi uusi/päivitetty submodule ja tietomallimodulin yaml-kuvaus: 
    $ cd <oma_git_juurihakemisto>/ry-tietomallit
$ git add .gitmodules docs/_data/modules/tonttijakosuunnitelma.yml docs/tonttijakosuunnitelma/v2.1.0
$ git commit -m "Lisätty tietomallimodulin tonttijakosuunnitelma julkaisuversio v2.1.0"
$ git push
  5. Tarkista että uuden version dokumentaatio tulee näkyviin Rakennetun ympäristön tietomallit -sivustolla. Sivuston generoinnissa menee pushauksen jälkeen muutama minuutti.
  6. Tiedota Semanttisen yhteentoimivuuden teemaryhmälle, että uusi versio on nyt julkaistu.

Uuden korjausversion teko julkaistusta tietomalliversiosta

Tämän ohjeen mukaan tietomallin korjausversion (ns. hotfix) voi tehdä vain viimeisimpää julkaisuversioon. Mikäli on tarpeen tehdä korjauksia myös aiempiin julkaisuversioihin, menee repo-haarojen hallinta astetta monimutkaisemmaksi, sillä tällöin kullakin julkaisuversiolle pitää tehdä oma support-haaransa, josta korjausversiot voidaan julkaista ilman että mukaan tulee myöhempien julkaisuversioiden muutoksia.

  1. Tee uusi issue korjaustarpeesta tietomallin repoon, ellei jo sinne muiden toimesta raportoitu.
  2. Tiedota korjaustarpeesta Semanttisen yhteentoimivuuden teemaryhmälle tai suoraan sopivalle alaryhmälle.
  3. Kun Semanttisen yhteentoimivuuden teemaryhmä päättää, että korjaus voidaan tehdä, tietomallirepon hallinnoija voi joko itse tehdä korjauksen, tai pyytää kehittäjää tekemään sen omassa forkissaan ja tekemään korjauksesta pull requestin. Alla ensimmäisen vaihtoehdon mukainen prosessi, joka sopii pieniin muutoksiin (kovin suuria ei voi korjauksina tehdäkään).
  4. Tee uusi hotfix-haara viimeisimmästä main-haarasta (tämä on aina viimeisimmän julkaisun tasalla): 
    $ git checkout -b hotfix/2.1.1 main
  5. Tee korjaus tietomallin dokumentaatioon tai/ja UML-malliin, ks. UML-mallin muokkaus EA:lla.
  6. Kuvaa tehty muutos muutosloki-tiedostoon oman versionumeronsa alle.
  7. Commitoi muutokset.
  8. Tee versiotägi ja merge takaisin develop-haaraan: 
    $ git tag v2.1.1
$ git checkout develop
$ git merge hotfix/2.1.1
  9. Työnnä uusi tägi etärepoon ja poista paikallinen hotfix-haara: 
    $ git push --tags origin develop
$ git branch -d hotfix/2.1.1
  10. Siirrä master/main-haara osoittamaan uuteen hotfix-version tägiin: 
    $ git checkout main
$ git merge --ff-only v2.1.1
$ git push origin main
  11. Julkaise korjausversio Rakennetun ympäristön tietomallit -sivustolla samoin kuin julkaisuversion kanssa.
Clone this wiki locally