Förbered utvecklingsmiljön

först och främst, sätt upp utvecklingsmiljön. Jag kommer fortfarande ihåg när jag börjar min utvecklingsresa, den mest smärtsamma perioden inrättades utvecklingsmiljön, speciellt som den här typen av projekt (mer än 3 system), vi måste ladda ner olika tjänster (burk, binär, etc.) för att få det öppet körs lokalt, men tack för containertekniken, genom att använda enkel docker-compose.YML-fil, vi kan bootstrap alla viktiga applikationer / komponenter vi behövde.

se, hur enkelt är det?

utveckling / kodning

Låt oss börja den roliga delen, Go är mitt senaste premiärutvecklingsspråk, men varför jag valde att gå till Datapipelineutvecklingen på grund av dess enkelhet, prestanda och typsäker. Här kommer jag inte att förklara fördelarna med Go, om du är intresserad av, kolla Golang.org.

som vanligt, om du kolla mitt tidigare inlägg

hur man bygger en MachineBox.io API med 100% enhetstestning täckning genom att använda Go

du vet, jag kommer att använda samma applikationsstruktur.

1. Bygg anslutningen genom att skapa Env Struct

2. Använda gränssnitt

du kanske känner till användningen av gränssnitt från att arbeta genom go-genomgången eller från den officiella dokumentationen. Skönheten med att använda gränssnitt I Go är dock att du kan definiera en uppsättning metoder som en typ (ofta struct) måste definiera för att betraktas som en implementering av det gränssnittet.

när en viss typ implementerar alla metoder för det gränssnittet, vet Go-kompilatorn automatiskt att det är tillåtet att användas som den typen.

3. Loggning

loggning är svårt!

om du redan har arbetat som Applikationsproduktionsstöd relativ funktion. Du kommer att uppskatta utvecklaren som loggar informationen om hur programmet körs, när och hur det här programmet misslyckades, vilken fil, vilken funktion. (Ett Plus+)

jag använder Uber Zap libs. Och jag wrapper också till en hjälpare som kan användas i olika projekt olika nivåer. För mig föredrar jag att returnera lägre spakfel till huvudimplementeringen.

4. Unit Test

skriva enhetstester kan säkerställa vår kod fungerar som förväntat, är mycket mindre ”dyra” än om en bugg eller regression gör det hela vägen till en release.

om du fortfarande kommer ihåg gränssnittsimplementeringen #1, och den andra fördelen med gränssnittsimplementeringen är att hjälpa dig att enkelt skriva testbar kod.

Enhetstesttäckning är ett intresserat ämne, Jag brukar galen nog att spåra 100% täckning, men jag lär mig mina lektioner, det viktigaste om enhetstestet är:

hur säker du är på din kod och se till att CI/CD automation fånga så mycket som möjligt kodningsnivå regression buggar.

slutresultat

Stödfas

denna pipeline är bara byggd under helgen, låt oss säga, 10 timmar total design, utveckling/kodning. På grund av enhetens testtäckning, loggning och lokalt integrationstest. Jag är ganska säker på att den är produktionsklar, men…

Förbättringsfas

det enda som saknas här är säkerhetsimplementering, miljönivå och kodnivå. detta är den viktigaste delen om du vill skicka till produktion.

denna artikel fokuserar mest på Design och byggnad. Nästa inlägg kommer att fokusera mer på stöd och förbättring. 🙂

del 2: