Tämän asiakirjan tarkoituksena on määritellä organisaation yhteiset minimivaatimukset ja toimenpiteet, jotka koskevat KOMPLEKSISTA haarastrategiaa ja käyttöönottoprosessia, joita sovelletaan flok-ohjelman puitteissa kehitettyjen sovellusten elinkaaren aikana.
Sovellusten käyttöönoton vakiorakenne käyttää seuraavia ympäristöjä:
-
paikallinen kehitysympäristö (lde)
-
kehitys (dev)
-
välivarastointi (stg)
-
tuotanto (prd)
-
master
Tämä tarkoittaa vakiosettiä kolmesta haarasta kaikissa sovellusrepositoorioissa:
|
Haara |
Ympäristö |
|---|---|
|
|
Poliittisesti tärkeämpi kuin |
|
|
sisältää tällä hetkellä toimivan koodin tuotantoympäristössä |
|
|
sisältää nykyisen yhteisen koodin, joka aiotaan julkaista tuotantoympäristössä seuraavan julkaisun aikana |
|
|
sisältää yhteisen koodin, joka tällä hetkellä toimii |
|
|
sisältää yhteisen koodin, joka aiotaan ottaa käyttöön |
|
|
sisältää yhteisen koodin, joka tällä hetkellä toimii |
|
|
sisältää lähdekoodin, jota kehittäjät kehittävät omissa paikallisissa kehitysympäristöissään (paikallinen) sekä joissain tapauksissa koodin |
Seuraavia toimintaohjeita tulee noudattaa:
- Kaikki haarat palautetaan uudelleen (rebase) ylhäältä alas yllä olevasta taulukosta ^^^ – tämä tarkoittaa esimerkiksi, että hotfixit tuotannossa TÄYTYY soveltaa kaikkiin alla oleviin haaroihin seuraavassa järjestyksessä –
develop,stg, staging,productionjokaiselle ominaisuusharalle, joka on työn alla (WIP) sovelluksen käyttöönoton aikana - Kun uutta ominaisuutta kehitetään, kehittäjä luo uuden ominaisuushaaran viimeisimmästä
develophaarasta. Ominaisuusharjan täytyy olla synkronoitu (rebase) kehityshaaran (develop) kanssa. - Ominaisuuksia, jotka lisäävät monimutkaisuutta, mutta eivät tarjoa CI-testejä näille monimutkaisuuksille, EI SAA lisätä mihinkään yhteiseen haaraan (tarkista konkreettiset askeleet, joita on noudatettava)
- Kun uusi ominaisuus on valmis, kehittäjä luo pull-pyynnön, jossa pyydetään yhdistämään hänen ominaisuusharansa
develophaaraan. - Pull-pyyntö arvioidaan vähintään yhden muun tiimin jäsenen toimesta ja yhdistetään
develophaaraan, JOS arvioija hyväksyy pull-pyynnön ja kaikki muutetut mikropalvelukomponentit on testattu. - Käyttöönotto stg ympäristöön tapahtuu
stghaarasta, jotta se voidaan tehdä saataville testauksia varten ei-teknisille käyttäjille. - Jos
stghaaran käyttöönotossa on ongelmia tai jos ei-tekniset käyttäjät eivät hyväksy uusinta käyttöönottoastagingympäristössä, suoritetaan palautus (rollback). - Kun
staginghaara on testattu ei-teknisten käyttäjien toimesta stg ympäristössä ja sitä pidetään valmiina tuotantoon, ominaisuuden käyttöönotosta vastaava henkilö yhdistää ominaisuudenreleasehaaraan (käyttäen-X theirsja--allow-unrelated-historieslippuja) ja merkitsee sen uudella versiolla, jotta koodin tilaa voidaan tunnistaa komennollagit push --tags. - Käyttöönotto tuotantoympäristöön tapahtuu
releasehaarasta. - JOS liiketoiminnan edustajat löytävät tuotannossa vian, joka voidaan korjata alle 4 tunnissa, luodaan hotfix haara
releasehaarasta ja se otetaan nopeasti käyttöön ensin stg-ympäristössä, ja jos kaikki testit läpäisevät nopeasti myös siellä, se otetaan käyttöön tuotantoon uudella tunnisteella. Jos korjaus vie yli 4 tuntia, on luotava prio-1 virhe ja seurattava normaalia käyttöönottoa ilman hotfixiä. - Kun liiketoiminnan edustajat ovat hyväksyneet uuden version tuotantoympäristössä, olemassa oleva
prodhaara palautetaan (rebase)releasehaarasta – julkaistu git-tunniste tulee uudeksi ”totuuden lähteeksi” – eli mikä on nykyinen ohjelmistoversio, joka toimii tuotantoympäristössä. - JOS liiketoiminnan edustajat eivät hyväksy uutta versiota, palautetaan edelliseen
tuotantocommit-tunnisteeseen. - Julkaisun jälkeen KAIKKI yhteiset (
developjarelease) haarat palautetaan (rebase)develophaarasta julkaisun suorittavan henkilön toimesta. Kaikkien muiden kehittäjien ON myös palautettava (rebase) omat ominaisuus– / bugfix haaransa develop-haarasta – jokaisen kehittäjän on varmistettava, että ero (diff) yhteisen develop-haaran ja nykyisen ominaisuus– / bugfix haaran välillä, jonka parissa hän työskentelee, sisältää VAIN muutokset, jotka liittyvät siihen virheeseen/ominaisuuteen, jonka parissa hän työskentelee. - HUOMAUTUS: Live-ympäristöihin tehtävät käyttöönotot tulee aina tehdä automatisoitujen CI/CD-prosessien kautta, ei koskaan manuaalisesti. Yllä kuvatun prosessin aikana kaikki siirtymiset ympäristöjen välillä tehdään GitLab-lähdekoodin hallintajärjestelmän kautta.
Jokainen käyttöönotto eri ympäristöihin tulisi olla mahdollista käynnistää manuaalisesti Git pohjaisen lähdekoodihallintajärjestelmän DevOps -käyttöliittymän kautta.