Salesforce DevOps voor admins: deployen zonder Git aan te raken

Kort antwoord: een Salesforce-admin hoeft geen Git te leren om veilig te deployen. Wat je nodig hebt is een pipeline met versiebeheer, en een ticketgedreven DevOps-tool kan die voor je draaien: jij kiest je wijzigingen in een interface, de tool commit ze, opent de pull request, draait de tests en promoot het werk door je omgevingen. Git draait er nog steeds onder. Het is alleen niet langer jouw interface.

Heb je Git nodig voor Salesforce DevOps?

Nee. Je hebt nodig wat Git je geeft, en dat is iets anders. Drie begrippen dragen bijna alle waarde, en geen ervan vraagt om een terminal.

• Versiebeheer: een permanent register van elke metadata-wijziging, wie hem maakte en wanneer, zodat je later kunt vergelijken of terugdraaien.
• Pipeline: een vast pad dat je wijzigingen afleggen, bijvoorbeeld dev-sandbox naar UAT naar productie, met dezelfde controles bij elke stap.
• Work item: het ticket waar een wijziging bij hoort, zodat een release een lijst goedgekeurde tickets is in plaats van een lijst componenten die iemand zich herinnerde.

Een workflow zonder Git is geen workflow zonder versiebeheer. Het is een workflow waarin het versiebeheer voor jou geautomatiseerd wordt.

Waarom schalen change sets niet mee met een adminteam?

Change sets zijn de echte gevestigde orde, en ze houden het prima vol tot een tweede persoon wijzigingen gaat maken. Twee beperkingen richten de meeste schade aan. Ten eerste heeft een change set een deployment connection nodig en reist hij alleen tussen org's die bij dezelfde productie-org horen, waardoor niet-gerelateerde org's simpelweg onbereikbaar zijn (Salesforce Help). Ten tweede is een change set een eenmalig pakket: geen historie, geen undo, en na uploaden niet meer aanpasbaar, dus een afgekeurde release betekent de componentenlijst met de hand opnieuw opbouwen.

De pijnlijkste fout is niet de deployment die faalt. Het is de stille overschrijving: twee mensen bewerken dezelfde flow of page layout in verschillende sandboxen, en wie als tweede deployt wint geruisloos.

Hoe ziet een ticketgedreven deployment er van begin tot eind uit?

Dit is de flow die de meeste admins nooit te zien krijgen, dus hier staat hij volledig. Niets hieronder vraagt om een command line.

1. Koppel de org's eenmalig. Autoriseer productie en elke sandbox via OAuth. Een platform dat standaard Salesforce-API's gebruikt installeert geen package in je org, dus er valt later niets te de-installeren.
2. Definieer de pipeline. Benoem je omgevingen en de volgorde waarin ze promoten. Dit doe je een keer, en daarna is het de enige route naar productie.
3. Open een ticket. Een ticket per wijziging, bij voorkeur per user story. Het ticket, niet de sandbox, is nu de eenheid van je release.
4. Bouw in je sandbox precies zoals je nu doet. Klikwerk, Flow Builder, page layouts. Aan de manier waarop je Salesforce configureert verandert niets.
5. Selecteer je wijzigingen. De tool toont wat er sinds de laatste sync in die sandbox is veranderd. Je vinkt de componenten aan, schrijft een korte omschrijving en hangt ze aan het ticket.
6. Review voordat er iets beweegt. Apex-tests en coverage draaien automatisch, en een AI-review leest de diff op governance-drift, beveiligingsrisico's en afwijkingen van best practices. Een collega keurt het ticket goed.
7. Promoot dezelfde selectie. Het goedgekeurde ticket reist naar UAT en daarna naar productie. Je bouwt de lijst nooit opnieuw op, en juist daar raken change-set releases componenten kwijt.
8. Release, en houd de undo-knop. De productie-deployment wordt vastgelegd, dus als de release zich misdraagt rol je met een handeling terug naar de laatste goede staat in plaats van te reconstrueren wat er live ging.

Wat doet Git terwijl jij klikt?

Elke stap hierboven heeft een Git-equivalent dat het platform voor je uitvoert:

• Een ticket openen maakt een branch aan.
• Componenten selecteren schrijft een commit met jouw omschrijving als bericht.
• Review aanvragen opent een pull request en draait de geautomatiseerde controles daarop.
• Goedkeuren en promoten merget die pull request en start een Metadata API-deployment.
• Terugrollen draait de commit terug en deployt de vorige staat opnieuw.

Dat is om een praktische reden belangrijk: je developers houden de repository, de branches en de CLI die ze al gebruiken, en de admins werken in een interface bovenop diezelfde historie. Er is geen tweede bron van waarheid om te verzoenen.

Is DevOps Center op zichzelf genoeg?

Salesforce levert een eigen gratis optie, en voor een klein team dat change sets achter zich laat is dat een echte stap vooruit. Ken de grenzen voordat je kiest. DevOps Center werkt alleen met cloudgebaseerde GitHub.com-plannen, inclusief GitHub Enterprise Cloud, en lokaal gehoste GitHub Enterprise Server wordt niet ondersteund. Elke gebruiker heeft een eigen GitHub.com-account nodig, en elke projectrepository moet een Salesforce DX-project bevatten (Salesforce Help).

De admin typt dus nooit een Git-commando, maar iemand beheert nog steeds GitHub, en backup, rollback en testautomatisering vallen buiten het product. Herken je je team daarin, dan is een platform dat het hele pad bezit de lichtere optie.

Wat richt een admin in de eerste week in?

1. Kies een pipeline en een productie-org. Modelleer niet op dag een al je omgevingen.
2. Duw een release met laag risico er volledig doorheen voordat je de backlog migreert.
3. Leg een reviewregel schriftelijk vast, bijvoorbeeld: geen ticket naar productie zonder een goedkeuring.
4. Zet automatische Apex-tests aan bij de UAT-stap, niet bij de productiestap, zodat fouten vroeg opvallen.
5. Doe bewust een rollback in een sandbox, zodat het team hem heeft gebruikt voordat het hem nodig heeft.

Serpent draait deze flow met Git op de achtergrond, installeert niets in je Salesforce-org en bevat AI-codereview in elk plan, ook in het gratis plan. Het opzetten kost minder dan 15 minuten en ons team doet het samen met jou.

FAQ

Kan een Salesforce-admin DevOps doen zonder developer?

Ja. Metadata selecteren, een diff beoordelen en een release goedkeuren zijn adminvaardigheden. Wat je niet kunt overslaan is het proces: een pipeline, een ticket per wijziging, een goedkeuring.

Krijg ik in een workflow zonder Git nog steeds rollback?

Alleen als de tool versiehistorie bijhoudt. Terugrollen kan omdat elke deployment eerst is gecommit, en dat is precies wat change sets nooit doen.

Worden mijn developers vertraagd door een admin-interface?

Nee, zolang beide kanten dezelfde repository delen. Developers houden de CLI en hun branches; de interface is een andere deur naar dezelfde historie.

Wat doe ik met mijn bestaande change sets?

Houd ze een release aan terwijl je de nieuwe pipeline parallel draait, en zet ze daarna stop. Migreer nooit een release die al onderweg is.

Meer stapsgewijze Salesforce DevOps-uitleg vind je in onze SF Guides-bibliotheek.