Monimutkainen haarautumis- ja käyttöönottostrategia

Monimutkainen haarautumis- ja käyttöönottostrategia

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ö

master

Poliittisesti tärkeämpi kuin prd, tämä tarkoittaa, että se ei ole vain tuotannossa yhdellä asiakkaalla, vaan tämä on julkinen julkaisu mille tahansa koodin instanssille.

prod

sisältää tällä hetkellä toimivan koodin tuotantoympäristössä

release

sisältää nykyisen yhteisen koodin, joka aiotaan julkaista tuotantoympäristössä seuraavan julkaisun aikana

staging

sisältää yhteisen koodin, joka tällä hetkellä toimii välivarastossa (stg) ympäristössä

stg

sisältää yhteisen koodin, joka aiotaan ottaa käyttöön välivarastossa (stg) ympäristössä

develop

sisältää yhteisen koodin, joka tällä hetkellä toimii kehitysympäristössä (dev)

<<ticket-id>>-<<feature-name>>

sisältää lähdekoodin, jota kehittäjät kehittävät omissa paikallisissa kehitysympäristöissään (paikallinen) sekä joissain tapauksissa koodin kehitysympäristössä(dev)

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öönottoa staging 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ää ominaisuuden release haaraan (käyttäen -X theirs ja --allow-unrelated-histories lippuja) ja merkitsee sen uudella versiolla, jotta koodin tilaa voidaan tunnistaa komennolla git 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 ja release) 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.