Utgivelsesadministrasjon, som navnet antyder, er prosessen med å administrere, planlegge, planlegge og kontrollere en programvare som bygges gjennom forskjellige stadier og miljøer; inkludert testing og distribusjon av programvareutgivelser (Humble & Farley, 2011).

Det er et ganske stort tema i seg selv og kan bare perfeksjoneres over tid ved å prøve forskjellige iterasjoner med utviklingsteamene og matche forretningsbehov eller funksjonsutgivelser. Vi vil prøve å dekke bransjepraksisene for metadataadministrasjon, CI-bygging og sandkasseadministrasjon for å administrere en organisasjon slipp toget .

Men hva er et frigjøringstog?

Et frigjøringstog er en inkrementell og forutsigbar teknikk for levering av funksjoner. Det krever at utvikleren setter opp en formell prosess for å ta eventuelle endringer som er gjort i utviklingsmiljøet og distribuere dem til produksjon.

Et frigjøringstog kan stort sett deles inn i tre segmenter:

• Metadataadministrasjon
• Kontinuerlig integrasjonsbygging
• Sandkasseadministrasjon

Metadataadministrasjon

Metadata er data som gir informasjon om andre data. Salesforce tilbyr en rik og kraftig metadatamodell via sin Metadata API . Søknadens metadata beskriver og omfatter et sett med metoder som gir programmatisk tilgang til kildekoden og konfigurasjonen til organisasjonen din.

De Metadata API er den beste måten å administrere tilpasningene i Salesforce på. Den støtter create, read, update, og delete metoder. Du kan bruke Endre sett, Force.com IDE og Ant Migration Tool for å migrere metadata fra en organisasjon til en annen, siden de alle gir migrasjoner via API.

Hvert verktøy har sine egne fordeler, og det er flere ting du må vurdere når du velger en:

Tabell 1: Sammenligning av verktøy for migrering av metadata

Endre sett	Force.com IDE	Ant Migration Tool
Endringssett er måten å distribuere komponenter via standard Salesforce UI.	Force.com IDE (Eclipse) er primært ment for Apex-utvikling, men kan brukes til distribusjonsformål.	Ant Migration er et kraftig kommandolinjeverktøy, dedikert for migrering av endringer / metadata mellom miljøer.
Vanligvis brukt til et lite antall migrering av komponenter.	Utviklere bruker vanligvis IDE for å migrere endringer i test- eller iscenesettelsesmiljøet.	Ant Migration brukes til migrering av stor nyttelast og trenger avansert kunnskap om Salesforce Metadata API.
Forbindelsen mellom organisasjonene må opprettes manuelt, så den er ikke egnet for automatiserte distribusjoner.	Den kan brukes til å distribuere til hvilken som helst organisasjon, men trenger noen manuelle trinn, som er feil utsatt.	Automatiske distribusjoner kan planlegges veldig enkelt.
Beregnet for bruk av administratorer.	Rettet mot salgsutviklere, siden utvikling av koden er den primære bruken.	Rettet mot DevOps ingeniører.
Å legge til avhengigheter er veldig enkelt og brukervennlig.	Å legge til avhengigheter er noe enkelt, da det gir et pek og klikk UI.	Implementering mislykkes vanligvis på grunn av manglende avhengigheter.
Tillater ikke destruktive endringer.	Tillater destruktive endringssett, men prosessen er ganske kjedelig.	Tillater destruktive endringssett.

Metadata API er god til å tjene formålet sitt når man utvikler og overfører endringer på Force.com-plattformen. Men det er en liten fangst - ikke alle Salesforce-metadata støttes av Metadata API. Den offisielle dokumentasjonen gir en liste av komponenter som ikke støttes.

Hvis organisasjonen din gjør endringer som ikke støttes av Metadata API, må du sørge for å replikere disse endringene manuelt i destinasjonsorganisasjonen. Den beste måten å spore disse endringene på er et regneark. Hvis du må ty til denne tilnærmingen, er det alltid lurt for en enkelt person å gjøre disse endringene og spore dem.

Dette vil være en god generell liste over kolonner som man kan bruke til å spore disse endringene i et regneark:

• Komponentens navn
• Type komponent
• Bytt eier
• Beskrivelse av funksjonalitet
• Kapasitetskartlegging
• Avhengighet av andre komponenter
• Vurdert / anmelderens navn
• URL
• Organisasjonsnavn / ID
• Andre kommentarer

Versjonskontroll og kontinuerlig integrasjon

