I softwareimplementering er et miljø eller et tier et computersystem, hvor et computerprogram eller en softwarekomponent er installeret og eksekveret. I et enkelt tilfælde kan en sådan implementering og øjeblikkelig udførelse af programmet på samme maskine udføres i et enkelt miljø , men i industriel udvikling bruges der en adskillelse mellem udviklingsmiljøet (udviklermiljøet), hvor de indledende ændringer er lavet og produktionmiljø (som slutbrugere bruger); ofte med mellemstadier (stadier) i midten. Denne strukturerede udgivelsesstyringsproces kan have implementeringsfaser (udrulning, 'implementering', 'udrulning'), test (test) og rollback (rulning) i tilfælde af problemer.
Miljøer kan variere meget i størrelse: Et udviklingsmiljø er normalt en individuel udviklers arbejdsstation , mens et produktionsmiljø kan være et netværk af mange geografisk spredte maskiner i tilfælde af datacentre eller virtuelle maskiner i tilfælde af cloud-løsninger . Kode, data og konfiguration kan implementeres parallelt, og der er ingen grund til at linke til det relevante niveau - for eksempel kan præproduktionskode oprette forbindelse til produktionsdatabasen .
Implementeringsarkitekturer varierer meget, men generelt starter niveauer med udvikling (DEV) og slutter med produktion (PROD). En almindelig 4-lags arkitektur er en kaskade af udviklings-, test-, model-, produktions- (DEV, TEST, MODL, PROD) niveauer med softwareimplementering på hvert niveau efter tur. Et andet almindeligt miljø er kvalitetskontrol (QC), til accepttest ; sandkasse eller forsøgsmiljø (EXP), til forsøg, der ikke er beregnet til at blive overført til produktion; og Disaster Recovery ('disaster recovery'), for at muliggøre øjeblikkelig tilbagerulning i tilfælde af et produktionsproblem. En anden almindelig arkitektur er udvikling, test, accept og produktion (DTAP).
En sådan opdeling er særligt velegnet til serverprogrammer, når servere opererer i fjerntliggende datacentre; for kode, der kører på brugerens slutenheder, såsom applikationer (apps) eller klienter, omtales det sidste niveau som brugermiljøet (USER) eller lokalt miljø (LOCAL).
De nøjagtige definitioner og grænser mellem miljøer varierer - test kan betragtes som en del af dev, accept kan betragtes som en del af testen, en del af scenen eller selvstændig, og så videre. De vigtigste niveauer behandles i en bestemt rækkefølge, hvor nye udgivelser bliver implementeret ( rullet ud eller skubbet ) på hver. De eksperimentelle niveauer og gendannelsesniveauer, hvis de er til stede, er eksterne i forhold til denne proces - eksperimentelle udgivelser er endepunkter, mens gendannelse normalt er gamle eller duplikerede versioner af produktion, der er implementeret efter produktion. I tilfælde af problemer kan du i sidstnævnte tilfælde rulle tilbage til den gamle udgivelse, og de fleste ruller bare den gamle ud på samme måde som den nye. Det sidste trin, implementering til produktion ("pushing to prod") er det mest følsomme, da eventuelle problemer her direkte påvirker brugeren. Af denne grund styres det ofte anderledes, men i det mindste overvåges mere nøje, og i nogle tilfælde er der en tilbagerulning eller simpel overgangsfase. Det er bedst at undgå et navn som Quality Assurance (QA); QA betyder ikke softwaretest. Test er vigtigt, men det er anderledes end QA.
Nogle gange udføres en implementering uden for den normale proces, hovedsageligt for at give presserende eller små ændringer uden behov for en fuld frigivelse. Det kan være en enkelt patch , en stor service pack eller et lille hotfix .
Miljøer kan være af meget forskellige størrelser: Udviklingen foregår normalt på individuelle udviklermaskiner (selvom det kan være tusindvis af udviklere), mens produktionen kan være tusindvis af geografisk spredte maskiner; test og kvalitetskontrol kan være små eller store afhængigt af de tilvejebragte ressourcer, og iscenesættelse kan variere fra en enkelt maskine (som en kanariefugl) til nøjagtige produktionsduplikater.
Lokal
Udviklingscomputer
Udvikling/Trunk
Udviklingsserver, der fungerer som en sandkasse , hvor udvikleren kan udføre enhedstest
integration
Rammer til opbygning af CI eller til test af bivirkninger af en udvikler
Test/Test/QC/Intern Accept
Det miljø, hvor grænsefladen er testet. QA-teamet kontrollerer, at den nye kode ikke vil have en indvirkning på den eksisterende funktionalitet af systemet efter implementering af den nye kode til testmiljøet.
Iscenesættelse/Stage/Model/Pre-produktion/Ekstern klientaccept/Demo
Spejl af produktionsmiljøet
Produktion/Live
Slutbruger/klientservere
Udviklermiljøet (dev) er det miljø, hvor software udvikles, ofte kun udviklerens computer. Dette adskiller sig fra det endelige målmiljø på nogle måder - målet er muligvis ikke en stationær computer (det kan være en smartphone, et indlejret system, et selvkørende datacenterkøretøj osv.), og selvom det er en stationær computer , vil udviklermiljøet omfatte udviklerværktøjer, f.eks. compiler, IDE, forskellige eller yderligere versioner af biblioteker og understøttende software osv., der ikke er til stede i brugermiljøet.
I forbindelse med revisionsstyring, især når der er flere udviklere involveret, er der mere subtile forskelle: udvikleren har en arbejdskopi af kildekoden på deres maskine, og der foretages ændringer i depotet ved at blive forpligtet enten i "trunken" eller i branchen, afhængigt af udviklingsmetoden. Et miljø på en separat arbejdsstation, hvor ændringer er udarbejdet og testet, kan kaldes et lokalt miljø eller en sandkasse . Opbygning af en kopi af kildekoden til depotet i et rent miljø er et separat integrationstrin (integration af forskellige ændringer), og dette miljø kan kaldes et integrationsmiljø eller et udviklermiljø ; i kontinuerlig integration gøres dette ofte, så ofte som ved hver revision. Konceptet med kildekodeniveauet, der lyder som at "forpligte (forpligte) ændringer i depotet" med den efterfølgende samling af "stammen" eller grenen, svarer til overgangen fra lokalt (individuelt udviklermiljø) til integration (ren samling) ; en dårlig udgivelse på dette tidspunkt betyder, at ændringen brød bygningen, og tilbageføring af udgivelsen betyder enten at vende tilbage til alle de ændringer, der er foretaget, eller kun vende tilbage til den brudte ændring, hvis det er muligt.
Formålet med et testmiljø er at give testere mulighed for at køre ny og ændret kode gennem enten automatiske kontroller eller manuelle metoder. Efter at en udvikler har videregivet ny kode og konfigurationer gennem enhedstest i udviklingsmiljøet, migreres koden til et eller flere testmiljøer. Efter at en test mislykkes, kan testrammeværket fjerne den fejlagtige kode fra testrammerne, kontakte den ansvarlige udvikler og give detaljerede testlogfiler og resultater. Hvis alle test består, kan testmiljøet eller den kontinuerlige integrationsramme , der styrer testene, automatisk migrere koden til det næste implementeringsmiljø.
Forskellige typer test involverer forskellige typer testmiljøer, hvoraf nogle eller alle kan virtualiseres for at give hurtig parallel test. For eksempel kan automatiserede brugergrænsefladetest køre på flere virtuelle operativsystemer og skærme (virkelige eller virtuelle). Benchmark-tests kan kræve en normaliseret baseline-hardwarekonfiguration, så benchmark-resultater kan sammenlignes over tid. Tilgængeligheds- eller modstandsdygtighedstestning kan være baseret på fejlsimulatorer i virtuel hardware og virtuelle netværk.
Tests kan være sekventielle (den ene efter den anden) eller parallelle (for nogle eller alle på én gang), afhængigt af kompleksiteten af testmiljøet. Et vigtigt mål med agil og anden højtydende softwareudviklingspraksis er at reducere tiden fra udvikling eller levering af software til levering til produktion. Stærkt automatiserede og paralleliserede testmiljøer yder et vigtigt bidrag til hurtig softwareudvikling.
Stage eller iscenesættelsesmiljø (staging) er et testmiljø, der er præcis som et produktionsmiljø. Det har til formål at spejle det faktiske produktionsmiljø så tæt som muligt og kan forbindes med andre produktionstjenester og data såsom databaser. For eksempel vil serverne køre på fjernmaskiner i stedet for lokalt (som på en udviklers arbejdsstation under udvikling eller på en enkelt testmaskine under test) for at teste netværkets indvirkning på systemet.
Hovedformålet med et iscenesættelsesmiljø er at teste alle opsætnings-/konfigurations-/flytningsscripts og -procedurer, før de anvendes til produktionsmiljøet. Dette sikrer, at alle større og mindre opdateringer af produktionsmiljøet vil blive gennemført med høj kvalitet, fejlfrit og på kortest mulig tid.
En anden vigtig anvendelse af iscenesættelsesmiljøet er præstationstest, især belastningstest, da dette ofte er miljøfølsomt.
Staging-miljøet bruges også af nogle organisationer til at forhåndsvise nye funktioner til kundevalg eller til at validere integrationer med kørende versioner af eksterne afhængigheder.
Produktionsmiljøet er også kendt som live (især når det anvendes på servere), fordi det er miljøet, som brugerne interagerer direkte med.
Udrulning til produktion er det mest følsomme trin; dette kan gøres ved at implementere den nye kode direkte (overskrive den gamle kode, så der kun er én kopi til stede ad gangen), eller ved at implementere en konfigurationsændring. Dette kan antage forskellige former: parallel implementering af en ny version af koden og skift til den med en konfigurationsændring; at implementere en ny version af koden ved siden af den gamle med det tilsvarende "nye funktionsflag", og derefter skifte til den nye version med en konfigurationsændring, der vil skifte dette "flag"; eller implementering af separate servere (den ene kører den gamle kode, den anden den nye) med trafik omdirigeret fra den gamle til den nye, med en konfigurationsændring på trafikdirigeringsniveauet. Alt dette kan til gengæld anvendes samtidigt eller selektivt og på forskellige stadier.
Implementering af en ny version kræver normalt en genstart, medmindre hot-switching er mulig , og kræver derfor enten tjenesteafbrydelse (normalt tilpasset software, når applikationer skal genindlæses) eller duplikering - gradvis genstart af forekomster "bag" load balanceren eller tidlig start nye servere, efterfulgt af en simpel omdirigering af trafik til nye servere.
Når du udruller en ny udgivelse til produktion, i stedet for straks at implementere den til alle forekomster eller brugere, kan du først udrulle den til én forekomst eller til nogle brugere og derefter enten implementere den til alle forekomster eller i faser for hurtigt at fange problemer, der opstår . Det ligner iscenesættelse, bortset fra at det er lavet i produktionen og kaldes en kanarie-udgivelse svarende til kulminedrift . Dette tilføjer kompleksitet, hvis flere udgivelser lanceres på samme tid, og derfor laves de normalt hurtigt for at undgå kompatibilitetsproblemer.
Udvikling, iscenesættelse og produktion er kendte og dokumenterede miljøvariabler i ASP.NET Core . Afhængigt af den angivne variabel udføres forskellig kode og forskellig indholdsgengivelse, forskellige sikkerheds- og fejlfindingsindstillinger anvendes.