Skrive programkode forut for de fleste skyløsninger-løsninger som de fleste applikasjonsprogrammerere skrive spesielt for disse dager.

for å håndtere denne dissonansen, har 12-Faktor app metodikk dukket opp. De 12 faktorene er en tilnærming som hjelper programmerere å skrive moderne apper på en deklarativ måte, ved hjelp av klare kontrakter distribuert via sky.

i denne artikkelen vil jeg introdusere 12-faktor app metodikk og tilby et høyt nivå sammendrag av sine prinsipper.

Hva er 12-Faktor app metodikk?

i 2012, programmerere på Heroku debuterte 12-Faktor app metodikk. Disse programmerere har utviklet og distribuert hundrevis av apps skrev denne metoden, tegning på deres erfaring med Å se SaaS apps «i naturen».

denne gruppen anser metodikken en triangulering av:

• Ideelle praksis for å støtte app utvikling
• dynamikken som oppstår som en app vokser organisk
• forholdet og samarbeidet mellom kodebase utviklere

deres mål er todelt:for å unngå programvareerosjonskostnader for å øke bevisstheten om systemiske problemer de har observert i moderne apputvikling, peker gruppen på to inspirasjonskilder, Mønstre Av Bedriftsapplikasjonsarkitektur og Refactoring, begge av profesjonell utvikler Martin Fowler.

Og nå vil jeg introdusere hver av de 12 faktorene.

Prinsipp I. Kodebase

«En kodebase spores i revisjonskontroll, mange distribuerer»

kodebasen din skal ha et logisk versjonskontrollsystem som er lett å forstå.

Hver distribusjon skal ha sitt eget kodelagre som kan distribueres til flere miljøer. Unngå boliger flere programmer i samme depot. Dette gjør versjonskontroll nesten umulig å forstå og versjoner vil bli sammenflettet, noe som resulterer i ikke-verdiskapende arbeid.

Prinsipp II. Avhengigheter

«Eksplisitt erklære og isolere avhengigheter»

dette prinsippet hevder at du aldri bør stole på den implisitte eksistensen av systemomfattende pakker. I stedet»

• Kontroller at app – spesifikke biblioteker er tilgjengelige
• Bekreft beskytningen til OPERATIVSYSTEMET
• Kontroller at nødvendige systembiblioteker, som curl eller ImageMagick, er tilgjengelige. (Det er ingen garanti for at disse finnes på alle systemer der appen kan kjøre i fremtiden.)

Totalt sett må en 12-faktor app være selv-inneholdende. Programmet skal isoleres tilstrekkelig for å unngå interaksjoner med motstridende biblioteker som er installert på vertsmaskinen.

La oss se på et eksempel. I Python kan du oppnå deklarasjon og isolasjon ved å bruke henholdsvis Pip og Virtualenv. For å tilfredsstille dette prinsippet må du alltid bruke både erklæring om avhengighet og isolasjon. Behandle avhengigheter i programmet, ikke fra en ekstern kilde. Avhengigheter bør ligge i et depot i appen

Prinsipp III. Config

«Lagre config i miljøet»

et program og dets konfigurasjon skal være helt uavhengig. Videre bør lagring av configs konstant i kode unngås helt.

konfigurasjonene dine bør ha en egen fil og bør ikke ligge i kodelageret. En egen config fil gjør det enkelt å oppdatere config verdier uten å berøre selve kodebasen, eliminerer behovet for re-distribusjon av programmene når du endrer visse config verdier.

når konfigurasjoner er i miljøet, ikke app, som variabler, kan du enkelt flytte den til et annet miljø uten å berøre kildekoden. Tolv-faktor apps lagre configs som variabler slik at de er» usannsynlig å bli sjekket inn i depotet » ved et uhell. En annen bonus: da dine configs er uavhengig av språk og OS.

Prinsipp IV. Backing services

«Behandle backing services som vedlagte ressurser»

i en 12-faktor app må alle tjenester som ikke støtter kjerneappen, nås som en tjeneste. Disse ikke-kjerneviktige tjenestene kan omfatte:

• Databaser
• Ekstern lagring
• Meldingskøer
• Etc.

Disse kan behandles som en ressurs. Disse bør nås som en tjeneste VIA HTTP eller lignende forespørsel, deretter spesifisert i config. På denne måten kan tjenestens kilde endres uten å påvirke appens kjernekode.en app som for eksempel bruker et message queuing-system, er best hvis den enkelt kan bytte Fra RabbitMQ Til ZeroMQ til ActiveMQ ved bare å endre konfigurasjonsinformasjon.

Prinsipp V. Bygg, slipp, kjør

«Strengt separate bygg og kjør stadier»

