Kā Dark izvērš kodu 50 ms.

Jo ātrāk notiek izstrādes process, jo ātrāk attīstās tehnoloģiju uzņēmums.

Diemžēl mūsdienu lietojumprogrammas darbojas pret mums — mūsu sistēmām jāatjaunojas reāllaikā, netraucējot nevienam un neizraisot dīkstāves vai traucējumus. Ieviešana šādās sistēmās ir sarežģīta uzdevums un prasa sarežģītus nepārtrauktas piegādes kanālus pat mazās komandās.

Šie kanāli parasti ir šauri, lēni un nav īpaši uzticami. Izstrādātājiem vispirms ir jāizveido tie manuāli, un pēc tam tie ir jākontrolē, tāpēc uzņēmumi bieži pieņem veselas DevOps komandas, lai to paveiktu.

No šiem kanāliem atkarīga izstrādes ātrums. Labākajām komandām ieviešana aizņem 5–10 minūtes, taču parasti tas notiek daudz ilgāk, un viena ieviešana var ilgt vairākas stundas.

Dark to paveic 50 ms. Piekdesmit. Milisekundes.. Dark — tas ir integrēts risinājums ar programmēšanas valodu, redaktoru un infrastruktūru, izveidota īpaši nepārtrauktai piegādei, un visi aspekts Dark, tostarp pati valoda, ir izstrādāti ar domu par drošu un momentālu ieviešanu.

Kāpēc nepārtrauktās piegādes kanāli ir tik lēni?

Pieņemsim, ka mums ir Python tīmekļa lietojumprogramma un jau esam izveidojuši brīnišķīgu un mūsdienīgu nepārtrauktas piegādes kanālu. Izstrādātājam, kurš katru dienu strādā pie šī projekta, viena nenozīmīga labojuma ieviešana izskatīsies apmēram tā:

Izmaiņu veikšana

• Jaunas zara izveide git
• Izmaiņu veikšana funkcijas pārslēgšanai
• Modulāro testu veikšana, lai pārbaudītu izmaiņas ar funkcijas pārslēgšanu un bez

Pull pieprasījums

• Izmaiņu apstiprināšana
• Izmaiņu nosūtīšana attālinātajam repozitorijam GitHub
• Pull pieprasījums
• CI būvēšana tiek automātiski veikta fonā
• Koda pārskats
• Vēl dažas pārskatīšanas, ja nepieciešams
• Izmaiņu apvienošana ar git master.

CI darbojas uz mastera

• Frontend atkarību uzstādīšana caur npm
• Resursu HTML+CSS+JS būvēšana un optimizācija
• Modulāro un funkcionālo testu izpilde frontendā
• Python atkarību uzstādīšana no PyPI
• Modulāro un funkcionālo testu izpilde backendā
• Integrācijas testēšana abos galos
• Resursu nosūtīšana frontendā uz CDN
• Python program container assembly
• Sending the container to the registry
• Kubernetes manifest update

Replacing old code with new

• Kubernetes launches multiple instances of the new container
• Kubernetes waits for the instances to become operational
• Kubernetes adds instances to the HTTP load balancer
• Kubernetes waits until the old instances are no longer in use
• Kubernetes stops the old instances
• Kubernetes repeats these operations until the new instances replace all the old ones

Enabling the new feature toggle

• New code is enabled only for itself to ensure everything is functioning correctly
• New code is enabled for 10% of users, operational and business metrics are monitored
• New code is enabled for 50% of users, operational and business metrics are monitored
• New code is enabled for 100% of users, operational and business metrics are monitored
• Finally, you repeat the entire procedure to remove the old code and toggle

The process depends on tools, language, and service-oriented architecture usage, but generally looks like this. I have not mentioned deployments with database migrations, as this requires careful planning, but below I will explain how Dark deals with this.

There are many components, and many of them can easily cause bottlenecks, failures, temporary contention, or crash the working system.

And since these pipelines are almost always created for special cases, they are hard to rely on. Many people have days when the code cannot be deployed because there are issues in the Dockerfile, one of the dozens of services has failed, or the necessary specialist is on vacation.

Worse yet, many of these steps do not accomplish anything useful at all. They were needed earlier when we deployed code directly for users, but now we have toggles for the new code, and these processes have separated. As a result, the step where code is deployed (old is replaced with new) has now simply become an unnecessary risk.

Of course, this is a very well-thought-out pipeline. The team that created it did not spare time and money for rapid deployment. Usually, deployment pipelines are much slower and less reliable.

