Minél gyorsabb a fejlesztési folyamat, annál gyorsabban fejlődik a technológiai vállalat.
Sajnos a modern alkalmazások ellenünk dolgoznak — rendszereinknek valós időben kell frissülniük, miközben senkinek sem zavarhatják meg az üzletmenetet, és nem vezethetnek leállásokhoz. Az ilyen rendszerekben való telepítés bonyolult feladattá válik, és még a kis csapatok számára is összetett folyamatos szállítási csatornákat igényel.
Ezek a csatornák általában szűk alkalmazásúak, lassan működnek és megbízhatatlanok. A fejlesztőknek először manuálisan kell azokat létrehozniuk, majd kezelniük őket, ezért a cégek gyakran egész DevOps csapatokat alkalmaznak erre.
A csatornák sebessége határozza meg a fejlesztés sebességét. A legjobb csapatoknál a telepítési folyamat 5–10 percet vesz igénybe, de általában sokkal tovább tart, és egy telepítéshez több órára van szükség.
A Darknál ez 50 ms-ba telik. Ötven. Millisekundum.. A Dark egy amelyet kifejezetten a folyamatos szállításra terveztek, és a Dark minden aspektusa, beleértve magát a nyelvet, a biztonságos, azonnali telepítés érdekében lett kialakítva.
Miért olyan lassúak a folyamatos szállítási csatornák?
Tegyük fel, hogy van egy Python webalkalmazásunk, és már létrehoztunk egy csodálatos és modern folyamatos szállítási csatornát. A fejlesztő, aki minden nap ezzel a projekttel foglalkozik, valahogy így látja egy apró változtatás telepítését:
Változtatások végrehajtása.
- Új ág létrehozása a gitben.
- Változtatások végrehajtása a funkciókapcsoló mögött.
- Moduláris tesztelés a változtatások ellenőrzésére a funkciókapcsolóval és anélkül.
Pull kérés.
- A változtatások elkötelezése.
- A változtatások elküldése a távoli repository-ba a githubon.
- Pull kérés.
- A CI build automatikusan, a háttérben történik.
- Kódellenőrzés.
- Még néhány ellenőrzés, ha szükséges.
- A változtatások egyesítése a git masterével.
A CI a masteren fut.
- Frontend függőségek telepítése npm-en keresztül.
- HTML+CSS+JS erőforrások összeállítása és optimalizálása.
- Moduláris és funkcionális tesztek futtatása a frontendben.
- Python függőségek telepítése a PyPI-ból.
- Moduláris és funkcionális tesztek futtatása a backendben.
- Integrációs tesztelés mindkét végén.
- Frontend erőforrások küldése a CDN-re.
- Konténer létrehozása a Python programhoz.
- A konténer regisztrálása
- A Kubernetes-manifeszt frissítése
A régi kód lecserélése újra
- A Kubernetes több példányt indít el az új konténerből
- A Kubernetes várakozik, hogy a példányok működőképesek legyenek
- A Kubernetes példányokat ad hozzá a HTTP terheléselosztóhoz
- A Kubernetes várakozik, amíg a régi példányok használatból nem kerülnek ki
- A Kubernetes leállítja a régi példányokat
- A Kubernetes megismétli ezeket a műveleteket, amíg az új példányok teljesen nem váltják le a régiakat
Az új funkciókapcsoló aktiválása
- Az új kódot csak önmagára aktiválják, hogy biztosítsák, minden rendben van-e
- Az új kód 10% -ának aktiválása, működési és üzleti metrikák nyomon követése
- Az új kód 50% -ának aktiválása, működési és üzleti metrikák nyomon követése
- Az új kód 100% -ának aktiválása, működési és üzleti metrikák nyomon követése
- Végül az egész folyamatot megismétlik, hogy eltávolítsák a régi kódot és a kapcsolót
A folyamat az eszközöktől, a nyelvtől és a szolgáltató-orientált architektúráktól függ, de átfogóan így néz ki. Nem említettem az adatbázis-migrációval történő telepítéseket, mivel ezek alapos tervezést igényelnek, de lentebb elmondom, hogyan kezeli ezt a Dark.
Itt sok összetevő van, és sok közülük egyszerűen lelassíthat, meghibásodhat, időszakos versenyt okozhat vagy összeomláshoz vezethet a működési rendszerben.
Ráadásul ezek a pipeline-ok szinte mindig speciális esetekre készülnek, így nehéz bennük megbízni. Sokaknak vannak napjaik, amikor a kódot nem lehet telepíteni, mert a Dockerfile problémás, az egyik a sok szolgáltatás közül leállt, vagy a szükséges szakember szabadságon van.
Ráadásul sok ezek közül a lépések közül valójában semmi hasznosat nem tesznek. Korábban szükségesek voltak, amikor a kódot azonnal a felhasználók számára telepítettük, de most már vannak kapcsolók az új kódhoz, és ezek a folyamatok elkülönültek. A végeredmény az, hogy a kód telepítése (ahol a régi helyébe új lép) most már egyszerűen egy felesleges kockázattá vált.
Természetesen ez egy nagyon átgondolt pipeline. A csapat, amelyik létrehozta, nem sajnálta az időt és a pénzt a gyors telepítéshez. A telepítési pipeline-ok általában sokkal lassabbak és megbízhatatlanabbak.
A folyamatos szállítás megvalósítása a Darkban
A megszakítás nélküli ellátás annyira fontos a Dark számára, hogy az elejétől fogva kevesebb mint másodpercen belüli időt céloztunk meg. Minden lépést átnéztünk a csővezetékben, hogy eltávolítsuk a felesleges részeket, és a maradékot optimalizáljuk. Így távolítottuk el a lépéseket.
Jessie Frazelle () új szót talált ki, a deployless-t (telepítés nélküli) a Sikertelen Szoftverfejlesztési Konferencián Reykjavikban.
Azonnal döntöttünk arról, hogy a Dark a „deployless” (köszönjük a neologizmusért). A deployless azt jelenti, hogy bármilyen kód azonnal települ és kész a használatra a produkciós környezetben. Természetesen nem hagyjuk figyelmen kívül a hibás vagy hiányos kódot (a biztonsági elveket alább részletezem).
A Dark bemutatóján gyakran kérdezték, hogyan sikerült ennyire felgyorsítani a telepítést. Furcsa kérdés. Valószínűleg az emberek azt hiszik, hogy kitaláltunk egy szupertechnológiát, amely összehasonlítja a kódot, kompaktálja, konténerbe csomagolja, virtuális gépet indít, hidegen indítja a konténert, és mindezt 50 ms alatt végzi. Ez valószínűleg nem lehetséges. De egy speciális telepítőmotort hoztunk létre, amelynek minderre nincs szüksége.
A Dark az értelmezőket a felhőben indítja. Tegyük fel, hogy kódot írsz egy függvényben vagy HTTP-eseménykezelőben. A különbséget (diff) egy absztrakt szintaktikai fába (AST), amelyet a szerkesztőnk és a szervereink belsőleg használnak, küldjük a szervereinkre, majd ezt a kódot indítjuk el, amikor kérdés érkezik. Így a telepítés egészen egyszerűen egy adatbázisbejegyzésnek tűnik - azonnali és elemi. A telepítés olyan gyors, mert magában foglalja a lehető legkevesebbet.
A jövőben a Darkból egy infrastruktúra-kompilátort tervezünk létrehozni, amely létrehozza és elindítja az ideális infrastruktúrát a nagy teljesítmény és megbízhatóság érdekében. Az azonnali telepítés természetesen nem tűnik el.
Biztonságos telepítés
Szerkesztett környezet
A kód a Darkban a Dark szövegszerkesztőben íródik. A strukturált szerkesztő nem engedélyez szintaktikai hibákat. A Darkban gyakorlatilag nincs szintaxis-elemző. Amíg beírod a szöveget, közvetlenül az absztrakt szintaktikai fával (AST) dolgozunk, mint , , , és .
Bármely befejezetlen kódnak a Darkban megengedett végrehajtási szemantikája van, körülbelül úgy, mint a . Például, ha megváltoztatja a függvényhívást, tároljuk a régi függvényt, amíg az új használhatóvá nem válik.
Minden programnak a Darkban megvan a saját jelentése, ezért a befejezetlen kód nem zavarja meg a befejezett működését.
Szerkesztési módok
A Darkban két esetben ír kódot. Az első: új kódot ír, és egyedüli felhasználó. Például, ha a REPL-ben van, és más felhasználók sosem férhetnek hozzá, vagy ez egy új HTTP útvonal, amelyre sehol nem hivatkozik. Itt óvintézkedések nélkül lehet dolgozni, és ön most valahogy így dolgozik a fejlesztői környezetben.
A második helyzet: a kódot már használják. Ha a kódon forgalom megy keresztül (függvények, eseménykezelők, adatbázisok stb.), óvatosnak kell lenni. Ehhez blokkoljuk az összes használt kódot, és követeljük, hogy strukturáltabb eszközöket használjon a szerkesztéshez. Az strukturált eszközökről lentebbi részben beszélek: függvénykapcsolók HTTP és eseménykezelőkhez, erőteljes migrációs platformok adatbázisokhoz és egy új verziókezelési módszer a függvények és típusok számára.
Függvénykapcsolók
Az egyik módja a Darkban az, hogy több problémát egy megoldással orvosol. A függvénykapcsolók sok különböző feladatot látnak el: a helyi fejlesztői környezet helyettesítése, a git ágak, a kód telepítése és természetesen a hagyományos, lassú és ellenőrzött új kód kiadása.
A függvénykapcsoló létrehozása és telepítése a szerkesztőnkben egy lépésben történik. Üres teret hoz létre az új kód számára, és hozzáférési vezérlőelemeket biztosít a régi és új kódhoz, valamint gombokat és parancsokat a fokozatos átálláshoz az új kódra vagy annak kizárására.
A függvénykapcsolók beépítve vannak a Dark nyelvbe, és még a befejezetlen kapcsolók is végzik a feladatukat — ha a feltétel a kapcsolóban nem teljesül, a régi, blokkolt kód fog futni.
Fejlesztői környezet
A funkcióváltók helyettesítik a helyi fejlesztési környezetet. Ma a csapatoknak nehéz nyomon követniük, hogy mindenki azonos verziójú eszközöket és könyvtárakat használjon (kódformázó eszközök, linterek, csomagkezelők, fordítók, preprocesszorok, tesztelőeszközök stb.). A Dark-ban nincs szükség helyben telepített függőségek kezelésére, helyi Docker telepítésre vagy más lépésekre, hogy bármilyen szinten hasonlóságot biztosítsanak a fejlesztési és a termelési környezet között. , még csak úgy sem tetteti magát, hogy törekszünk rá.
Ahelyett, hogy egy klónozott lokális környezetet hoznánk létre, a Dark funkcióváltói egy új homokozót hoznak létre a termelésben, amely helyettesíti a fejlesztési környezetet. A jövőben azt is tervezzük, hogy homokozókat hozzunk létre az alkalmazás más részeihez (például az adatbázis azonnali klónjaihoz), bár ez jelenleg nem tűnik olyan fontosnak.
Ágak és telepítések
Jelenleg számos módja van az új kód bevezetésének a rendszerekbe: git ágak, telepítési szakaszok és funkcióváltók. Ezek egy problémát oldanak meg a munkafolyamat különböző részein: a git a telepítés előtti szakaszokban, a telepítés az új kódra való váltás pillanatában, míg a funkcióváltók a új kód kontrollált kiadására.
A leghatékonyabb módszer a funkcióváltók (amelyek a legkönnyebben érthetők és használhatók). Ezekkel teljesen el lehet hagyni a másik kettő módszert. Különösen hasznos elhagyni a telepítést - ha már úgyis funkcióváltókat használunk a kód aktiválására, akkor a lépés a szerverek új kódra váltására csak felesleges kockázatokat teremt.
A git használata nehézkes, különösen a kezdők számára, és ez nagymértékben korlátozza, de cserébe vannak kényelmes ágai. Sok git hibát simítottunk el. A Dark valós időben szerkeszthető és lehetővé teszi a Google Dokumentumok stílusú együttműködést, hogy ne kelljen kódot küldeni, és ritkábban kelljen rebázis együttműködni és egyesíteni.
A funkciók átkapcsolói a biztonságos telepítés alapját képezik. Az azonnali telepítésekkel együtt lehetővé teszik a koncepciók gyors tesztelését kis szegmensekben, alacsony kockázattal, ahelyett, hogy egy nagyobb változtatást alkalmaznánk, amely összeomlaszthatja a rendszert.
Verziókezelés
A funkciók és típusok módosításához verziókezelést alkalmazunk. Ha módosítani kíván egy funkciót, a Dark létrehoz egy új verziót az adott funkcióból. Ezt a verziót később hívhatja a HTTP vagy eseménykezelő átkapcsolójával. (Ha ez a funkció mélyen van a hívások gráfjában, minden egyes funkció új verziót kap. Talán túlzásnak tűnik, de a funkciók nincsenek zavarban, ha nem használja őket, így ezt szinte észre sem veszi.)
Ugyanezek miatt verzionáljuk a típusokat is. A típusainkról részletesen beszéltünk. .
A funkciók és típusok verziókezelésének köszönhetően fokozatosan módosíthatja az alkalmazást. Ellenőrizheti, hogy minden egyes kezelő új verzióval működik, anélkül, hogy az összes változtatást egyszerre kellene végrehajtani az alkalmazásokban (de rendelkezésünkre állnak eszközök, hogy ezt gyorsan meg tudja tenni, ha úgy kívánja).
Ez lényegesen biztonságosabb, mint az összes egyidejű telepítése, ahogy az most történik.
Új verziójú csomagok és a standard könyvtár
Amikor frissít egy csomagot a Dark-ban, nem helyettesítjük azonnal az összes funkció vagy típus használatát a teljes kódalapban. Ez nem biztonságos. A kód továbbra is ugyanazt a verziót használja, amelyet használt, és ön új verzióra frissíti az egyes esetek funkcióit és típusait átkapcsolókkal.
A Dark automatikus folyamatának részletét ábrázoló képernyőkép, amely két verzióját mutatja a Dict::get funkciónak. A Dict::get_v0 az Any típust adta vissza (amelytől eltekintünk), míg a Dict::get_v1 az Option típust adja vissza.
Gyakran új funkciót biztosítunk a standard könyvtárban és kizárjuk a régi verziókat. A régi verziókat használó felhasználók megtartják hozzáférésüket, de az új felhasználók nem férhetnek hozzájuk. Olyan eszközöket fogunk biztosítani, amelyek segítségével a felhasználókat egy lépésben át tudjuk vinnik az új verziókra, szintén a funkciók átkapcsolóival.
A Dark egyedülálló lehetőséget kínál: mivel végrehajtjuk a munkakódját, saját magunk tesztelhetjük az új verziókat, összehasonlítva az új és régi lekérdezések kimenetét, hogy értesítsük Önt a változásokról. Ennek eredményeként a csomagok frissítése, amely gyakran blind módon történik (vagy alapos tesztelést igényel a biztonság érdekében), lényegesen kisebb kockázatokkal jár, és automatikusan végrehajtható.
Új Dark verziók
A Python 2-ről Python 3-ra való átállás egy évtizedig tartott, és még mindig problémákat okoz. Mivel a Dark-ot a folyamatos szállítás érdekében hozzuk létre, figyelembe kell vennünk ezeket a nyelvi változásokat.
Amikor kis változtatásokat végzünk a nyelvben, új Dark verziót készítünk. A régi kód a régi Dark verzióban marad, míg az új kód az új verzióban használatos. Új Dark verzióra való átálláshoz lehet switch-eket vagy funkcióverziókat lehet használni.
Ez különösen hasznos, figyelembe véve, hogy a Dark még nagyon új. Sok nyelvi vagy könyvtári változtatás kudarcra futhat. A nyelv fokozatos verziózása lehetővé teszi, hogy apró frissítéseket végezzünk, így nem kell sietnünk, és sok nyelvi döntést halaszthatunk, amíg több felhasználónk nem lesz, ami nagyobb információt jelent.
Adatbázis-migrációk
Biztonságos adatbázis-migrációhoz van :
- A kód átírása, hogy támogassa az új és régi formátumokat
- Az összes adat átalakítása új formátumban
- A régi adat-hozzáférés eltávolítása
Ennek eredményeként az adatbázis-migráció elhúzódik és sok erőforrást igényel. Elavult séma halmozódik fel, mert még a legegyszerűbb feladatok, mint például egy tábla vagy oszlop nevének javítása, nem érik meg a ráfordított időt.
A Dark hatékony adatbázis-migrációs platformmal rendelkezik, amely (reméljük) annyira leegyszerűsíti a folyamatot, hogy megszabadul a félelmétől. A Dark összes adattárolója (kulcs-érték pár tárolók vagy tartós hash táblák) típussal rendelkezik. Az adattároló átviteléhez egyszerűen új típust és visszagörgető és visszaállító funkciót rendel hozzá az értékek két típus közötti átalakításához.
A Dark adatfolyamokhoz való hozzáférés verziókezelési változóneveken keresztül történik. Például a Users adatfolyam elsődlegesen Users-v0 néven fog szerepelni. Amikor új verzió jön létre más típusban, a név megváltozik Users-v1-re. Ha az adatokat Users-v0-n keresztül mentették el, és hozzájuk Users-v1-en keresztül szeretne hozzáférni, törlési funkció lép életbe. Ha az adatokat Users-v1-en keresztül mentették el, és hozzájuk Users-v0-n keresztül szeretne hozzáférni, visszaállító funkció lép életbe.
Az adatbázis-migrációs képernyő az öreg adatbázis mezőneveivel, a törlési és visszaállítási kifejezésekkel, valamint a migráció aktiválásának utasításaival rendelkezik.
Használjon funkciókapcsolókat az Users-v0 hívások Users-v1 verzióra irányításához. Ezt egy HTTP-kezelnél egyszerre végezheti el a kockázatok csökkentése érdekében, és a kapcsolók egyedi felhasználókra is működnek, így ellenőrizheti, hogy minden a vártnak megfelelően működik-e. Amikor már nem marad felhasználó az Users-v0 számára, a Dark a háttérben átalakítja a megmaradt adatokat régi formátumból újra. Ezt még csak észre sem veszi.
Tesztelés
A Dark egy melynek módosíthatatlan értékei vannak, így a tesztelési felület jelentősen kisebb, mint a dinamikus típusú objektumorientált nyelvek esetében. De a tesztelést így is el kell végezni.
A Dark automatikusan, háttérben futtatja a moduláris teszteket a szerkesztett kódra, és alapértelmezés szerint ezeket a teszteket futtatja a funkciókapcsolókra vonatkozóan is. A jövőben szeretnénk statikus típusok segítségével automatikusan élni a fuzzing teszteléssel a hibák feltárására.
Továbbá, a Dark a termelési infrastruktúráját futtatja, ami új lehetőségeket nyit meg. Automatikusan eltároljuk a HTTP-kéréseket a Dark infrastruktúrában (míg jelenleg minden kérelmet eltárolunk, később szeretnénk válogatásra váltani). Ezen állapotok alapján teszteljük az új kódot és hajtjuk végre a moduláris teszteket, és ha akarja, könnyen konvertálhatja az érdekes kérdéseket moduláris tesztekké.
Amiktől megszabadultunk
Mivel nincs telepítés, de vannak funkciókapcsolók, a telepítési folyamat körülbelül 60%-a nem szükséges. Nincs szükség git-ágakra vagy húzási kérelmekre, a háttérforrások és -konténerek összeállítására, a források és konténerek regisztrálására, vagy a Kubernetes telepítési lépéseire.
A hagyományos folyamatos szállítási pipeline (balra) és a Dark folyamatos szállítás (jobbra) összehasonlítása. A Dark szállítás 6 lépésből és 1 ciklusból áll, míg a hagyományos változat 35 lépést és 3 ciklust tartalmaz.
A Dark deployment csak 6 lépésből és 1 ciklusból (az ismétlődő lépések) áll, míg a modern folyamatos szállítási pipeline 35 lépést és 3 ciklust tartalmaz. A Dark-ban a tesztek automatikusan futnak, és ezt még csak nem is látja; a függőségek automatikusan települnek; a git vagy a Github használata már nem szükséges; a Docker konténerek összeszerelése, tesztelése és küldése nem szükséges; a Kubernetes telepítés már nem szükséges.
A Dark-ban még a megmaradt lépések is egyszerűbbé váltak. Mivel a funkciókapcsolókat egyetlen művelettel lehet kezelni, nem kell újra végigmenni az egész telepítési pipeline-on a régi kód eltávolításához.
A lehető legegyszerűbbé tettük a kód szállítását, csökkentve a folyamatos szállítás időtartamát és kockázatait. Emellett jelentősen egyszerűsítettük a csomagok frissítését, az adatbázis-migrációkat, a tesztelést, a verziókezelést, a függőségek telepítését, a fejlesztési és éles környezet közötti egyenlőséget, valamint a gyors és biztonságos nyelvfrissítéseket.
A kérdéseidre itt válaszolok .
A Dark eszközről többet szeretnél tudni? Olvasd el a , (vagy ) vagy . Ha szeptemberben a StrangeLoopra mész, .
Forrás: habr.com
