Salesforce DevOps Course Module 1: What is Salesforce DevOps? Complete Beginner Guide 2026
๐
DevOps
๐ Free Salesforce DevOps Course 2026
Module 1 of 15
What is Salesforce DevOps?
Complete Beginner Guide
Complete Beginner Guide
Start your Salesforce DevOps journey from zero. No experience needed. Learn what DevOps is, why it matters, how it transforms Salesforce development, and the tools that power it all — with real examples throughout.
15
Total Modules
M1
Beginner
Free
Forever
2026
Updated
๐ Course Progress — Module 1 of 15
M1
You Are Here
You Are Here
M2
Sandboxes
Sandboxes
M3
Change Sets
Change Sets
M4
Metadata API
Metadata API
M5
Git Basics
Git Basics
M6
SFDX & CLI
SFDX & CLI
M7
Scratch Orgs
Scratch Orgs
M8
Packages
Packages
M9
DevOps Center
DevOps Center
M10
Deploy Strategy
Deploy Strategy
M11
GitHub Actions
GitHub Actions
M12
Advanced CI/CD
Advanced CI/CD
M13
Unlocked Pkg
Unlocked Pkg
M14
Enterprise
Enterprise
M15
Capstone
Capstone
๐ What You Will Learn in This Module
๐ Full Course Navigation
M1 — What is Salesforce DevOps? ๐
M2 — Environments & Sandboxes
M3 — Change Sets Mastery
M4 — Metadata API Basics
M5 — Version Control with Git
M6 — SFDX & SF CLI Setup
M7 — Scratch Orgs
M8 — Salesforce Packages
M9 — DevOps Center
M10 — Deployment Strategies
M11 — GitHub Actions CI/CD
M12 — Advanced CI/CD Patterns
M13 — Unlocked Packages
M14 — Enterprise DevOps
M15 — Capstone Project
๐ค Section 1 — What is DevOps?
Understanding the foundation before applying it to Salesforce
๐ The Simple Explanation
DevOps is a way of working that combines Development (writing code) and Operations (deploying and maintaining that code) into one smooth, automated process.
Before DevOps, developers wrote code and threw it "over the wall" to an operations team who deployed it manually — slowly, carefully, and often with errors. DevOps breaks down that wall.
Before DevOps, developers wrote code and threw it "over the wall" to an operations team who deployed it manually — slowly, carefully, and often with errors. DevOps breaks down that wall.
๐ฏ Real World Analogy
Think of it like a restaurant kitchen:
❌ Without DevOps: The chef (developer) cooks the food and hands it to a completely separate delivery team (operations) who has never seen the dish before. The delivery team doesn't know the ingredients, doesn't know how it should look, and sometimes drops it on the way.
✅ With DevOps: The same team cooks AND delivers. They have a checklist (automated tests), a standardized container (version control), and an automatic delivery route (CI/CD pipeline). Every dish arrives the same way, every time — perfectly.
❌ Without DevOps: The chef (developer) cooks the food and hands it to a completely separate delivery team (operations) who has never seen the dish before. The delivery team doesn't know the ingredients, doesn't know how it should look, and sometimes drops it on the way.
✅ With DevOps: The same team cooks AND delivers. They have a checklist (automated tests), a standardized container (version control), and an automatic delivery route (CI/CD pipeline). Every dish arrives the same way, every time — perfectly.
✅ The 3 Core Principles of DevOps
| Principle | What It Means | In Salesforce Terms |
|---|---|---|
| ๐ Collaboration | Dev and Ops work together | Developers + Admins in same pipeline |
| ๐ค Automation | Repetitive tasks done by machines | Automated testing & deployment |
| ๐ Continuous Delivery | Small, frequent, safe releases | Deploy every week instead of every quarter |
๐ Key Takeaway
- DevOps is NOT a tool — it is a culture and set of practices
- The goal is to deliver changes faster, safer, and more reliably
- Automation is the engine that makes DevOps work at scale
- DevOps reduces the fear of deployment — from a quarterly event to a daily routine
☁️ Section 2 — What is Salesforce DevOps?
How DevOps principles apply specifically to the Salesforce ecosystem
๐ Definition
Salesforce DevOps is the application of DevOps principles — version control, automation, CI/CD, and team collaboration — to Salesforce development and deployment.
It replaces the traditional manual process (build in sandbox → create Change Set → upload → deploy to production → pray ๐) with an automated, version-controlled pipeline where every change is tracked, tested, and deployed consistently.
It replaces the traditional manual process (build in sandbox → create Change Set → upload → deploy to production → pray ๐) with an automated, version-controlled pipeline where every change is tracked, tested, and deployed consistently.
✅ What Salesforce DevOps Includes
| Area | Traditional Way | DevOps Way |
|---|---|---|
| Code storage | Lives only in the org | Stored in Git repository |
| Deployment | Manual Change Sets | Automated CLI + CI/CD |
| Testing | Manual, before every deploy | Automated on every code push |
| Collaboration | One shared sandbox, conflicts everywhere | Individual Scratch Orgs, feature branches |
| Rollback | Manual, painful, risky | Git history — deploy previous version |
| Visibility | "What changed and when?" — nobody knows | Full audit trail in Git commits |
๐ฏ The Salesforce DevOps Stack
| Layer | Tool | Purpose |
|---|---|---|
| Code Editor | VS Code + Salesforce Extension Pack | Write Apex, LWC, metadata locally |
| Version Control | Git + GitHub | Track every change, collaborate safely |
| CLI | Salesforce CLI (sf command) | Deploy, retrieve, test from terminal |
| Dev Environment | Scratch Orgs | Individual isolated development orgs |
| CI/CD | GitHub Actions | Automate validation, testing, deployment |
| Packaging | Unlocked Packages | Modular, versioned deployments |
๐ก Important Note for Beginners
You do NOT need to learn all of this at once. This course takes you through each tool one module at a time — starting with the basics and building up to full CI/CD pipelines. By Module 15, you will have built a complete end-to-end pipeline from scratch. One step at a time! ๐
๐ Section 3 — The Real Problems Without DevOps
Pain points every Salesforce team faces without a proper DevOps process
❌ Problem 1 — The "Who Broke Production?" Problem
It is Monday morning. Production is broken. Orders are not saving. Customers are calling. The question everyone is asking:
- "Who deployed what and when?" — nobody knows
- "What changed since last week?" — no record exists
- "Can we undo it?" — there is no rollback
Without version control, every Salesforce org is a mystery. Changes accumulate silently with no history.
❌ Problem 2 — The "Overwrite" Problem
Two developers working in the same sandbox:
- Developer A spends 3 days writing a complex AccountTriggerHandler
- Developer B also modifies AccountTriggerHandler for a different feature
- Developer B deploys via Change Set first
- Developer A deploys second — completely overwrites Developer B's work
- Developer B's 3 days of work are gone. Silently. No warning.
❌ Problem 3 — The "Change Set Roulette" Problem
- Production deployment day arrives — it is a quarterly event, treated like surgery
- Everyone stops normal work. The deployment window is 2 AM on Sunday
- 40 components in the Change Set. 500 Apex tests running
- 45 minutes in — a test fails on something unrelated to your change
- Rollback. Start over. Next deployment in 3 months
- The fear of deployment means features wait months to reach users
❌ Problem 4 — The "What's in Production?" Problem
- A new team member joins: "What custom code do we have in production?"
- Answer: nobody fully knows
- Some components were built years ago by developers who left
- There is no documentation, no history, no way to understand what is there
- Touching anything feels dangerous — ripple effects are unknown
❌ Problem 5 — The "Environment Drift" Problem
- Developer sandbox has a feature that QA sandbox does not
- QA sandbox has custom settings that production does not
- Production has something nobody remembers adding
- All three environments are different — testing in sandbox means nothing
- The classic line: "It worked in sandbox!"
๐ข XYZ Company — Before DevOps
XYZ Company had 3 Salesforce developers, 1 admin, and 2 sandboxes. Every quarter they had a "deployment day" — a full Sunday of stress. Once they accidentally deployed an old version of the Order trigger that overwrote 6 weeks of work. They lost a full sprint of development because there was no version history. The developers were afraid to make changes because they couldn't predict the impact. Sound familiar?
✅ Section 4 — How Salesforce DevOps Solves Every Problem
The exact solution for each pain point
✅ Solution 1 — Git = Full History of Everything
Every change is committed to Git with a message, author, timestamp, and the exact code that changed. "Who broke production and when?" becomes a 5-second Git log query. Every line of code has a story.
# See exactly what changed and who changed it
git log --oneline
abc1234 Fix Order trigger for international customers — Anant
def5678 Add Visit Report LWC pagination — Anant
ghi9012 Update approval workflow for Europe — Admin
# See exactly what changed in a specific commit
git show abc1234
✅ Solution 2 — Feature Branches = Zero Overwrites
Each developer works in their own Git branch and their own Scratch Org. Changes are merged via Pull Request with code review. The merge process handles conflicts explicitly — no silent overwrites, ever.
| Developer | Branch | Scratch Org |
|---|---|---|
| Developer A | feature/account-trigger | devorg-anant |
| Developer B | feature/order-validation | devorg-raj |
| Merge to main | Pull Request review | CI validates automatically |
✅ Solution 3 — CI/CD = Deployment Every Day, Not Every Quarter
With GitHub Actions, every code push automatically validates and tests. Deployment becomes a boring, reliable routine — not a terrifying quarterly event. Teams at XYZ Company go from deploying once a quarter to deploying twice a week with zero production incidents.
✅ Solution 4 — Git = Living Documentation
The Git repository IS the documentation. Every component has a history. New developers clone the repo and immediately see everything that exists, who built it, and why. Onboarding goes from weeks to days.
✅ Solution 5 — Scratch Orgs = Consistent Environments
Scratch Orgs are created from a definition file — every developer gets an identical environment. "It worked in sandbox!" disappears because all environments are built the same way from the same source. Environment drift becomes impossible.
๐ข XYZ Company — After DevOps
After adopting Salesforce DevOps, XYZ Company's team deploys every Tuesday and Friday. Each developer works in their own Scratch Org with no conflicts. Every PR is automatically validated by GitHub Actions before merging. The last production incident from a bad deployment was 6 months ago. The CTO now asks for new features instead of complaining about broken production.
๐ Section 5 — The Salesforce DevOps Lifecycle
The complete end-to-end flow from idea to production
๐ The 8-Step DevOps Lifecycle
| Step | Stage | What Happens | Tool |
|---|---|---|---|
| 1 | ๐ฏ Plan | Decide what to build, create work item | Jira, GitHub Issues |
| 2 | ๐ป Code | Developer writes code in local VS Code | VS Code + Salesforce Extension |
| 3 | ๐ฌ Build | Push to Scratch Org, test locally | Salesforce CLI |
| 4 | ๐งช Test | Run Apex tests automatically | GitHub Actions + SF CLI |
| 5 | ๐ Merge | Pull Request reviewed and merged | GitHub |
| 6 | ๐ Deploy | Auto-deploy to QA sandbox | GitHub Actions |
| 7 | ✅ Release | QA approved, deploy to production | GitHub Actions |
| 8 | ๐ Monitor | Watch for errors, collect feedback | Salesforce Debug Logs, Monitoring |
๐ฏ The Pipeline in Simple Terms
Developer writes code locally
↓
git add . && git commit -m "Add Visit Report feature"
↓
git push origin feature/visit-report
↓
GitHub Actions triggers automatically:
→ Validates metadata against QA sandbox
→ Runs all Apex tests
→ Reports results on Pull Request
↓
Code review passes → Merge to main
↓
GitHub Actions triggers again:
→ Deploys to production automatically
↓
Feature is LIVE ๐
✅ CI vs CD — What is the Difference?
| Term | Full Name | What It Does | When |
|---|---|---|---|
| CI | Continuous Integration | Automatically validate and test every code push | On every Pull Request |
| CD | Continuous Delivery | Automatically deploy to the next environment | On every merge to main |
๐ Key Takeaway
- The DevOps lifecycle is continuous — it never stops, it keeps improving
- CI catches problems early — before they reach production
- CD makes deployment routine — not an event
- The faster the cycle, the faster users get value
๐ข Section 6 — Org-Based vs Source-Driven Development
The most important concept in Salesforce DevOps — understanding the two worlds
๐ Org-Based Development (The Old Way)
In org-based development, the org IS the source of truth. Code lives in the org. Changes are made directly in the org (Setup UI or Developer Console). To move changes, you manually create a Change Set.
Think of it like writing a document directly on someone else's computer with no backup. If the computer crashes, everything is gone. If two people edit at the same time, whoever saves last wins.
Think of it like writing a document directly on someone else's computer with no backup. If the computer crashes, everything is gone. If two people edit at the same time, whoever saves last wins.
✅ Source-Driven Development (The DevOps Way)
In source-driven development, the Git repository is the source of truth. Code lives in Git first. Orgs are built FROM the repository — not the other way around. You write code locally in VS Code, commit to Git, and push to orgs using the CLI.
Think of it like writing in Google Docs with full version history, real-time collaboration, and the ability to restore any previous version at any time.
Think of it like writing in Google Docs with full version history, real-time collaboration, and the ability to restore any previous version at any time.
๐ Full Comparison
| Aspect | ๐ข Org-Based | ๐ Source-Driven |
|---|---|---|
| Source of Truth | The Salesforce org | Git repository |
| Code Location | Only in the org | Local machine + Git |
| Version History | ❌ None | ✅ Full Git history |
| Team Collaboration | Shared sandbox, conflicts | Feature branches, clean merges |
| Deployment | Manual Change Sets | Automated CLI + CI/CD |
| Testing | Manual, before deploy | Automatic, on every push |
| New environment | Sandbox refresh (hours) | Scratch Org (minutes) |
| Delete components | Manual in Setup | Destructive changes XML |
| Code review | ❌ Not possible | ✅ Pull Request review |
| Rollback | Manual, risky | Deploy previous Git commit |
๐ฏ The Key Mental Shift
Org-Based mindset: "I will log into the sandbox and make this change directly."
Source-Driven mindset: "I will make this change locally in VS Code, commit to Git, and let the CLI push it to the org."
This mental shift is the hardest part of learning Salesforce DevOps — but once it clicks, everything else makes sense.
Source-Driven mindset: "I will make this change locally in VS Code, commit to Git, and let the CLI push it to the org."
This mental shift is the hardest part of learning Salesforce DevOps — but once it clicks, everything else makes sense.
๐ Golden Rule of Source-Driven Development
- Never make changes directly in production — always go through the pipeline
- The Git repo must always match what is in production
- If you make a declarative change (Flow, field) in an org UI — immediately retrieve it to Git
- Treat the org as output, not input — Git in, org out
๐ ️ Section 7 — Salesforce DevOps Tools Overview
Every tool you will use in this course — explained simply
๐ The Full Toolchain
You do not need to know all these tools right now. This is your reference map — by Module 15 you will have hands-on experience with every single one.
๐ข Beginner Tools (You will learn in M1-M5)
| Tool | What It Is | Why You Need It |
|---|---|---|
| VS Code | Code editor | Write Apex, LWC, metadata locally |
| Salesforce Extension Pack | VS Code plugin | Salesforce-specific editing features |
| Git | Version control system | Track every change, collaborate safely |
| GitHub | Git repository hosting | Store code online, team collaboration |
| Change Sets | Built-in Salesforce deployment tool | Simple deployments between connected orgs |
| Workbench | Web-based Salesforce tool | Quick metadata retrieval and deployment |
๐ก Intermediate Tools (You will learn in M6-M10)
| Tool | What It Is | Why You Need It |
|---|---|---|
| Salesforce CLI (sf) | Command line tool | Deploy, retrieve, test from terminal |
| Scratch Orgs | Temporary development orgs | Isolated, consistent dev environments |
| Dev Hub | Central Scratch Org management | Create and manage Scratch Orgs |
| DevOps Center | Native Salesforce DevOps UI | UI-based pipeline without CLI |
| package.xml | Deployment manifest file | Define exactly what to deploy |
๐ด Advanced Tools (You will learn in M11-M15)
| Tool | What It Is | Why You Need It |
|---|---|---|
| GitHub Actions | CI/CD automation platform | Automate validation, testing, deployment |
| Unlocked Packages | Modern Salesforce packaging | Modular, versioned deployments |
| JWT Authentication | Non-interactive org login | Authenticate CLI in CI/CD pipelines |
| Copado / Gearset | Third-party DevOps platforms | Enterprise-scale DevOps management |
๐ก Beginner Tip
Start with just VS Code + Git + GitHub. These three tools form the foundation of everything else. If you are comfortable committing and pushing code to GitHub, the rest of the course will feel natural. We will set these up step by step in Module 5.
๐บ️ Section 8 — Your Salesforce DevOps Journey
Where you are now, where you are going, and how this course gets you there
๐ The 3 Stages of Your Journey
| Stage | Modules | You Will Be Able To |
|---|---|---|
| ๐ข Beginner | M1 → M5 | Understand DevOps concepts, use Change Sets professionally, set up Git and version control for Salesforce |
| ๐ก Intermediate | M6 → M10 | Use SFDX CLI, create Scratch Orgs, work with DevOps Center, deploy using package.xml confidently |
| ๐ด Advanced | M11 → M15 | Build full CI/CD pipelines with GitHub Actions, create Unlocked Packages, manage enterprise-scale releases |
✅ What You Will Build by Module 15
By the end of this course you will have built a complete, production-ready CI/CD pipeline for XYZ Company — a real manufacturing company Salesforce org:
- ✅ GitHub repository with full SFDX project structure
- ✅ Feature branch → QA → UAT → Production pipeline
- ✅ GitHub Actions workflow validating every Pull Request
- ✅ Automatic deployment on merge to main
- ✅ Scratch Orgs for isolated feature development
- ✅ Unlocked Package for modular deployment
- ✅ Non-interactive JWT authentication for the pipeline
- ✅ Full documentation and runbook
๐ฏ Recommended Learning Path
| Week | Modules | Focus |
|---|---|---|
| Week 1 | M1, M2, M3 | Concepts, Sandboxes, Change Sets |
| Week 2 | M4, M5 | Metadata API, Git basics |
| Week 3 | M6, M7 | SFDX CLI, Scratch Orgs |
| Week 4 | M8, M9, M10 | Packages, DevOps Center, Deploy strategy |
| Week 5 | M11, M12 | GitHub Actions, Advanced CI/CD |
| Week 6 | M13, M14, M15 | Unlocked Packages, Enterprise, Capstone |
๐ข Section 9 — The XYZ Company Story
Follow this real-world company throughout the entire course
๐ Meet XYZ Company
Throughout this entire course, we will follow XYZ Company — a polymer and silicone products manufacturer with operations in India, the USA, and Belgium. They use Salesforce for sales, customer management, and order processing.
XYZ Company has a team of 5 Salesforce professionals — 3 developers and 2 admins. They are on a journey from painful quarterly Change Set deployments to a modern DevOps pipeline. You will build their pipeline with them.
XYZ Company has a team of 5 Salesforce professionals — 3 developers and 2 admins. They are on a journey from painful quarterly Change Set deployments to a modern DevOps pipeline. You will build their pipeline with them.
✅ XYZ Company's Current State (Start of Course)
| Area | Current Situation | Problem |
|---|---|---|
| Deployment | Manual Change Sets every 3 months | Slow, scary, error-prone |
| Code storage | Only in sandboxes | No version history |
| Collaboration | 2 shared sandboxes for 3 devs | Constant conflicts and overwrites |
| Testing | Manual testing before every deploy | Inconsistent, things get missed |
| Environments | Dev sandbox ≠ production | Things break that worked in dev |
| New features | Users wait 3 months minimum | Business is frustrated |
๐ฏ XYZ Company's Target State (End of Course)
| Area | Target State | Benefit |
|---|---|---|
| Deployment | Automated pipeline, twice a week | Fast, reliable, zero fear |
| Code storage | Full Git history in GitHub | Complete audit trail |
| Collaboration | Each developer has own Scratch Org | Zero conflicts, clean merges |
| Testing | Automated on every commit | Catch bugs before production |
| Environments | All built from same Git source | Zero environment drift |
| New features | Users get features in days | Business is happy ๐ |
๐ก Key Insight
The XYZ Company transformation is not just technical — it is cultural. The team goes from fearing deployments to treating them as routine. From working in silos to collaborating seamlessly. From quarterly big-bang releases to continuous small safe releases. This is what Salesforce DevOps really delivers.
๐ Section 10 — Module 1 Quiz
Test your understanding before moving to Module 2
๐ง Module 1 Knowledge Check — 8 Questions
Q1. What does DevOps combine?
A) Design and Testing
B) Development and Operations ✅
C) Deployment and Optimization
D) Data and Operations
Q2. In source-driven development, what is the source of truth?
A) The production org
B) The sandbox
C) The Git repository ✅
D) The Change Set
Q3. What does CI stand for in CI/CD?
A) Code Integration
B) Continuous Integration ✅
C) Consistent Infrastructure
D) Cloud Implementation
Q4. Which tool is used for CI/CD automation in Salesforce?
A) Change Sets
B) Workbench
C) GitHub Actions ✅
D) Data Loader
Q5. What is the biggest problem with org-based development?
A) No version control or history ✅
B) Too many tools to learn
C) Salesforce doesn't support it
D) It costs too much
Q6. What are Scratch Orgs used for in Salesforce DevOps?
A) Long-term UAT testing
B) Production deployment
C) Isolated individual development environments ✅
D) Storing production data
Q7. What is the main advantage of deploying frequently with DevOps?
A) More work for developers
B) Smaller, safer changes that are easier to test and rollback ✅
C) Less testing required
D) No need for sandboxes
Q8. What happens in source-driven development when a declarative change is made in the org UI?
A) It is automatically committed to Git
B) It does not need to be tracked
C) You must retrieve it using CLI to sync with Git ✅
D) Change Sets handle it automatically
✅ Answer Key
B, C, B, C, A, C, B, C — Score 7-8: Ready for Module 2! Score 5-6: Re-read Sections 3 and 6. Score below 5: Re-read the full module before continuing.
๐ Module 1 Summary — Key Takeaways
Everything you learned in this module
✅ What You Learned in Module 1
- ✅ DevOps combines Development and Operations into one automated, collaborative process
- ✅ Salesforce DevOps replaces manual Change Sets with automated, version-controlled pipelines
- ✅ The 5 biggest problems without DevOps: no version history, overwrites, deployment fear, unknown org state, environment drift
- ✅ Source-driven development means Git is the source of truth — not the org
- ✅ The DevOps lifecycle: Plan → Code → Build → Test → Merge → Deploy → Release → Monitor
- ✅ CI = automatically validate and test on every push. CD = automatically deploy on every merge
- ✅ The Salesforce DevOps toolchain: VS Code, Git, GitHub, SF CLI, Scratch Orgs, GitHub Actions
๐ค Module 1 One-Line Summary
"Salesforce DevOps replaces manual, fear-driven quarterly deployments with automated, version-controlled continuous delivery — using Git as the source of truth, Scratch Orgs for development, and CI/CD pipelines for automatic testing and deployment."
➡️ Next: Module 2 — Environments & Sandboxes
Learn all 4 sandbox types, refresh strategies, seeding, and how to build a proper environment strategy for your team
๐ Enjoying This Free Course?
Share it with your Salesforce community — every share helps one more developer learn DevOps for free.
All Free Resources → 75 DevOps Q&As →