Implementing continuous delivery in Dark

Nepārtraukta piegāde ir tik svarīga uzņēmumam Dark, ka mēs sākumā centāmies sasniegt laiku, kas ir mazāks par vienu sekundi. Mēs pārskatījām visus procesus un noņemām visu lieko, kā arī uzlabojām atlikušos. Lūk, kā mēs izslēdzām soļus.

Džesija Frazela (Jessie Frazelle) izdomāja jauno terminu „deployless” (neprasot izvēršanu) Future of Software Development konferencē Reikjavīkā.

Mēs tūlīt nolēmām, ka Dark balstīsies uz „deployless” koncepciju (pateicoties Džesijai Frazelai par neologismu). Deployless nozīmē, ka jebkāds kods ir momentāni izvērsts un gatavs izmantošanai ražošanā. Protams, mēs nepalaidīsim garām bojātu vai nepilnīgu kodu (drošības principi tiks aprakstīti zemāk).

Dark demonstrācijas laikā bieži tika jautāts, kā mums izdevās tik ļoti paātrināt izvēršanu. Dīvains jautājums. Cilvēki, šķiet, domā, ka mēs izdomājām kādu supersistēmu, kas salīdzina kodu, kompilē to, iepako traukā, запуска виртуālo mašīnu, aukstā pudiņa konteineru un visu tādu lietu, — un viss tas notiek 50 ms laikā. Maz ticams, ka tas ir iespējams. Bet mēs izveidojām īpašu izvēršanas dzinēju, kuram viss šis process vispār nav nepieciešams.

Dark sāk izpildīt interpretatorus mākoņos. Pieņemsim, ka jūs rakstāt kodu funkcijā vai HTTP vai notikumu apstrādātājā. Mēs nosūtām diff uz abstrakto sintaktisko koku (koda realizāciju, ko iekšēji izmanto mūsu redaktors un serveri) uz mūsu serveriem un tad izpildām šo kodu, kad saņemam pieprasījumus. Tātad izvēršana izskatās vienkārši kā pieticīgs ieraksts datu bāzē — momentāna un elementāra. Izvēršana notiek tik ātri, jo iekļauj minimālo.

Nākotnē plānojam padarīt Dark par infrastruktūras kompilatoru, kas radīs un izpildīs ideālu infrastruktūru augstas veiktspējas un uzticamības lietotnēm. Momentāna izvēršana, protams, nekur nepazudīs.

Droša izvēršana

Strukturētais redaktors

Kods Dark tiek rakstīts Dark redaktorā. Strukturētais redaktors nepieļauj sintaktiskas kļūdas. Patiesībā Dark nav neviena analizatora. Kamēr jūs ievadat tekstu, mēs tieši strādājam ar abstrakto sintaktisko koku (AST), kā Paredit, Sketch-n-Sketch, Tofu, Prune un MPS.

Ikvienam nepabeigtam kodam Dark ir pieļaujama izpildes semantika, aptuveni kā typed holes Hazel valodā. Piemēram, ja jūs maināt funkcijas izsaukumu, mēs saglabājam veco funkciju, kamēr jaunā kļūst derīga.

Katram programmas elementam Dark ir sava nozīme, tāpēc neizpildīts kods netraucē izpildītajam darboties.

Rediģēšanas režīmi

Jūs rakstāt kodu Dark divos gadījumos. Pirmais: jūs rakstāt jaunu kodu un esat vienīgais lietotājs. Piemēram, tas ir REPL, un citi lietotāji nekad tam netiks klāt, vai tā ir jauna HTTP maršruta piekļuve, uz kuru jūs nekur neatsaucaties. Šeit var strādāt bez jebkādām piesardzības darbībām, un šobrīd jūs vairāk vai mazāk tā arī strādājat izstrādes vidē.

Otra situācija: kods jau tiek izmantots. Ja caur kodu plūst satiksme (funkcijas, notikumu apstrādātāji, datu bāzes utt.), jāievēro piesardzība. Tāpēc mēs bloķējam visu izmantoto kodu un pieprasām izmantot strukturētākus rīkus tā rediģēšanai. Par strukturētajiem rīkiem es runāšu zemāk: funkciju slēdži HTTP un notikumu apstrādātājiem, jaudīga migrācijas platforma datu bāzēm un jauna versiju vadības metode funkcijām un tipiem.

Funkciju slēdži

