2

There are many many threads debating Salesforce team development. One sandbox vs multiple (i.e, one per developer).

I would prefer to work in my own dev org, but I always decide against it when I remember the following scenario:

  • DEV1 works in sandbox1. He adds a call to a new method1 in the Account trigger before update handler. When all is said and done, the transaction includes 100 SOQL statements, and oh, I don't know... 6 seconds cpu time.

  • DEV2 works in sandbox2. He adds a call to a new method2 in the Account trigger before update handler. When all is said and done, the transaction includes 101 SOQL queries, and oh, I don't know... 6 seconds cpu time.

Each developer's work compiles and runs without issue. But then they merge into a shared dev sandbox, and, as now 201 SOQL queries will be run (not to mention running over the max cpu time), everything breaks.

What's the solution here? I say work in the same sandbox and communicate and plan accordingly. I can't think of a better way.

But does that scale? Can a company with 100 developers work in the same sandbox? Can they all communicate and plan accordingly? Is it practical? But if they don't.. they'll potentially hit the limits once they merge. Better work in the same sandbox and know earlier rather than later, no?

2

Ideally, everyone should be in their own org. This is why we are given a ton of developer sandboxes, and why DX allows us to create many orgs daily.

The thing you're missing is source control and continuous integration (CI). See, how it should work is like this:

Developer A creates their trigger, commits it, and then it is deployed by CI to a staging org. Developer B also commits, and CI tries to deploy. With proper unit tests, deployment fails, so B can't commit. At this point, A and B need to coordinate efforts to get their tests passing.

At no point should failing code make it to QA, because the unit tests should pass before CI allows it.

If you are not currently using DX, you should learn about it, set up a repository, and start using it. Doing anything less will often result in lost code and productivity.

  • Thanks, Brian. I appreciate your answer. I use source control & continuous integration, absolutely. And I do agree that no failing code should ever make it to QA. My qualm is in Developer B writing all that code not realizing that it's destined to fail. Were A and B working in the same sandbox, their conflict would be caught much earlier in the dev process, and they could work together earlier to resolve it. So in a nutshell, if devs (all working in the same sandbox) are not conflicting with each other, then no problem. If they are conflicting with each other, they'll know earlier. No? – David Oct 26 '17 at 2:37
  • 1
    @David The possibility of knowing earlier is not worth the price. What's more important: possibly learning that you violated a governor limit, or possibly losing weeks worth of code because of an accidental overwrite? Also, I would argue that any developer that writes a trigger that is using 67% of available resources by itself is simply irresponsible. I had a network of 12 triggers that only used 49 queries, regardless of which object initiated the transaction stack. Learning to write lean code is a requirement of being a successful developer. – sfdcfox Oct 26 '17 at 2:54
  • Thanks, Brian. I can't argue with any of that. Though in my scenario, the code is safe, as both Devs A and B have their own Git branch off of master. Of course, as they are working in the same sandbox, their respective branches obviously don't reflect exactly what's in the org at any given time. The key is in only committing the lines they've changed themselves. All that said, you're right. Code smarter and stop worrying. Thanks very much. And with that, I accept your answer and add to your.. wow, that's a lot of points. – David Oct 26 '17 at 3:12
0

Your scenario when 2 Dev will conflict in the total number of queries is an edge case that may be prevented by having a single Dev sandbox. That said, there are many other conflicts that could pop up when 2 or more devs are working on the same Sandbox.

Usually, a work in progress means "not working code/application". If you are alone on the sandbox, you are the only one affected that. If more developers are on the same Sandbox, all of them will be stuck in a broken application until the "work in progress" is done.

In my experience, change in UI (HTML, Javascript, CSS, etc) is one of the most common cases where a misplaced ";" will break the application and stop all other developers while it's fixed.

Under no circumstance, a team of developers should be stopped because 1 developer is working on something that breaks the application for a while.

Edge scenarios as the one you suggest (combined limit of SOQL queries) should be handled on a case by case at the integration stage, as said by sfdcfox in his answer above.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.