En guide til Salesforce DevOps - del 1

Utvikling på Salesforce-plattformen har tradisjonelt vært utfordrende, med tungvint deployment og manuelle prosesser som stjeler tid fra utviklerteam. De siste årene har nye verktøy og prinsipper revolusjonert hvordan man utvikler på Salesforce-plattformen. Denne artikkelserien gir en praktisk innføring i hvordan din bedrift eller ditt team kan spare både tid og ressurser gjennom moderne DevOps-prinsipper og verktøy. Bruk mer tid på å skape verdi og mindre tid på repetitive oppgaver.

Hva er DevOps?

DevOps er et sett med praksiser og prinsipper som knytter utviklings- og driftsprosessene tettere sammen. Istedenfor at disse teamene jobber hver for seg, fremmer DevOps samarbeid for å øke effektiviteten. Dette gjør det mulig å lansere nye funksjoner raskere og mer pålitelig, samtidig som feil og nedetid reduseres.

Kjerneprinsippene i DevOps inkluderer:

• Automatisering: Automatisere repetitive oppgaver for å minimere feil
• Kontinuerlig integrasjon (CI) og kontinuerlig distribusjon (CD): Hyppig integrasjon av kodeendringer og automatisert utrulling
• Samarbeid: Forbedre kommunikasjonen mellom utvikling og drift
• Overvåkning og feedback: Kontinuerlig overvåking av applikasjoner for å forbedre dem over tid

Salesforce DevOps: Hvorfor er det viktig?

Salesforce er en kritisk plattform for mange bedrifter, men tradisjonelle utviklingsmetoder har ofte vært preget av manuell håndtering av endringer og deployment. Salesforce DevOps tar tak i disse utfordringene ved å automatisere prosesser, forbedre samarbeid, og redusere feilrisiko.

Fordelene med Salesforce DevOps:

• Raskere til markedet: Automatisert testing og utrulling reduserer tiden det tar å lansere nye funksjoner
• ‍Bedre samarbeid: Versjonskontroll med Git gjør det enklere å samarbeide, spore endringer og unngå konflikter
• ‍Reduksjon av feil: Automatiserte pipelines reduserer manuelle feil og sikrer at alle endringer blir grundig testet
• ‍Kostnadsbesparelser: Effektivisering gjennom automatisering frigjør tid og reduserer kostnader

Utfordringer med tradisjonell Salesforce-utvikling

Mange Salesforce-team benytter fortsatt en org-basert utviklingsmodell der produksjonsmiljøet er "source of truth". Dette innebærer manuelle Change Sets for å flytte endringer mellom miljøer, noe som ofte er tidkrevende og feilutsatt.

Typiske utfordringer inkluderer:

• ‍Manglende sporbarhet: Vanskelig å holde styr på endringer og hvem som har gjort hva
• ‍Høy risiko for konflikter: Når flere utviklere jobber i samme org kan endringer overskrives
• ‍Langsomme deployments: Change Sets krever manuell selektering av komponenter, noe som forsinker utrullinger

Hvordan løser Salesforce DevOps disse utfordringene?

Versjonskontroll med Git: Ved å bruke Git som "source of truth", får du full sporbarhet, historikk og kontroll over alle endringer. Dette gjør det enklere å samarbeide på tvers av team, med mulighet for å bruke branches for parallell utvikling. Git er blitt bransjestandard for utvikling i alle typer software-prosjekter. Det er på tide for Salesforce-utvikling å bli med på toget.

Automatisering med CI/CD: Når endringer pushes til GitHub, kan automatiserte workflows ta over. Dette kan inkludere:

• ‍Automatiserte tester: For å sikre kvalitet og unngå regresjoner
• ‍Kontinuerlig utrulling: Godkjente endringer kan automatisk distribueres til sandboxer eller produksjon

Saleforce DX - Kapabiliteter på Salesforce plattformen

I en stackoverflow undersøkelse i 2017 ble Salesforce kåret utviklere til en av de mest fryktede plattformene å utvikle på. Siden den gang har Salesforce introdusert Salesforce DX for å bedre denne opplevelsen. Dette har gitt plattformen mange ny kapabiliteter som kan bidra til å gjøre det enklere å utvikle på Salesforce. Viktig å merke seg at Salesforce kun tilbyr disse byggeblokkene, men ikke en fullstendig løsning. Det er derfor opp til community'et og tredjeparts-leverandører å tilby løsninger som lar utviklere ta dette i bruk på en verdifull måte.

