Livscyklussen for et FIFA-problem – del 4

7. december 2020

Denne serie beskriver de faser, som et problem i FIFA 21 typisk gennemgår, før det kan løses.

Hej FIFA-fans.

Jeg hedder Joel Doonan, og jeg er Lead Producer på Player First Operations-holdet, der hører under FIFA Live-holdet.

Dette er fjerde og sidste del af en Sidelinjen-artikelserie, der har fokus på problemers typiske livscyklus i FIFA 21.

I denne serie beskriver jeg de forskellige trin forbundet med at identificere, undersøge og løse et problem i FIFA 21.

Denne serie i fire dele dækker:

• Del 1 – Identificering
• Del 2 – Undersøgelse
• Del 3 – Løsning
• Del 4 – Udgivelse (denne artikel)

I denne artikel kigger vi nærmere på udgivelsesfasen, hvor vi rent faktisk overfører de(n) ændring(er), som vi har foretaget for at løse et problem, til livemiljøet og gør det hele tilgængeligt for vores spillere.

Før vi går videre, vil jeg lige gøre opmærksom på, at jeg kommer til at bruge forskellige tekniske begreber undervejs, som folk, der ikke er fortrolige med spiludvikling, muligvis ikke kender. Derfor har jeg forsynet artiklen med en række fodnoter, der forklarer disse begreber. Lad os begynde med at kigge nærmere på, hvordan løsninger på problemer udgives.

Forberedelse af en udgivelse

I den foregående artikel beskrev vi, hvordan sidste trin i livscyklussens løsningsfase er at overføre ændringen, der blev foretaget for at løse et problem, til spillets primære build(s)². Når ændringen er tilgængelig i det primære build, kan den inkluderes i en udgivelse.

Der findes mange forskellige slags udgivelser – alt afhængigt af typen af kode, der er blevet ændret.

Hvis ændringen udelukkende er implementeret i serverkoden³, er udgivelsen en serverudgivelse, der ikke kræver, at spillerne downloader en opdatering på deres konsol, pc eller – i tilfælde af FUT Companion-appen – mobilenhed. Det er vigtigt at pointere, at der er grænser for, hvad der kan ændres og løses direkte på serveren, og at de ændringer, der inkluderes i disse udgivelser ofte ikke bemærkes af spillerne eller påvirker deres oplevelse, men snarere påvirker, hvordan tingene fungerer bag kulisserne eller på system- og infrastrukturniveau. Gameplayændringer implementeres f.eks. ikke gennem serverudgivelser, idet de kræver en regulær spilopdatering.

Hvis ændringen er foretaget i klientkoden⁴, regnes udgivelsen for at være en spiludgivelse – almindeligvis kaldet en spilopdatering. Det er disse opdateringer, som du – og alle andre spillere – er nødt til at downloade, idet de opdaterer eller erstatter kode, der oprindeligt var på den disk, som du installerede spillet fra, eller i den udgave, som du downloadede.

Nogle gange kræver det ændringer på flere områder – altså af både server- og klientdelen – at løse et problem. I så fald skal alle de nødvendige udgivelser være tilgængelige i livemiljøet, hvis ændringen skal have effekt og fungere korrekt.

Selvom disse forskellige slags udgivelser er forskellige på det tekniske niveau, er den overordnede fremgangsmåde ens.

Først skal vi beslutte, hvilken ændringsliste vi skal tage udgangspunkt i, når vi skal oprette udgivelsen. Det vil resultere i, at vi ender med en version af klient- eller serverkoden, der indeholder alle de ændringer, der er blevet implementeret siden den seneste ændringsliste, der blev brugt til kodeudgivelse.

Derefter opretter vi en udgivelse ud fra den pågældende ændringsliste, der enten udgives på serverne eller udgives som spilopdatering.

Tredje trin er at gøre udgivelsen tilgængelig til test. For serverudgivelser indebærer dette at udgive udgivelsen i et testmiljø⁵. For klientudgivelser indebærer dette at udgive opdateringen til testkonsoller⁵.