Migrering av endringer i produksjonen bør være en jevn prosess, siden det bare er en gjentakelse av å bruke endringer i test- og iscenesettelsesmiljøet. Likevel er det alltid en sjanse for at ting går sørover, og da trenger du en reserveplan. Det er veldig viktig å ta sikkerhetskopi av organisasjonens metadata, og det er det versjonskontroll og CI-bygg er for.

Versjonskontroll er et absolutt must for enhver organisasjon. Det lar utviklere jobbe på en samarbeidende, effektiv og trygg måte. Å administrere multiutvikler, kodeutvikling og migrering av flere sandkasser er en utfordring i Salesforce. Salesforce har også sin egen tidsplan for utgivelser og vedlikehold. Disse oppdateringene gir nye funksjoner, men de kan introdusere en endring i Metadata API som kan ødelegge CI-bygningen din. Så bortsett fra situasjoner der utviklere overskriver hverandres endringer, hjelper versjonskontroll deg med å bygge en tilbakeføringsstrategi. Å ha en tilbakevendingsstrategi er et must når søknaden din kjører på Force.com.

Følgende flytskjema viser en praktisk struktur for versjonskontroll og CI. Vi prøver å gi deg en rask beskrivelse av hva diagrammet representerer.

1. En utvikler vil sjekke endringen i versjonskontrollsystemet.
2. CI Server / Jenkins ville distribuere den siste versjonen til CI-sandkassen og kjøre testklasser.
3. Hvis distribusjonen i trinn 2 er vellykket, blir endringene slått sammen i QA-grenen.
4. CI ville da distribuere den siste forpliktelsen fra QA-grenen til QA-sandkassen.
5. Hvis QA avviser endringene på grunn av testfeil, bør trinn 1 til 3 utføres igjen til QA fjerner endringene.
6. Etter at endringene er bestått i QA, blir endringene slått sammen i mastergrenen.
7. De siste endringene fra Master-grenen distribueres til Master-sandkassen.

Man kan velge å legge til flere filialer avhengig av organisasjonens behov. Men ovennevnte struktur fungerer bare bra for utviklingsstrukturer på medium til bedriftsnivå.

Sandkasseadministrasjon

For å få mest mulig ut av DevOps-prosessen i organisasjonen din, er det veldig viktig å sette opp sandkassestrukturen. Før vi dykker mye dypere inn i det, la oss diskutere de forskjellige typene sandkasser Salesforce tilbyr oss.

En sandkasse er en nesten eksakt kopi av produksjonsmetadataene. Sandkasser brukes vanligvis til utvikling, testing, iscenesettelse og treningsformål. Det er fire typer sandkasser, og man bør ta hensyn til det når man velger en sandkasse. Sandkasser i full kopi kan koste mye penger!

Nedenfor er tabellen for grensene håndhevet av Salesforce for forskjellige sandkasser.

Tabell 2: Begrens sammenligning

	Utvikler	Utvikler Pro	Delvis kopi	Full kopi
Produksjonsdata	Nei	Nei	Ja	Ja
Datalagring	200 MB	1 GB	5 GB (10 000 poster per objekt)	Komplette data
Oppdateringsperiode	1 dag	1 dag	5 dager	29 dager

Vi kan se at prisen ikke er den eneste forskjellen mellom sandkasser.

Utviklerens sandkasse har en oppdateringsperiode på én dag, noe som gjør den egnet for utvikling, men kan bare romme 200 MB data og ingen produksjonsdata. Som et motsatt punkt har fullkopisandkasser en nøyaktig kopi av produksjonsdataene; til og med post-ID-ene er de samme. Det kan gjøre det flott for testing og iscenesettelse, men oppdateringsperioden på 29 dager gjør det vanskelig å få de nyeste produksjonsmetadataene og dataene i den fullstendige sandkassen.

Tabellen nedenfor fungerer som en tommelfingerregel for valg av sandkasser:

Tabell 3: Bruk tilfeller for valg av sandkasse

	Utvikler	Utvikler Pro	Delvis kopi	Full kopi
Utvikling	Ja	Ja	Nei	Nei
QA	Ja	Ja	Ja	Nei
Integrasjonstest	Nei	Nei	Ja	Ja
Batch Data Test	Nei	Nei	Ja	Ja
Opplæring	Nei	Nei	Ja	Ja
UAT	Nei	Nei	Ja	Ja
Lastetest	Nei	Nei	Nei	Ja
Iscenesettelse	Nei	Nei	Nei	Ja
Brukeropplæring	Nei	Nei	Nei	Ja