Salesforce CLI

Salesforce CLI er et kommandolinjeverktøy som brukes til å administrere Salesforce-org'er og utviklingsprosesser. Det gir funksjonalitet for å synkronisere metadata mellom lokalt utviklingsmiljø og en org, administrere scratch orgs, pakkehåndtering og mye mer. Salesforce CLI er spesielt nyttig for utviklere, da det forenkler komplekse oppgaver og er enkelt å implementere i DevOps-verktøy og automatiserte prosesser.

Scratch orgs

En Scratch Org er en midlertidig, blank Salesforce-org som lar utviklere starte fra "scratch" med å teste og utvikle funksjoner. De er designet for source-driven utvikling. Innstillinger defineres i en konfigurasjonsfil, i stedet for å kopiere fra en eksisterende produksjons-org, som tradisjonelle sandboxes gjør. Dette gjør scratch orgs ideelle som personlige, isolerte utviklings-miljøer, noe som øker produktiviteten og reduserer konflikter.

En stor fordel med scratch orgs er at de er raske å spinne opp og kan slettes når de ikke lenger er nødvendige, noe som gir høy fleksibilitet sammenlignet med tradisjonelle sandboxes. De provisjoneres med verktøy som Salesforce CLI, hvilket gjør det mulig å implementere som en del av CI/CD-prosessen. Scratch orgs er derfor egnet for å gjøre valideringer, som apex-tester og deployment.

På den andre siden er scratch orgs tidsbegrensede og eksisterer kun i opptil 30 dager, noe som kan være upraktisk for langsiktige POC'er. I motsetning til sandboxes, som kan inneholde realistiske produksjonsdata for mer omfattende testing, krever scratch orgs ofte separat data import. Dette gjør sandboxes er bedre egnet for integrasjonstesting og brukergodkjenning.  Scratch orgs et mer fleksibelt alternativ for rask utvikling og korte arbeidsløp.

Ved å kombinere bruken av scratch orgs tidlig i utviklingen med sandboxes senere, kan team optimalisere både effektivitet og kvalitet i prosjektene sine.

For å få ordentlig nytte av scratch orgs, så kreves en omstilling til source-driven utvikling. De er raske å spinne opp, men inneholder ingen metadata-konfigurasjon. I seg selv er de derfor ikke så veldig nyttige for et eksisterende prosjekt hvor man bygger videre på eksisterende konfigurasjon. Om det skal brukes som et fullverdig utviklingsmiljø så bør de pre-provisjoneres med konfigrasjon fra et kildekode repo.

Unlocked Packages

En unlocked package er en fleksibel måte å håndtere metadata på i Salesforce. Pakkene fungerer som containere for metadata som kan legges til, endres eller fjernes i en Salesforce-org på en sporbart måte. De er spesielt nyttige for interne forretningsapplikasjoner, da de gir mulighet for direkte endringer i produksjon ved behov. Hver pakke har en distinkt utviklingssyklus: du kan oppdatere metadata, lage en ny pakkeversjon, teste den, og deretter installere den i produksjon. Dette gir deg full kontroll over hva, når og hvordan metadata rulles ut.

Pakkens versjoner er uforanderlige og kan installeres i ulike org-typer, som produksjon eller sandbox. Ved installasjon kan du se hvilke metadata som kommer fra hvilken pakke og få oversikt over all metadata knyttet til en spesifikk pakke. For å unngå konflikter mellom utviklere og administratorer når metadata endres i produksjon, kreves god styring og kommunikasjon. Unlocked packages gjør det enklere å teste og oppgradere Salesforce-apper, samtidig som de støtter iterative utviklingssykluser.

Org-dependent unlocked packages

En utfordring med unlocked packages er at de ikke kan være avhengig av metadata som ikke er pakketert. En relativt ny variant løser dette problemet med org-dependent unlocked packages. Her er det tillatt med avhengigheter til ikke-pakketert metadata i installasjons-org'en. Når en bruker org-dependent unlocked packages, så skjer metadata valideringen under installasjon og ikke under versjons-bygging.

Verktøy for Salesforce DevOps

Selv om Salesforce har introdusert flere kapabiliteter for å støtte moderne utviklingsmetodikk, tilbyr de ikke en komplett DevOps-løsning ut av boksen. Det er derfor opp til hvert enkelt team å sette sammen sin egen verktøykjede basert på behov og modenhet. I denne artikkelen fokuserer vi på ett verktøy vi mener skiller seg ut i open-source-landskapet: flxbl package manager - sfp. Det er et godt eksempel på hvordan man kan bygge en profesjonell DevOps-løsning på toppen av Salesforce-plattformens egne byggeklosser.