Nu, hvor vi står med en klargjort udgivelse, er det tid til at gå videre til at teste og validere denne.

Test og validering af en udgivelse

Nu, hvor udgivelsen er blevet oprettet, går vores QV-testere i gang med at teste udgivelsen med udgangspunkt i deres testplan. Omfanget og kompleksiteten af ændringerne i udgivelsen afgør, hvor lang tid testerne bruger på selve testen, men det ligger generelt inden for et spænd fra et par dage til et par uger.

QV-testerne fokuserer på to slags tests. Generelle tests sikrer, at spillet som helhed stadig fungerer som ventet i den nye version, mens fokuserede tests har til formål at tjekke, at de specifikke ændringer i udgivelsen fungerer som tilsigtet.

Mens QV-testerne kører deres tests, gennemgår producerne⁹ ofte udgivelsen samtidig, hvor de tjekker ændringerne inden for det spilområde, som de har ansvaret for, så de sikrer at både funktionaliteten for og kvaliteten af de nye ændringer er i orden.

Der er også tekniske tests, der muligvis skal afvikles i denne fase, f.eks. belastningstests¹⁰ af de serverudgivelser, hvor det er nødvendigt.

Formålet med alle disse bestræbelser er at styrke vores tro på, at de ændringer, som vi står over for at udgive i livemiljøet, både giver de ønskede resultater og samtidig ikke medfører utilsigtede ændringer, herunder afledte problemer¹¹.

Når vi har kørt alle vores tests, og de relevante interessenter har givet grønt lys, erklæres udgivelsen for "endelig" eller "klar", hvorefter dens udgivelse i livemiljøet kan planlægges.

Planlægning af en udgivelse – spilopdatering

Planlægning af udgivelsen af en spilopdatering handler ikke kun om, hvornår vi gerne vil gøre opdateringen tilgængelig for spillerne. En del af processen indebærer at få udgivelsen godkendt af platformens ejere, f.eks. Sony, Microsoft eller Nintendo eller – i tilfælde af udgivelse på pc og Origin – en intern EA-afdeling.

Når vi har erklæret spilopdateringen for "endelig", sendes den til disse virksomheder, hvorefter de kører deres egne tests og valideringsprotokoller, før de giver deres tilladelse, hvorefter vi kan planlægge et konkret udgivelsestidspunkt. Alle virksomheder har deres egne tidslinjer og krav for godkendelse, hvilket kan resultere i, at udgivelsen af spilopdateringen kan være klar på forskellige tidspunkter på forskellige platforme.

Når vi har fået de enkelte samarbejdspartneres godkendelse, kan vi planlægge udgivelsen. Når vi står over for at skulle vælge et udgivelsestidspunkt, forsøger vi generelt at følge et par retningslinjer.

Først og fremmest forsøger vi at udgive opdateringen på et tidspunkt, hvor udgivelsen påvirker så få spillere som muligt. Det vil typisk være, når de fleste af vores spillere sover eller lige er ved at vågne. Dernæst forsøger vi at undgå at udgive opdateringer sidst på ugen, eftersom det er sværere at løse eventuelle problemer, der måtte opstå, hen over weekenden, hvor der statistisk set er flere, der spiller. Endelig forsøger vi også at undgå at udgive opdateringer i situationer, hvor udgivelsen kunne forstyrre vigtige spilbegivenheder eller -turneringer.

Når vi internt har tilrettelagt en udgivelsesplan, låser vi den sammen med de relevante virksomheder, hvorefter de fleste personer, der har været involveret i arbejdet på opdateringen, påbegynder arbejdet på en ny opdatering, selvom der stadig mangler at blive gjort et par ting med den forestående opdatering, hvilket vi kommer nærmere ind på i afsnittet "Fuldførelse af udgivelsen" nedenfor.

Planlægning af en udgivelse – serverudgivelse

Det er normalt mere ligetil at udgive en serverudgivelse end en spilopdatering, eftersom der ikke er behov for at få udgivelsen gennemset og godkendt af virksomhederne nævnt i spilopdateringsafsnittet ovenfor.

