Új hozzászólás Aktív témák

• #14844 instantwater addikt

  Új Válasz 2020-10-17 22:50:39 #14844

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  instantwater

  addikt

  A DevOps topik kihalt, úgyhogy bedobom ide.

  Egy kis brainstormingot szeretnék indítani az alábbiakról.

  Continuous Deployment környezetben ki melyik branching strategyt használja, és miért? Mi triggereli a promotiont stagingből productionbe?

  Melyik azonosítót használnád a deploymentek jelölésére? Semver, git hash, vagy build id?

  A semver igényel emberi közreműködést, mert default a patch számot növelné a rendszer, de a fejlesztő belátásán múlik, hogy a kód amit beküld az inkább egy minor bump legyen patch bump helyett.

  Git hash egyértelmű, könnyen visszavezethető pontosan a forrás commitra. Viszont nincs benne szekvencia, nehéz megmondani 2 git hashról, hogy melyik a későbbi anélkül, hogy valaki megnézi a git historyt és megkeresi a commitokat ID alapján.

  Build number szekvenciális, és nem igényel emberi beavatkozást, viszont nehéz visszavezetni commitra.

  Viszont, ha nem kap verzió taget egy-egy commit, akkor mi triggereli a production deployt, ha stagingben megfelelt a kód?

  Van erre valami best practice? Itt vissza térünk a kérdés elejére, hogy melyik branching strategy lenne a legideálisabb.

  Jelenleg GitFlowot használunk, de macerás a dupla PR a hotfixekhez (master, develop), és a develop PRrel kerül a masterbe (és deployolásra) hetente 2x, amit szintén szeretnénk lecserélni napi többszöri deploymentre.

  Az eszközökkel nincs baj, GitHub Actions, Docker, Terraform, Ansible tapasztalat megvan, inkább a mit mikor és hogyan lenne a kérdés.

  A deployment jelenleg egy több szerverre kitolt kódbázissal megy ahol a függőségek az összes szerveren helyben újra és újra telepítve vannak ami írtó sávszél pazarló, és fragile, mert boldog-boldogtalan root joggal bír a szervereken, és gyakran elb.rmolják az ownershipeket.

  Ezt le akarom cserélni immutable image alapú deploymentre, ahol egyszer vannak telepítve a függőségek, majd ez az image van kitolva a szerverekre.

  Ez lehet akár machine image buildeléssel aztán Terraformmal lecserélni a szervereket és újrakonfigurálni a routingot, de ezt lassúnak érzem. A másik opció Docker image buildelés lenne, mert az könnyen és gyorsan lehet kitolni a szerverekre.

  Hosszabb távon a cél Kubernetesre költözés, de mivel egy monolit alkalmazásról van szó ezért úgy érzem az azonnali Kubernetesre váltás túl sok új komplikációt hozna, és jelenlegi archirektúra automatizálása egy jó köztes lépés lenne.

  Vagy ahogy egy szakadékot sem lehet két ugrással átugrani, több értelme lenne egyből Kubernetesbe tolni az egészet, aztán lassan refaktorálni microservices architektúrára?

  Kinek mi jött be, mi működött, nem működött?

Új hozzászólás Aktív témák