What does it take to maintain an optimized DevOps pipeline in a Salesforce ecosystem full of slow tests, fragile deployments, and sprawling codebases? According to Pablo Gonzalez, it starts with clean code.
In our latest webinar, Clean Code, Real DevOps, Pablo Gonzalez—Director of Product Management and Research at AutoRABIT and author of Clean Apex Code—delivered a sharp, practical session on why clean architecture is more than just technical hygiene. It’s the foundation for scalable DevOps in Salesforce.
Clean Code: The Missing DevOps Enabler
Salesforce teams talk a lot about CI/CD, but few experience it the way it’s meant to be: fast, automated, and continuous.
Why? According to Pablo, the problem isn’t tooling. It’s code. Specifically, unclean codebases that lead to long test cycles and brittle pipelines.
To make continuous integration work in practice, developers need to:
- Deploy in-progress work multiple times a day
- Test features in combination with others’ work
- Run tests fast enough that this isn’t a productivity tax
But when unit tests take 45+ minutes to run—a reality in many Salesforce orgs—none of that happens. Developers batch work, avoid tests, and continuous integration becomes a myth.
The Three Enablers of Real CI/CD in Salesforce
Pablo outlined three pillars that teams need to practice real DevOps:
1. Clean Code
Balanced cohesion and coupling. Descriptive design. Clean code isn’t academic—it’s a performance lever.
2. Mocking the Salesforce Database
Teams must learn how to decouple tests from the database. It’s not easy, but it’s transformative—cutting test times by over 50% in many cases.
3. Modular Design
Without clear boundaries in your codebase, mocking is impossible and tests become brittle. Modular design is the secret to fast, maintainable, scalable testing.
As Pablo put it, this is a knowledge gap, not a tooling gap. Tools like AutoRABIT help automate DevOps workflows—but teams also need the know-how to build testable, modular systems.
Enter AWAF: A Modern Framework for Apex
To bridge this gap, Pablo introduced the Apex Well-Architected Framework (AWAF)—a flexible approach to structuring Apex code for the real world.
Unlike legacy frameworks like the FFLIB, AWAF is built on principles, not prescriptions. It emphasizes thinking over templates, allowing teams to tailor their architecture based on:
- Org size and complexity
- Business domain ownership
- Functional boundaries
Two orgs using AWAF may look completely different—but they’ll feel the same. That’s by design.
From Classes to Cohesion: Rethinking Apex Structure
One of AWAF’s core ideas is to move beyond the massive “god classes” of old. Teams should:
- Organize by use case or business unit, not object
- Leverage Salesforce DX folders to group cohesive assets—Apex classes, components, metadata, and more
- Model business logic as plain-English classes that reflect what the business actually wants
This structure increases cohesion, makes tests faster and easier to write, and reduces merge conflicts. It’s also more readable. Developers can actually trace the logic behind a requirement without digging through a jungle of unrelated code.
Business Logic Deserves Its Own Layer
Apex doesn’t clearly separate business logic from platform infrastructure. But it should.
Business logic—what the business actually cares about—should be modeled independently from DML operations, governor limit workarounds, and retry logic.
By creating “core” classes that reflect business intent, developers can keep critical logic clean, composable, and testable. Infrastructure logic wraps around it—but doesn’t pollute it.
Beyond FFLIB: Why AWAF Takes a Different Path
While FFLIB was foundational to the ecosystem, it falls short in a few areas:
- Encourages rigid layering without critical thinking
- Leads to bloated service and selector classes
- Doesn’t scale well across complex orgs with shared objects
AWAF offers an alternative: Think in terms of coupling and cohesion, not layers for their own sake. Don’t ask, “What does the framework say?” Ask, “What makes this logic testable, maintainable, and easy to reason about?”
Selector Classes: Overengineered and Overrated?
While selector classes aim to enforce query consistency, in practice they:
- Become dumping grounds for one-off queries
- Create friction for fast iteration
- Add risk via merge conflicts
Instead, use general-purpose query builders—lighter, more flexible, and easier to mock in tests.
Real DevOps Starts in Your Codebase
You can’t automate your way out of a bad codebase. True DevOps—real, continuous integration and delivery—demands intentional design.
Tools matter. But structure matters more.
If your tests are slow, your deployments are brittle, and your teams are frustrated, don’t just look at pipelines. Look at your code.
Want to go deeper? Check out Pablo’s book, Clean Apex Code. You can also watch the full on-demand recording of the webinar to learn more about these points.
Because real DevOps doesn’t start in your CI tool—it starts in your IDE.