Vi gennemgår dog stadig de samme beslutningsprocesser som ved planlægningen af en spilopdatering – især hvis serverudgivelsen kræver, at én eller flere tjenester eller funktioner deaktiveres i forbindelse med udgivelsen.

Ligesom med spilopdateringer går det meste af holdet, der har været involveret i udgivelsen, i gang med at arbejde på den næste udgivelse, mens de sidste par opgaver relateret til den forestående udgivelse udføres (mere om dette nedenfor).

Fuldførelse af udgivelsen

Nu, hvor udgivelsen er blevet planlagt, er der muligvis et par afsluttende ting, der skal klargøres før den endelige udgivelse.

Ud over at forberede alle interne grupper på udgivelsen er et af vigtigste trin i denne proces at nedfælde de udgivelsesnoter, der skal sendes ud til spillerne i forbindelse med udgivelsen, og som beskriver ændringerne. Uanset om vi udarbejder opdateringsnoter til en spilopdatering, udgivelsesnoter til en serverudgivelse, en vedligeholdelsesnotifikation i forbindelse med et udfald eller en ny Sidelinjen-artikel, der går i dybden med nogle af ændringerne i en udgivelse, forsøger vi i så høj grad som muligt at afmystificere, hvad der foregår bag kulisserne, så I, spillerne, ved, hvad der sker.

Derefter venter vi på, at udgivelsen udgives og bliver tilgængelig i livemiljøet. Når det sker, går vores Live Quality Verification Analysts (Live QV-testere), der arbejder og udfører tests i livemiljøet, i gang med at gennemgå og teste de forskellige ændringer for at validere, at de problemer, som vi har forsøgt at løse, rent faktisk er blevet løst.

Hvis Live QV-testerne konstaterer, at problemet ikke er blevet løst, sendes problemet hele vejen tilbage til undersøgelsesfasen, hvorefter hele processen starter forfra. Hvis problemet er blevet løst, betragter vi sagen som lukket.

Rejsen er slut. Problemet har fuldendt sin rejse gennem alle faserne i livscyklussen.

Det er vigtigt at bemærke, at hvert eneste problem er unikt. Nogle af dem kan løses hurtigt, mens rejsen gennem de forskellige faser, som vi har dækket i denne artikelserie, helt naturligt tager længere tid for andre problemer.

Der er også unikke tilfælde, hvor det ikke er nødvendigt at gennemgå alle faser, som vi har gennemgået, men det ville kræve et helt essay at gennemgå disse undtagelser, og jeg forestiller mig, at det ville være TL;DR for de fleste!

Jeg håber, at denne serie har givet alle jer, der har læst med, større forståelse for, hvor stort et arbejde FIFA Live-teamet ligger i at løse problemer og rette fejl, og hvad det rent faktisk indebærer. Tak, fordi du læste med!

Joel Doonan og FIFA-holdet.

Fodnoter

¹: Overførsel af en ændring betyder, at du implementerer ændringen i et build. I denne artikel betyder det først og fremmest, at ændringen overføres til klientkodens eller serverkodens primære build. Når en ændring er blevet overført, betyder det, at den findes i de pågældende builds og potentielt kan inkluderes i en fremtidig udgivelse.

²: De(t) primære build(s) er stedet, hvor de enkelte udvikleres og udviklergruppers kodnings- og udviklingsarbejde ender, når det er blevet overført, og i sidste ende, hvor de endelige versioner af spillets klient- og serverkode hentes fra. Hvis noget er en del af det primære build, når der udgives en opdatering, betyder det som regel, at det er med i den pågældende udgivelse.

³: Når noget er på serversiden, betyder det, at det ikke er på disken, men snarere er kode eller indhold, der kommer fra en server og leveres via din onlineforbindelse til den pågældende server. Der er mange forskellige slags serveroplysninger, og inden for FIFA 21 er der mange forskellige serversystemer, som du kommunikerer med, afhængigt af hvilken del af spillet du spiller.