Viens no veidiem kā samazināt lieku sarežģītību Dark ir atrisināt vairākas problēmas ar vienu risinājumu. Funkciju slēdži veic daudz dažādu uzdevumu: vietējās izstrādes vides aizvietošana, git zari, koda izvietošana un, protams, tradicionālais lēnais un kontrolētais jauna koda izlaišana.

Funkciju slēdža izveide un izvietošana tiek veikta mūsu redaktorā vienā operācijā. Tas izveido tukšu telpu jaunajam kodam un nodrošina piekļuves kontroli gan vecajam, gan jaunajam kodam, kā arī pogas un komandas pakāpeniskai pārejai uz jauno kodu vai tā izslēgšanai.

Funkciju slēdži ir iebūvēti Dark valodā, un pat neizpildītie slēdži veic savu uzdevumu — ja nosacījums slēdžā netiek izpildīts, tiks izpildīts vecais bloķētais kods.

Izstrādes vide

Funkciju pārslēgi aizvieto vietējo izstrādes vidi. Šodien komandām ir grūti sekot līdzi tam, lai visi izmantotu vienādas instrumentu un bibliotēku versijas (koda formatēšanas rīki, linters, pakotņu pārvaldnieki, kompilatori, priekšprocesori, testēšanas rīki utt.). Ar Dark nav nepieciešams lokāli instalēt atkarības, pārvaldīt lokālo Docker instalāciju vai veikt citus pasākumus, lai nodrošinātu vismaz kādu līdzību starp izstrādes un ražošanas vidi. Ņemot vērā, ka šāda līdzība tomēr nav iespējama, mēs pat neizliksimies, ka tiecamies uz to.

Tā vietā, lai izveidotu klonētu vietēju vidi, Dark funkciju pārslēgi veido jaunu smilšu kasti ražošanā, kas aizvieto izstrādes vidi. Nākotnē plānojam izveidot smilšu kasti citām lietojumprogrammas daļām (piemēram, momentānos datubāzu klonos), lai gan pagaidām tas neizskatās tik svarīgi.

Zaru un izvietojumu

Pašlaik ir vairāki veidi, kā ieviest jaunu kodu sistēmās: git zarus, izvietošanas posmus un funkciju pārslēgus. Tie risina vienu problēmu dažādās darba plūsmas daļās: git — izvietošanas posmos, izvietojums — pārejā no vecā koda uz jauno, bet funkciju pārslēgi — kontrolētā jauna koda izlaišanas brīdī.

Visefektīvākais veids ir funkciju pārslēgi (tāpat kā visvieglāk saprotamais un lietojamais). Ar tiem var pilnībā atteikties no abiem atlikušajiem metodēm. Īpaši noderīgi ir atteikties no izvietošanas — ja mēs tomēr izmantojam funkciju pārslēgus, lai iespējo kodu, tad serveru pārejas uz jauno kodu solis tikai rada liekas riskus.

Git ir grūti lietot, īpaši iesācējiem, un tas būtiski ierobežo tā lietošanu, tomēr tam ir ērti zari. Mēs esam izlabojuši daudzas git nepilnības. Dark tiek rediģēts reālajā laikā un nodrošina sadarbības iespējas kā Google Dokumentiem, lai nebūtu jānosūta kods un varētu retāk veikt rebazēšanu un saplūšanu.

Funkciju slēdži ir droša izvietošanas pamats. Kopā ar tūlītējiem izvietojumiem tie ļauj ātri pārbaudīt koncepcijas mazās daļās ar zemu risku, nevis ieviest vienu lielu izmaiņu, kas var sabojāt sistēmu.

Versiju kontrole

Funkciju un tipu maiņai mēs izmantojam versiju kontroli. Ja vēlaties mainīt funkciju, Dark izveido jaunu šīs funkcijas versiju. Pēc tam jūs varat izsaukt šo versiju, izmantojot slēdzi HTTP apstrādātājā vai notikumos. (Ja tas ir aicinājums dziļi izsaukumu grafikā, pa ceļam tiek izveidota jauna versija katrai funkcijai. Tas var likties pārspīlēti, bet funkcijas netraucē, ja jūs tās neizmantojat, tāpēc jūs to pat nepamanīsiet.)

Tieši šo pašu iemeslu dēļ mēs versējam tipus. Par mūsu tipu sistēmu mēs detalizēti pastāstījām iepriekšējā ierakstā.

