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
,production
jokaiselle ominaisuusharalle, joka on työn alla (WIP) sovelluksen käyttöönoton aikana - Kun uutta ominaisuutta kehitetään, kehittäjä luo uuden ominaisuushaaran viimeisimmästä
develop
haarasta. 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
develop
haaraan. - Pull-pyyntö arvioidaan vähintään yhden muun tiimin jäsenen toimesta ja yhdistetään
develop
haaraan, JOS arvioija hyväksyy pull-pyynnön ja kaikki muutetut mikropalvelukomponentit on testattu. - Käyttöönotto stg ympäristöön tapahtuu
stg
haarasta, jotta se voidaan tehdä saataville testauksia varten ei-teknisille käyttäjille. - Jos
stg
haaran käyttöönotossa on ongelmia tai jos ei-tekniset käyttäjät eivät hyväksy uusinta käyttöönottoastaging
ympäristössä, suoritetaan palautus (rollback). - Kun
staging
haara 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ää ominaisuudenrelease
haaraan (käyttäen-X theirs
ja--allow-unrelated-histories
lippuja) ja merkitsee sen uudella versiolla, jotta koodin tilaa voidaan tunnistaa komennollagit push --tags
. - Käyttöönotto tuotantoympäristöön tapahtuu
release
haarasta. - JOS liiketoiminnan edustajat löytävät tuotannossa vian, joka voidaan korjata alle 4 tunnissa, luodaan hotfix haara
release
haarasta 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
prod
haara palautetaan (rebase)release
haarasta – 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
tuotanto
commit-tunnisteeseen. - Julkaisun jälkeen KAIKKI yhteiset (
develop
jarelease
) haarat palautetaan (rebase)develop
haarasta 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.