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.