Nog niet op source control is een goed signaal, geen schande

Kort antwoord: een Salesforce-team dat nog met change sets deployt loopt niet achter, het is onbelast. Er is geen half gebouwde pipeline om af te breken, geen verlaten branching-model om uit te leggen en geen scripts van iemand die allang weg is. De eerste week met source control is voor dat team korter dan voor bijna ieder ander, en de winst is groter.

Waarom is "nog niet op source control" een goed signaal?

Omdat het gat tussen waar je staat en waar je kunt staan de hele afstand is, en niets ervan wordt geblokkeerd door een eerdere keuze. Teams die nooit begonnen zijn hebben drie stille voordelen:

• Niets te migreren. Je org is vandaag de bron van waarheid. Dat is een schone basis, geen rommel.
• Geen sunk-costpolitiek. Niemand hoeft toe te geven dat de pipeline die hij in 2023 bepleitte doodliep.
• Geen gewoontes om af te leren. Het team leert een werkwijze, een keer, en dat mag meteen de moderne zijn.

De Salesforce-teams met de slechtste releaseresultaten zijn zelden de change-setteams. Het zijn de half gemigreerde teams: twee deploymentpaden naast elkaar, een persoon die de YAML begrijpt, en een reviewstap waar iedereen omheen loopt zodra de release laat is.

Waar bestaat de pijn van change sets echt uit?

De pijn is echt, en die precies benoemen helpt meer dan te horen krijgen dat je achterloopt. Op basis van een goed gepubliceerd overzicht van hoe change sets zich gedragen zijn dit de terugkerende kosten:

• Een change set is na uploaden niet meer aan te passen. Vergeet je een component, dan kloon je en bouw je het pakket opnieuw.
• Componenten worden met de hand geselecteerd, en de dependency-hulp mist indirecte ketens van verwijzingen.
• Deploymentverbindingen zijn standaard eenrichtingsverkeer, en niet-gerelateerde productieorgs kunnen helemaal niet naar elkaar deployen.
• Sommige metadata reist simpelweg niet mee, waaronder standaard picklistwaarden en organisatiebrede e-mailadressen.
• Profielen overschrijven in de doelorg, waarbij rechten die niet in de bron zaten stilletjes verdwijnen.
• Er is geen rollback na een deployment, en er wordt vooraf geen snapshot gemaakt.

Merk op dat niets daarvan een kwestie van vaardigheden is. Het is een gereedschapsprobleem dat je team met overwerk heeft opgevangen.

Wat moet je eigenlijk leren?

Minder dan het gesprek suggereert. De gewoonte om "wij zitten nog niet op Git" te beantwoorden met een college over branchingstrategie heeft echte schade aangericht, want zij verschuift de eerste stap van veiliger deployen naar developer worden. Dat zijn niet dezelfde projecten.

Een change-setteam heeft het meeste dat telt al in huis: kennis van de org, een sandboxgewoonte, gevoel voor wat er breekt. Wat het nodig heeft is een registratie van elke wijziging, een manier om er een terug te draaien, en een review die voor productie plaatsvindt in plaats van na het incident. Git kan die drie leveren terwijl het op de achtergrond draait. Of je admins ooit een terminal openen is een keuze in gereedschap, geen wet van het platform.

Hoe begin je volgende week zonder DevOps-engineer?

1. Zet een snapshot van de org in een repository. Nog niet om vanaf te deployen. Alleen zodat de staat van vandaag vastligt en wijzigingen van morgen zichtbaar zijn als diff.
2. Koppel je bestaande sandboxes. Behoud de omgevingen die je hebt. Het pad van developer sandbox naar UAT naar productie hoeft op dag een niet te veranderen.
3. Verplaats een terugkerend type wijziging. Kies de deployment die je het vaakst doet en stuur twee weken lang alleen die door het nieuwe pad.
4. Zorg dat rollback werkt voordat je uitbreidt. De eerste keer dat een release in een minuut wordt teruggedraaid in plaats van in een avond is de discussie voorbij.
5. Voeg review als laatste toe. Zodra wijzigingen als diff binnenkomen kost een tweede paar ogen minuten. Review daarvoor invoeren is precies wat teams doet afhaken.

Dit kan met Salesforce DevOps Center, met Gearset of Copado, of met Serpent. Vergelijk ze eerst eerlijk op een as: hoeveel van de werkwijze gaat uit van iemand die beroepsmatig YAML schrijft.

Wat kun je negeren?

• Maturity-modellen die je afzetten tegen bedrijven met een platformteam van acht.
• Discussies over branchingstrategie. Een beschermde main-branch en kortlevende feature branches brengen je jaren verder.
• Iedereen die suggereert dat source control een moreel standpunt is. Het is een mechanisme om fouten ongedaan te maken. Meer is het nooit geweest.

Serpent is precies voor dit startpunt gebouwd: deployments op basis van tickets met Git eronder, rollback met een klik, AI-codereview op elk plan en geen Git-expertise nodig van admins of consultants. Het installeert niets in je org, opzetten kost minder dan 15 minuten, en ons team doet een hands-on sessie met iedereen in plaats van je een handleiding te geven. Er is een gratis Essentials-plan met onbeperkt aantal gebruikers, en je kunt bij het aanmelden een gevulde demo-workspace kiezen als je eerst wilt kijken. Begin bij Serpent.

FAQ

Is het te laat om van change sets af te stappen?

Nee. Change sets worden nog ondersteund en werken nog. Overstappen gaat over deploymentrisico en teamtijd, niet over een deadline die je gemist hebt.

Moeten onze admins Git leren?

Niet met gereedschap dat Git op de achtergrond houdt. Admins moeten begrijpen wat een versie en een rollback zijn. Branchingcommando's zijn optioneel.

Wat is de grootste winst in week een?

Rollback. Een slechte release snel kunnen terugdraaien verandert het gevoel rond deployen meer dan welke andere functie ook.

Is DevOps Center genoeg?

Het is een echte stap vooruit ten opzichte van change sets en het is gratis van Salesforce, dus een eerlijke plek om te beginnen. Teams ontgroeien het meestal zodra ze packaging, testpoorten of rijkere rollback nodig hebben.

Moeten we de org eerst opruimen?

Nee. Breng de org onder source control zoals hij is. Een vastgelegde rommel is veel makkelijker te verbeteren dan een niet-vastgelegde.