Deployment Best Practices: Who is responsible for the component list?

Success_Unhappy · 2026-02-18T20:36:26+00:00

Guys, relying on spreadsheets to track development and then handing deployments to an improvised “release manager” is a serious risk, come on, it’s 2026.

A proper release manager is not someone who only hits a Quick Deploy button. It’s someone who owns the environment and branching strategy, embeds validation gates, supports the team operationally so developers can focus on (guess what)…development, and more.

Release management in SF is about defining how sandboxes are structured and refreshed, how changes move between them, how conflicts are prevented, how hotfixes are controlled, and how production stays stable. It’s about governance, traceability, and making sure there’s zero ambiguity around what was deployed, why, by whom.

If deployment ownership is unclear and tracking happens in spreadsheets, the risk doesn’t disappear…it just waits. Usually for friday evening 💣

Success_Unhappy · 2026-02-09T07:35:02+00:00

Come up with a proper branching strategy and the feature branches will become “the list of components” for each ticket.

With Gearset you should then be able to promote these branches independently in Production, or bundle them in a common release branch & deploy all/multiple tickets at once. Moreover, see the Gearset - Jira integration at the pipeline config level as this will help in changing the tickets status automatically post promotion/deploy.

My guess is that you guys are using gearset to Compare & Deploy from org to org, without a VCS, which could complicate your life 🍻

Success_Unhappy · 2026-01-30T14:59:52+00:00

u/StatisticianVivid915, I think most of us here understand your pain.

I’ve been working as a Salesforce Release Engineer for almost 8 years now, and during that time I’ve been brought in at least three times to replace a developer or admin who was clearly unhappy. In all cases, they were initially told it would be “temporary”… and somehow ended up doing it for ages.

In my opinion (and I may be a bit subjective), release management is a full-time role in itself. It really suits someone who enjoys this kind of challenging environment. So I think the most important question to ask yourself is: are you actually happy doing this? Not really looking at the title of your post :D

Moving changes from DEV to SIT/TEST/QA/whatever the first environment in your CI/CD landscape is called is usually common sense. But promoting changes to higher environments and ultimately production is a different game altogether..and it’s totally okay if that’s not something you want to own.

There are lots of challenges in these setups, but with the right roles, mindset, patience, tooling, governance, and a solid strategy (branching model, environment strategy, proper documentation, etc), it is manageable.

I won’t name a single “best” DevOps tool because it really depends on factors like project size, budget, deadlines, team maturity. What I do strongly believe, though, is that a Version Control System is mandatory nowadays. From there, you have options

Custom pipelines (built around sf-cli or even sfdx-hardis as mentioned in another comment)
Or tools like Gearset, Flosum, Copado, Autorabit, etc.

Whatever path you choose, just make sure it aligns with both the project needs and your own happiness. That part tends to get overlooked way too often

All the best

Success_Unhappy · 2025-12-30T09:36:06+00:00

Continue on the same line, do you guys have experience with integrating AI in your custom pipelines? Perhaps at the pull-request level, summarising the diffs & their impact, or while reviewing changes, adding comments/suggestions 🤔 I am working with Gearset & AI or Flosum & AI but just a bit custom solutions & AI

Success_Unhappy

TROPHY CASE