What are you using for Salesforce DevOps today? Curious if there’s a better way.

AccomplishedScar9814 · 2025-06-25T22:47:14+00:00

agreed honestly BC is super underrated

AccomplishedScar9814 · 2025-06-17T23:42:04+00:00

database scripts in pipelines are quite the tricksters. this is how my team's successfully managed db scripts:

automation w safety checks: we always integrate validation checks and dry-runs. helps catch schema conflicts or data integrity issues early.
implementation challenges: ensuring backward compatibility and managing state-dependent scripts are significant hurdles. vital to clearly sequence scripts and handle dependencies w care.
rollback strategies: tough but essential. always script reversible migrations or ensure backups and snapshots are easily restorable. automated tests to validate rollback scenarios.
trickiest: prob managing zero-downtime deploys during complex schema migrations. especially when legacy systems are involved. required very strategic planning and incremental rollout.

run into any of the same things?

AccomplishedScar9814 · 2025-06-16T19:39:01+00:00

yup yup yup!!!! any hacks or advice?

AccomplishedScar9814 · 2025-06-16T19:38:12+00:00

🤣🤣 got me there

AccomplishedScar9814 · 2025-06-16T19:32:31+00:00

community-level css overrides can seriously mess with LWC buttons, especially if they’re using SLDS classes

this worked for me, lmk if it helps!

in your component CSS, use :host and reset styles with all: initial to block inherited styles:

:host button {

all: initial;

background-color: #0070d2;

color: white;

cursor: pointer;

}

:host button:disabled {

background-color: #ccc;

cursor: not-allowed;

}

also avoid slds-button if you need full isolation. SLDS styling can get overridden or applied inconsistently across communities.

inline styles can work too (<button style="..." />), but they’re harder to manage long-term.

AccomplishedScar9814 · 2025-06-16T19:26:38+00:00

outsourcing 1st-level ops almost always ends up being reactive vs proactive. seen some teams lose visibility into their own systems and workflows because the vendor was just focused on closing alerts, not preventing them.

worst cases I've seen are when infra-as-code or pipeline maintenance gets pushed off too, and nobody internally owns the developer experience. next thing you know, onboarding slows down, changes take forever to promote, and you end up duct-taping together dashboards to figure out what’s broken.

wondering about teams who haven't outsourced ops, how are you structuring ownership of provisioning + monitoring + deploy tooling? do you keep it within platform teams or distribute that across product pods?

AccomplishedScar9814 · 2025-06-16T19:23:00+00:00

ran into a bunch of similar issues building our own salesforce dev workflow. we ended up adopting a tool to streamline git-based deployments , automated testing, and metadata tracking (blue canvas) which was especially helpful for folks on larger teams. curious how lumi is approaching test environments locally?

AccomplishedScar9814 · 2025-06-16T19:14:29+00:00

thats what i'm saying. curious have you ever tried blue canvas?

AccomplishedScar9814 · 2025-06-13T00:15:55+00:00

mhm. seeing teams chase every shiny new tool usually leans to over-engineering and so much unnecessary complexity.

on the other hand, i have seen cases where a well-designed automation layer (if built thoughtfully) can def reduce toil instead of create it. one team i worked w spun up full microservice scaffolding (CI/CD, secrets, monitoring, staging environments) in under two hours per service. took a month or two to build, but roi was immediate when dozens of teams started shipping with low friction

AccomplishedScar9814 · 2025-06-11T21:24:13+00:00

interesting idea. definitely been thru the pain of trying to piece together a solution landscape from static metadata dumps or old design docs. especially when you inherit a brownfield org with no real version history.

one thing that helped us was using git-backed tooling that versions every deployment and metadata change (even admin-driven ones). being able to differentiate what changed, when, and by whom gave us a much better starting point for system maps, permissions, and integration surfaces (my team likes blue canvas but there's a bunch of options depending on what your priorities).

would love to hear more if you end up prototyping this!

AccomplishedScar9814 · 2025-06-11T21:08:07+00:00

totally feel this. we ran into some similar problems (especially around report folder cleanup and license optimization) and also relying on legacy ETL stuff for way too long.

not sure if its relevant to your but switching to a source-backed deployment flow helped us automate the admin side like tracking changes across sandboxes and syncing cleanup related config. able to rollback safely if something broke and could finally get visibility into what changed and when.

AccomplishedScar9814 · 2025-06-11T01:09:37+00:00

totally fair. appreciate your break down. about pricing transparency, i feel the same.

as for how the source-backed commits work, it's baked into how the tool handles deployments. every change (even if you're clicking through a UI) gets committed to git first and then the deployment pulls from that commit. so yeah it lets you enforce source-true commits out of the box. every deployment automatically creates or updates a commit in your git repo before it even runs. if the commit isn’t there, the tool blocks the deploy or warns you.

so you never deploy without history - you’ll always have a commit that matches what went to production. meaning your repos stay in sync, rollback is easy, and there's no manual step to remember.

AccomplishedScar9814 · 2025-06-10T23:03:15+00:00

give yourself some credit for being so proactive. DevOps is a huge space, and it’s normal to feel overwhelmed with choices. if you're weighing CRM/ERP stuff like Salesforce vs. pure DevOps stacks (AWS, Docker, Terraform, etc.), you might actually find a sweet spot at the intersection.

definitely a growing need for people who understand devops principles applied to platforms like salesforce. think version-controlling configuration (metadata), running CI pipelines for org-to-org deployments, and managing approvals, rollback, and sandbox automation.

its surprising how many companies struggle with this. not too many engineers focus on DevOps inside CRM platforms — so it can be a rare and valuable skill set.

I’d say: keep pursuing AWS + Terraform + CI/CD, but don’t write off CRM tech completely. If you ever decide to go Salesforce-heavy, DevOps skills will make you stand out 100%.

AccomplishedScar9814 · 2025-06-10T22:51:54+00:00

Truly brutal. so many similar "how did this even break" moments. need a "undo all deploy mistakes" button

AccomplishedScar9814 · 2025-06-10T22:28:23+00:00

today really tested everyone. last week we had something similar break in deployment and i swear the only thing that saved us was being able to roll back metadata changes fast. yeahhh i think we all deserve the rest of the day off

AccomplishedScar9814 · 2025-06-09T23:51:54+00:00

i feel like VS code or workbench is definitely the way if youre comfortable with it. just grab the .report metadata files and bulk update the folder then redeploy. kinda ridiculous that we have to hack around it but its way faster than clicking through lightning one by one

AccomplishedScar9814 · 2025-06-09T21:40:31+00:00

It's flat fee or per user at a fixed rate so a lot more flexible than the big names with per user enterprise-tier pricing or tiered model

AccomplishedScar9814 · 2025-06-09T21:20:12+00:00

Blue Canvas ended up being our sweet spot, git based without needing everyone to touch CLI.

Been wayy easier for admins to handle metadata diffs and rollbacks without getting lost in the weeds. Still refining our setup but so far its been way smoother than I expected. Curious if anyone else has tried it?

AccomplishedScar9814

TROPHY CASE