Pateicoties funkciju un tipu versiju kontrolei, jūs varat pakāpeniski veikt izmaiņas lietojumprogrammā. Varat pārbaudīt, ka katrs individuālais apstrādātājs darbojas ar jauno versiju, neatkarīgi no tā, vai uzreiz veicat visas izmaiņas lietojumprogrammā (taču mums ir rīki, lai to ātri izdarītu, ja vēlaties).

Tas ir daudz drošāk nekā uzreiz izvietot visu kopā, kā tas notiek tagad.

Jaunas pakotņu versijas un standarta bibliotēka

Kad jūs atjaunināt pakotni Dark, mēs uzreiz neaizvietojam katras funkcijas vai tipa izmantošanu visā kodu bāzē. Tas nav droši. Kods turpina izmantot to pašu versiju, kādu tas izmantoja, un jūs atjaunināt funkciju un tipu izmantošanu līdz jaunai versijai katrā atsevišķā gadījumā, izmantojot slēdžus.

Ekrānuzņēmums no daļas automatizētā procesa Dark, kas parāda divas funkcijas Dict::get versijas. Dict::get_v0 atgrieza tipu Any (no kura mēs atteiksimies), bet Dict::get_v1 atgriež tipu Option.

Mēs bieži sniedzam jaunas funkcijas standarta bibliotēkā un izslēdzam vecās versijas. Lietotājiem ar vecajām versijām kodā saglabās pieeju tām, bet jaunajiem lietotājiem tās vairs nebūs pieejamas. Mēs plānojam nodrošināt rīkus, lai pārceltu lietotājus no vecajām versijām uz jaunajām vienā solī, un atkal, izmantojot funkciju slēdžus.

Dark arī sniedz unikālu iespēju: tā kā mēs izpildām jūsu darba kodu, mēs varam paši testēt jaunās versijas, salīdzinot rezultātus jaunajiem un vecajiem pieprasījumiem, lai informētu jūs par izmaiņām. Rezultātā pakotņu atjaunināšana, kas bieži tiek veikta akli (vai nepieciešama rūpīga testēšana drošības nolūkos), rada daudz mazāk risku un var notikt automātiski.

Jaunās Dark versijas

Pāreja no Python 2 uz Python 3 noritēja desmit gadus un joprojām ir aktuāla problēma. Tā kā mēs izstrādājam Dark nepārtrauktai piegādei, šīs valodas izmaiņas ir jāņem vērā.

Kad mēs ieviešam nelielas izmaiņas valodā, mēs izveidojam jaunu Dark versiju. Vecais kods paliek vecajā Dark versijā, bet jaunais kods tiek lietots jaunajā versijā. Pārslēgšanu uz jauno Dark versiju var veikt, izmantojot slēdžus vai funkciju versijas.

Tas ir īpaši noderīgi, ņemot vērā, ka Dark ir izveidots pavisam nesen. Daudzas valodas vai bibliotēkas izmaiņas var būt neveiksmīgas. Pakāpeniskā valodas versiju pārvaldība ļauj mums veikt nelielus atjauninājumus, t.i., mēs varam nesteigties un atlikt daudzas valodas lēmumu pieņemšanas, kamēr mums nav vairāk lietotāju, tātad arī vairāk informācijas.

Datu bāzu migrācijas

Drošai datu bāzu migrācijai pastāv standarta formula:

• Pārrakstīt kodu, lai atbalstītu jaunos un vecos formātus
• Pārveidot visus datus jaunajā formātā
• Noņemt veco piekļuvi datiem

Rezultātā datu bāzes migrācija tiek aizkavēta un prasa daudz resursus. Un mums uzkrājas novecojušas shēmas, jo pat vienkāršas darbības, piemēram, tabulas vai kolonnas nosaukuma labošana, nav tā vērta.

Dark ir efektīva datu bāzu migrācijas platforma, kas (mēs ceram) tik ļoti vienkāršos procesu, ka jūs pārstāsiet to baidīties. Visi datu krātuvju veidi Dark (atslēgas-vērtības pāru glabātuves vai pastāvīgās hash tabulas) ir definēti. Lai pārvietotu datu krātuvi, jūs vienkārši piešķirat tai jaunu tipa un atgriešanas funkciju, lai pārvērstu vērtības starp diviem tipiem.

Piekļuve datu krātuvei Dark tiek nodrošināta caur versiju nosaukumiem. Piemēram, datu krātuve Users sākotnēji tiks saukta par Users-v0. Kad tiek izveidota jauna versija ar citu tipu, nosaukums tiek mainīts uz Users-v1. Ja dati ir saglabāti, izmantojot Users-v0, bet jūs piekļūstat tiem caur Users-v1, tiek pielietota atgriešanas funkcija. Ja dati ir saglabāti, izmantojot Users-v1, bet jūs piekļūstat tiem caur Users-v0, tiek pielietota atgriešanas funkcija.