‍
Open-source verktøy: sfp

Det er ingen hemmelighet at vi er glad i open-source. Det kanskje mest spennende verktøyet tilgjengelig akkurat nå er sfp. Dette er et kraftig verktøy som forenkler modularisert utvikling på Salesforce plattformen. Med sfp kan du orkestrere hele utviklings-syklusen.

Opprinnelig bygget som en plugin til Salesforce CLI (under navnet "sfpowerscripts") har dx@scale nå rebrandet seg til flxbl og lansert sfp. Fra å være et sett av script bygget rundt Salesforce CLI kommandoer, har de bygget en helt eget CLI ved bruk av bl.a. Salesforce sine npm-pakker. Dette gir mer robusthet og resultatet er en helt ny måte å tenke Salesforce-utvikling på. CLI'en er bygget for å integreres i CI/CD prosesser og mange av kommandoene har støtte for å sjekke etter endringer i repoet.

Som et fullverdig bygge-verktøy hjelper sfp deg med å automatisere deployment og kvalitetssikring på tvers av Salesforce-miljøer. Dette verktøyet gjør det enkelt å håndtere Salesforce metadata, pakker og deployment pipelines. I tillegg krever sfp veldig lite tilpasning av din Salesforce-org. Det er to pakker som må installeres før man tar det i bruk, men de introduserer bare en håndfull custom felt og settings.



‍

Hva tilbyr sfp?

Bygging av versjonerte Salesforce-pakker
Sfp tilbyr orkestrering for bygging av Salesforce Unlocked packages. Som en del av deployment pipelinen støtter også sfp ikke-pakketert metadata gjennom deres egne konsepter som source-packages og data-packages. I tillegg gir muligheter for feature-toggling og miljø-spesifikk deployment. Slik er sfp det ultimate verktøyet for å orkestrere hele pipelinen.

Scratch-org pooling
Som nevnt kan det ta tid å bygge scratch orgs fra kildekode. Sfp løser dette ved å pre-provisjonere "pools" av scratch-orgs. Scheduler en jobb ved hjelp av ditt foretrukne CI/CD verktøy og scratch-orgene er klare på minutter når du kommer på jobb om morgenen.

Automatisert testing og deployment validering
Valider nyeste endringer mot scratch-orgs. Vær sikker på at alle unit-tester er vellykkede og forsikre deg om at de nyeste endringen lar seg deploye til andre miljøer og at ingen konfigurasjon er glemt. På denne måten slipper du å håndtere disse problemene når man skal ut i produksjon.

Release Management
Reduserer kompleksiteten ved utrulling, spesielt for større organisasjoner. Hvis en har utnyttet sfp sine kapabiliteter og modularisert sin Salesforce applikasjon i pakker, så gir sfp muligheten for å kjøre granulære deployments. Her kan individuelle pakker oppdateres med en gitt versjon, hvilket gir god robusthet og mulighet for å rulle tilbake endringer ved behov.

Fordeler

• Godt egnet for større utviklings-team
• Tar hånd om alle ledd i utviklings-syklusen
• Gode støtteverktøy for håndtering av profiler
• Stor mulighet for tilpasning med egne skript
  ‍

Ulemper

• Bratt læringskurve
• Utvikler-rettet verktøy: vanskelig å bruke om man ikke er kjent med git og terminal
  
  ‍

Konklusjon

Salesforce-plattformen har tradisjonelt vært forbundet med manuelle prosesser og begrensede verktøy for profesjonell programvareutvikling. Men med fremveksten av Salesforce DX, moderne DevOps-praksis og kraftige verktøy som SFP, har utviklerteam nå muligheten til å jobbe smartere og mer effektivt. Ved å ta i bruk versjonskontroll, CI/CD og pakkebasert utvikling kan man redusere risiko, øke leveransefrekvensen og få bedre kontroll på endringene.

I neste del skal vi se nærmere på hvordan man faktisk implementerer en DevOps-strategi i praksis: hvordan sette opp CI/CD med GitHub Actions og andre plattformer — og hvordan DevOps Center kan hjelpe både utviklere og administrasjon å samarbeide effektivt. Følg med videre!

‍

‍