en 12-faktor app er streng om å skille de tre stadiene av å bygge, slippe og kjøre.Start byggeprosessen ved å lagre appen i kildekontroll, og bygg deretter ut avhengighetene. Å skille config-informasjonen betyr at du kan kombinere den med bygningen for utgivelsesfasen-og så er den klar for løpetrinnet. Det er også viktig at hver utgivelse har en unik ID.

Prinsipp VI. Prosesser

«Kjør appen som en eller flere statsløse prosesser»

Lagre alle data som kreves for å fortsette i en stateful backing service, for eksempel databaser. Tanken er at prosessen er statsløs og deler absolutt ingenting.

mens mange utviklere er vant til «klissete økter», lagring av informasjon i økten forventer neste forespørsel vil være fra den samme tjenesten motsier denne metoden.

PRINSIPP VII. Portbindingsprinsipp

«Eksporter tjenester via portbinding»

12-faktorapper må alltid være uavhengige av flere applikasjoner. Hver funksjon bør være sin egen prosess—i full isolasjon.

i et tradisjonelt miljø antar vi at ulike prosesser håndterer ulike funksjoner. Som sådan er det lett å anta at disse funksjonene er tilgjengelige via en webprotokoll, FOR EKSEMPEL HTTP, noe som gjør det sannsynlig at apper vil kjøre bak webservere, Som Apache eller Tomcat. Men dette er i strid med 12-faktor metodikken.

legg I Stedet til et webserverbibliotek eller lignende til kjerneappen. Dette betyr at appen kan vente forespørsler på en definert port, ENTEN DET ER HTTP eller en annen protokoll.

Prinsipp VIII. Samtidighet

«Skaler ut via prosessmodellen»

en ekte 12-faktor app er designet for skalering. Bygg programmene dine slik at skalering i skyen er sømløs. Når du utvikler appen til å være samtidig, kan du enkelt spinne nye forekomster til skyen.

for å legge til mer kapasitet (starte flere prosesser på flere maskiner), bør appen din kunne legge til flere forekomster i stedet for mer minne eller CPU på den lokale maskinen.

Prinsipp IX. Disponibel

«Maksimere robusthet med rask oppstart og grasiøs nedleggelse»

begrepet disponibel prosesser betyr at et program kan dø når som helst, men det vil ikke påvirke brukeren—appen kan erstattes av andre apper, eller den kan starte helt opp igjen. Bygge disponibilitet i app sikrer at app avsluttes grasiøst: det bør rydde opp alle utnyttede ressurser og stenge jevnt.

når designet på denne måten, app kommer opp igjen raskt. På samme måte, når prosesser avsluttes, bør de fullføre sin nåværende forespørsel, nekte innkommende forespørsel og avslutte.

Prinsipp X. Dev / prod paritet

«Hold utvikling, iscenesettelse og produksjon så lik som mulig»

Applikasjoner som distribueres til utvikling og produksjon, bør ha paritet. I hovedsak bør det bare være den minste forskjellen mellom begge distribusjoner.

en stor forskjell kan føre til utilsiktede kompatibilitetsproblemer mellom dev og produksjonskode. Når du bygger en 12-faktor app, må støttetjenester mellom dev og prod være de samme; en forskjell her kan forårsake betydelige problemer nedover linjen.

Prinsipp XI. Logs

«Behandle logger som hendelsesstrømmer»

I Motsetning til monolitiske og tradisjonelle apper som lagrer logginformasjon i en fil, opprettholder dette prinsippet at du skal streame logger til et valgt sted—ikke bare dumpe dem i en loggfil.loggene ligger vanligvis Ikke på samme sted i skybaserte miljøer etter hver brenning. Etter hvert som nye prosesser starter eller appen din krasjer, blir loggene distribuert over flere skymaskiner; de vil ikke sitte på en enkelt maskin eller vert.

Løs dette problemet ved å navngi et felles sted for loggene å strømme. I noen tilfeller kan du bare omdirigere Stdout til en fil. Mer sannsynlig vil du imidlertid distribuere en loggrouter som Fluentd og lagre loggene Til Hadoop eller en bestemt tjeneste, som Splunk.

Prinsipp XII. Admin prosesser

«Kjør admin / administrasjonsoppgaver som engangsprosesser»

det endelige 12-faktor app-prinsippet foreslår å skille administrative oppgaver fra resten av søknaden din. Disse oppgavene kan omfatte overføring av en database eller inspeksjon av poster.

selv om administrasjonsprosessene er separate, må du fortsette å kjøre dem i samme miljø og mot basiskoden og config av selve appen. Shipping admin oppgaver kode sammen med programmet hindrer drift.

Relatert lesing

• BMC DevOps Blog
• Agile vs Waterfall SDLCs: Hva Er Forskjellen?
• Distribusjon Rørledninger (CI/CD) I Software Engineering
• Hva Er Ekstrem Programmering (XP)?
• Hvordan & Hvorfor Bli En Programvarefabrikk
• Topp Konferanser For Programmering & Programvareutvikling