Datu bāzes migrācijas ekrāns ar vecās datu bāzes lauku nosaukumiem, atgriešanas un atgriešanas izteiksmēm un instrukcijām migrācijas iekļaušanai.

Izmantojiet funkciju slēdžus, lai novirzītu izsaukumus no Users-v0 uz versiju Users-v1. To var izdarīt pa vienam HTTP apstrādātājam, lai samazinātu riskus, un slēdži darbojas atsevišķiem lietotājiem, lai jūs varētu pārbaudīt, ka viss darbojas kā paredzēts. Kad izžūs visus Users-v0 lietotājus, Dark fonā pārveidos visas atlikušo datus no vecā formāta uz jauno. Jūs to pat nemanīsiet.

Testēšana

Dark ir funkcionāla programmēšanas valoda ar statisku tipizāciju un nemainīgiem vērtībām, tāpēc tā testēšanas virsma ir ievērojami mazāka salīdzinājumā ar objektorientētām valodām ar dinamisku tipizāciju. Bet testēšana tāpat ir nepieciešama.
Dark redaktors automātiski veic moduļu testus fonā rediģējamajam kodam, un pēc noklusējuma šie testi tiek veikti visiem funkciju slēdžiem. Nākotnē mēs vēlamies izmantot statiskos tipus, lai automātiski veiktu fuzzeru testus kodā, lai atrastu kļūdas.

Turklāt Dark realizē jūsu infrastruktūru ražošanā, kas atver jaunas iespējas. Mēs automātiski saglabājam HTTP pieprasījumus Dark infrastruktūrā (kamēr mēs saglabājam visus pieprasījumus, bet vēlāk vēlamies pāriet uz izlasi). Mēs testējam jauno kodu pēc tiem un veicam moduļu testus, un, ja vēlaties, jūs varat viegli pārvērst interesantus pieprasījumus moduļu testos.

No kā mēs esam atbrīvojušies

Tā kā mums nav izsniegšanas, bet ir funkciju slēdži, aptuveni 60% izsniegšanas procesā paliek novārtā. Mums nav nepieciešami git zari vai pieprasījumi, servera resursu un konteineru būvēšana, resursu un konteineru nosūtīšana reģistriem vai izsniegšanas soļi Kubernetes.

Salīdzinošs standarta nepārtrauktās piegādes līnijas attēlojums (kreisajā pusē) un Dark nepārtrauktās piegādes (labajā pusē). Dark piegāde sastāv no 6 soļiem un viena cikla, savukārt tradicionālā versija ietver 35 soļus un 3 ciklus.

Dark izvietošanā ir tikai 6 soļi un 1 cikls (soļi, kas atkārtojas vairākas reizes), kamēr mūsdienu nepārtrauktās piegādes līnija sastāv no 35 soļiem un 3 cikliem. Dark testi tiek palaisti automātiski, un jūs to pat neievērojat; atkarības tiek instalētas automātiski; viss, kas saistīts ar git vai Github, vairs nav nepieciešams; nav nepieciešams savākt, testēt un nosūtīt Docker konteinerus; izvietošana Kubernetes vairs nav nepieciešama.

Pat palikušie soļi Dark ir kļuvuši vienkāršāki. Kad funkciju slēdži tiek pārvaldīti ar vienu darbību, nav jādodas vēlreiz cauri visai izvietošanas līnijai, lai izdzēstu veco kodu.

Mēs cik vien iespējams esam atvieglinājuši koda piegādi, samazinot laiku un riskus, kas saistīti ar nepārtrauktu piegādi. Mēs arī ievērojami atvieglojam pakotņu atjaunināšanu, datu bāzu migrāciju, testēšanu, versiju pārvaldību, atkarību instalēšanu, vienotību starp attīstības un ražošanas vidi, kā arī ātrus un drošus valodas versiju uzlabojumus.

Es atbildu uz jautājumiem par to HackerNews.

Lai uzzinātu vairāk par Dark ierīci, izlasiet rakstu par Dark, sekojiet mums Twitter (vai man) vai pierakstieties uz beta versiju un saņemiet paziņojumus par nākamajiem ierakstiem. Ja dodaties uz StrangeLoop septembrī, nāciet pie mums uz palaišanu.

Avots: habr.com