Nedenfor er den typiske organisasjonsstrukturen som er vedtatt for mellomstore prosjekter. For klienter på bedriftsnivå blir organisasjonsstrukturen mer kompleks, men følger generelt modellen nedenfor.

Salesforce-utvikling gjøres vanligvis i utviklerens sandkasse (rød) og endringene flyttes til integrasjonssandkassen (grønn) som vanligvis er en utviklerprosess eller en delvis kopi sandkasse. Deretter flyttes endringene fra flere integrasjonssandkasser opp til samleboks (gul) som skal være en delvis kopi sandkasse.

Hvis organisasjonen din har integrasjoner med tredjepartssystemet som trenger integrasjonstesting og belastningstesting for å bli utført, må man ha et stabilt datasett som ikke endres fra utgivelse til utgivelse. Så det er bedre å ha en full eller delvis kopi sandkasse for den.

Disse endringene blir deretter flyttet til integrasjonstestkassen, hvor testene utføres. Deretter flyttes endringene til den iscenesatte sandkassen, som skal være en fullkopisk sandkasse. Alle testklassene kjøres før distribusjon. En distribusjonsvalidering bør utføres for å sikre at distribusjonen skjer uten problemer.

Denne prosessen hjelper oss med å sørge for at endringene går gjennom flere testerunder og par med øyne. Det kommer med en tung ulempe at det krever mye tid å utvikle, teste og distribuere endringer.

Svært ofte er det et presserende behov for å utføre feilrettinger eller oppdateringer. For å håndtere disse raskt, bør man ha en utviklersandkasse, som vil skyve små lapper direkte til samleboks.

Som nevnt tidligere er en sandkasse en nesten nøyaktig kopi av produksjonsmetadata, men ikke helt. Det er en offisiell liste av komponenter / funksjoner som er deaktivert i en sandkasse.

En annen ting du bør vurdere når du oppdaterer en sandkasse, er at den bare kopierer produksjonsmetadataene og dataene. Det er ingen måte å kopiere metadataene fra en sandkasse til en annen, eller til og med å opprette en tom sandkasse uten metadatakonfigurasjoner (som gratis utviklerorganisasjoner). Noen ganger blir dette en utfordring i virkelige situasjoner. Salesforce har planer om å løse dette problemet, og dette trekk kan snart bli generelt tilgjengelig.

I tillegg, hvis du har noen sensitive data i produksjon som du føler at utviklings- eller testteamet ikke skal ha tilgang til, kan du opprette sandkassemaler for helt og delvis kopierte sandkasser.

Hva du bør vurdere når du distribuerer

Vi har dekket bransjepraksisene med applikasjonens livssyklusadministrasjon i Salesforce-økosystemet. Metadata- og sandkasseadministrasjon spiller en veldig viktig rolle i å skape distribusjonspakker og nyttelaster. For store og komplekse Salesforce-applikasjoner , versjonskontroll hjelper til med å sikre at metadataendringene blir sporet, samtidig som det hjelper til med å lage en tilbakeføringsstrategi.

Sandkasseadministrasjon er avgjørende for store eller komplekse prosjekter. Men sandkassene er kostbare i Salesforce-økosystemet, både når det gjelder økonomiske ressurser og tid. Å formulere en strategi for sandkasseadministrasjon er alltid avgjørende for prosessen for frigjøringsadministrasjon.

Vi gir deg noen ekstra poeng som det vil være greit å huske på under din neste distribusjon:

1. Bare 10 000 filer, eller en 39 MB ZIP-fil, kan distribueres på en gang. Hvis nyttelasten er for stor, må du naturligvis dele pakken i flere deler og deretter gjøre distribusjonen.
2. Hvis distribusjonen mislykkes på grunn av request timeout feil, prøv å fjerne objekter, egendefinerte felt og profiler fra pakken. Disse komponentene tar lengre tid å distribuere.
3. Hvis en felttype endres, eller det har skjedd endringer i rollehierarkiet, kan det være lange forsinkelser på grunn av datarekalkulering, noe som krever litt tid å fullføre.
4. Salesforce låser alle komponenter som for øyeblikket brukes av en bruker i systemet. Hvis vi prøver å distribuere mens det er tilfelle, vil distribusjonen mislykkes.

Forhåpentligvis vil denne oversikten hjelpe deg under din neste Salesforce-utgivelse.

---

Kilder

Ydmyk, Jez; Farley, David (2011). Kontinuerlig levering: pålitelige programvareutgivelser gjennom bygge-, test- og distribusjonsautomatisering . Pearson Education, Inc. s. 110. ISBN 978-0-321-60191-9.