⁴: Klienten er helt grundlæggende det indhold, der er på disken, eller – hvis du har en digital udgave af spillet – det indhold, som du downloader til din konsol eller pc, før du kan spille spillet.

⁵: Livemiljøet, der også kaldes det spilbare miljø eller produktionsmiljøet, er det sted, hvor vores spillere kan spille den udgivne version af spillet. Vi har også en række miljøer, som typisk kun er tilgængelige internt blandt udviklerne, såsom vores testmiljøer, hvor nye versioner af spillet testes, inden de udgives.

⁶: Ændringslisten er grundlæggende en version af koden. Hver gang nogen overfører en ny ændring til enten klient- eller serverkoden, oprettes der en ny ændringsliste. Denne nye ændringsliste indeholder den nye ændring samt alt tidligere kode, der var på plads før ændringen.

⁷: En testkonsol er en særlige udgave af en spilkonsol, der bruges under udviklingen af et spil. Disse konsoller gør det muligt at bruge særligt værktøj under testarbejdet, der bl.a. kan gøre det hurtigere at teste noget eller tillade indsamling af oplysninger, der ikke er tilgængelige i den udgivne version af spillet eller konsollen. De kan også køre de præudgivelses- og testversioner af spillet, der bruges under udviklingen.

⁸: En Release Quality Verification Analyst (QV-tester) er et medlem af vores kvalitetstesterhold, der specifikt har til opgave at teste de forskellige klient- og serverudgivelser, før de udgives i livemiljøet. QV-testerens rolle er at validere, at ændringerne i udgivelsen fungerer som tilsigtet, og at udgivelsen ikke har skabt nye problemer.

⁹: En producer er grundlæggende en person, der har ansvaret for et bestemt område eller aspekt af spillet. Produceren står typisk for at udstikke den overordnede retning og træffe beslutninger om prioriteringen. En liveproducer udfører de samme opgaver som en almindelig producer, men har fokus på livespillet – altså hvordan spillet fungerer lige nu – frem for at arbejde på en kommende spiludgivelse.

¹⁰: En belastningstest er en test, hvor servermiljøets ydeevne og stabilitet måles ved at simulere mange menneskers handlinger på én gang, som om de spillede spillet, udførte en masse handlinger i spillet og foretog forskellige opkald til serverne.

¹¹: Et afledt problem er et problem, der skyldes en ændring, og er næsten altid utilsigtet. Et afledt problem kan opstå i situationer, hvor en ændring på ét område påvirker funktionaliteten på et andet på grund af nogle afhængigheder eller delt kode/teknologi.

¹²: En Live Quality Verification Analyst (Live QV-tester) er et medlem af vores kvalitetstesterhold – mere formelt kaldet vores Live Monitoring Testing-hold. De er konstant til stede i spillet. Nogle gange spiller de ligesom enhver anden spiller, men med den afgørende forskel, at de konstant kører meget fokuserede tests for at validere og/eller forsøge at fremprovokere fejl og problemer i spillet. Deres primære opgave er at finde, spore og indsende rapporter om problemer i spillet. De validerer også alle udgivelser, der sendes til livemiljøet, for at bekræfte, at ændringerne i den pågældende udgivelse har den tilsigtede effekt.

Besøg Sidelinjen for flere dyk ned i FIFA-gameplayet med holdet.

Bemærk: Denne artikel beskriver i generelle vendinger, hvad udviklerholdene arbejder på. Vi forsøger konstant at forbedre FIFA-oplevelsen for alle, så artiklen bliver muligvis forældet i takt med, at vi justerer spillets dynamikker til alles bedste.

Følg med i alt, hvad der handler om FIFA, ved at synes godt om os på Facebook, følge os på Twitter og Instagram, følge vores udvikleres Twitter-kanal, @EAFIFADirect, på EA Sports FIFA Tracker samt deltage på de officielle FIFA-fora. Tilmeld dig for at få e-mails om EA SPORTS FIFA og EA-produkter, nyheder, begivenheder og kampagner.