Under de senaste åtta åren har vi med särskild uppmärksamhet sett utvecklingen av webbekosystem som Ruby och Ruby on Rails, vilket är ett av de bästa verktygen för backend-infrastruktur som vi använder på båda webb- och mobilapputveckling.
Åtta år är en lång tid i livet för någon teknik på en oändlig utvecklingsprocess. Av den anledningen har vi sett projekt byggda i det nästan glömda Räls 3.1 ovanpå Rubin 1.9, utan nyckelordsargument eller säkra navigeringsoperatörer, till den senaste Räls 5.2.2 på Rubin 2.5.3. Lägg nu till flera olika versioner av ädelstenar och en skvätt av paketets beroenden - ovanpå olika operativsystem - och vi får en myriad av projektmiljöer.
I sådana scenarier blir det en kritisk och brådskande uppgift att skapa en utvecklingsmiljö som tillåter replikering av villkoren för att reproducera en bugg, eller till och med ha ett snabbt sätt att kontrollera projektets nuvarande tillstånd för att uppskatta ansträngningen att införa en ny funktion.
Att växla mellan projekt med olika konfigurationer och miljöer blir svårare, och övergången till gamla projekt för att tillhandahålla en hot-fix blir en fruktansvärd och frustrerande uppgift.
Detta beror på att installationen av gamla projekt tar längre tid än tiden att reproducera, fixa och distribuera en ny snabbkorrigering.
Det är inte kul.
Det är inte hälsosamt.
Det är inte effektivt.
Det blev uppenbart att det fanns ett behov av att bevara utvecklingsmiljön på ett bärbart och begränsat sätt, vilket möjliggjorde en smidigare övergång mellan projekt.
Det är när Vagrant gick in i aktion.
Vagrant är ett populärt verktyg för deklaration och hantering av virtuell maskin med öppen källkod från Hashicorp. Dess popularitet kommer från det enkla Ruby syntax som beskriver en resurs från basavbildningen, resursallokeringsfunktionen och andra mindre provisionskonfigurationer, till exempel hur den monterar en delad mapp eller krokprovideringsskript för att förbereda utvecklingsmiljön.
Det kommer också med en mängd olika leverantörer som kan stödja Vagrant på flera plattformar, med skapandet av en lokal virtuell maskin på VirtualBox, VMware och Hyper-V.
Dessutom utvidgades det av samhället för att stödja populära värdtjänster som Amazon webbtjänster eller DigitalOcean, så att de kan arbeta som leverantörer och abstrahera hela skapelses- och hanteringsprocessen Droppar och EC2-instanser.
På så sätt kan utvecklare simulera och samordna flera nodarkitekturer genom ett välbekant gränssnitt. Och den bästa delen? Alla specifikationer görs på en enda textfil, som enkelt kan buntas in i ett projekt och hållas under versionskontroll, redo för utcheckning.
Vagrant erbjuder ett snabbt och rent sätt att interagera med utvecklingsmiljöer, med ett operativsystem som liknar iscensättning och produktion. Detta ökar applikationernas motståndskraft och gör dem mindre benägna att misslyckas som förblir dolda i utvecklingsmiljöer. Men i sig är Vagrant inte det bästa verktyget för att tillhandahålla en virtuell maskin.
Med hänsyn till detta, Ansibel var vårt valda vapen för att tillhandahålla de virtuella maskinerna. Det kräver ingen form av agent som körs på den virtuella maskinen, som andra alternativ som Kock och Marionett skulle, och gör det mesta av sitt arbete Tryck, via SSH.
Dess specifikationer görs i EL, vilket gör det ganska läsbart och lätt att förstå, så att vem som helst snabbt kan ta med varje instruktion och ändra ett provisionsskript för att passa nya behov, till exempel att lägga till ett extra systembibliotek för en ny pärla. Skriptens övergripande struktur möjliggör också en tydlig bild av de ändringar som införs, vilket bidrar till att medföra de nya beroenden som läggs till under kodgranskningar och säkerhetsrevisioner. Det är något lätt att missa när man utvärderar ett vanligt skalskript med långa kommandon som ser ut som ett oändligt lasttåg.
Med Vagrant, Ansibles skript är bara vanlig text som kan lagras med projektet, under versionskod.
Liksom vad som händer med alla andra innovationer, Vagrant och Ansibles introduktionen kan möta olika grader av motstånd vid dess antagande. Utvecklare som tilldelas bara ett projekt under längre perioder kanske inte fullt ut uppskattar denna nödvändighet eller värderar dess portabilitet, och det är förståeligt.
Men när utvecklare hoppar från projekt till projekt och pysslar med olika saker dagligen, kommer de att få en bättre förståelse för hur värdefullt Vagrant är. Det är inte ett ovanligt scenario att fixa något på en gammal Python projekt på morgonen, byt till Ruby underhåll på eftermiddagen och pyssla med Node.js Nästa dag till exempel.
Vagrant gör det möjligt att effektivt ändra projektets sammanhang.
Ansibel alone är ett kraftfullt provisioneringsverktyg som effektivt interagerar med flera VPS och kan användas för att distribuera förändringar i stora kluster. Medan en massiv användning av Ansibel att hantera stora kluster är inte förutsebart inom en snar framtid, genom att anta det konsekvent kan man återanvända de redan byggda Ansible-skripten för att installera virtuella utvecklingsmaskiner, tillhandahålla VPS som kommer att vara värd för både iscensättnings- och produktionsmiljöer.
Det är mestadels anpassat till bästa praxis för utveckling, eftersom det bygger bra och flexibla provisioneringsskript som kan uppfylla mer än att bara etablera en virtuell maskin och återanvända dem när du försöker distribuera programmet till flera miljöer.
Medan Vagrant kan användas som ett verktyg för att skapa och hantera VPS för utveckling, eller till och med för att skapa iscensättnings- och produktionsmiljöer, finns det andra verktyg som kan användas för att uppnå samma mål, till exempel Terraform.
Men det är en helt ny historia för en annan dag...
Tyckte den här artikeln intressant? Du kanske gillar dessa också!
Din dagliga webbutvecklare som gillar att gömma sig i backend. Javascript och Ruby är min sylt. Jag fumlar fortfarande med Docker och mina byggnader går sönder ganska ofta.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
