3

We are currently in the process of developing what will be the next big release of our main Salesforce app. Right now our sandbox situation is a mess. We have 7 different sandboxes which are being used for various reasons. Several are purely used for "experimental" type of development. Some are for very specific types of development. One is a purely configuration sandbox used as a backup for production. One is meant to be a picture of what our environment will look like after our upcoming release.

As it is today our "main" sandbox - which is meant to be a picture of what our production will be after our next release - is not really a perfect picture of that. That is because some of our developers thought it would be a good idea to do development directly into production because it was needed immediately, and some of that development will also be part of our upcoming release, some will not. Some of that is considered "temporary" and will be eliminated with the new release. Some of it will be incorporated into the new release. And to make it worse, that new development was not put into our "main" sandbox. There will need to be further "temporary" development between now and the release of our upcoming new version.

So, my strategy for cleaning up (and regulating) our sandbox situation will be this :

  • keeping the "experimental" development sandboxes. They're not hurting anything because any development that gets done there will inevitably be put into the "main" sandbox

  • creating a "Day To Day" sandbox which will always mirror the current production. Developers will be able to do any kind of development which will be needed immediately. That development may or may not be included in the upcoming release.

  • using a "New Release" sandbox. This will always be an exact indication of what our production will look like at the time of our new release

Is this the proper approach to this all ? Does anybody have any opinions or advice on this ? Do you see any potential problems with it ? Is there a better approach ? It seems like the "safest" approach, but I'm not sure if it is the best or most efficient one. I have other concerns but I won't go into it right now just because I don't want this post to get too confusing. (although it's probably too late for that)

Thank you for any advice or feedback you can give.

1

I have a similar situation where I have scattered development across 2 production orgs, 2 sandboxes, and 5 Developer orgs. I am in the process of finalizing our app as a managed package, and it's taking some time to get a "clean" configuration to start from. The problem arose because the app is designed to be used for different orgs with each org having some slight customization, and development was made piecemeal for different customers. On top of that, we've implemented development on-the-fly. Now I am compiling all the customizations across all the orgs into one org. Additionally, I (am trying to) use the same Apex Classes among my orgs, but I develop the classes at different speeds. So, I am trying to compile ALL the versions of my Classes into single, all-encompassing versions

I support your idea, and I am trying to doing something in similar fashion.

Some things that I'm trying to do also:

  • Keep a dedicated org that houses the "final development" (i.e. "New Release"). This is where the "production" package (or Change Set) is to be housed. All other development must go into this org where it is to be "publicly" released. This org should also house the state of the current production org (in my case, my package is to be deployed on a fresh org). This way, your tests should be able to mimic exactly how they will run when deployed to production (in case you have complexity like validation rules, etc.)
  • For the other Sandboxes, have projects work on a specific sandbox. And keep a list of which sandbox is being used for each project.
  • When a project has an update for production, first have the Change Set deployed to the "New Release" sandbox. Then, deploy that same Change Set to production. This way, the "New Release" sandbox will always mimic/match/simulate the meta-data state of the Production Org.
  • This is probably obvious, but it's a lesson I'm learning the hard way: Whenever a new Apex Class or Trigger is created, require test code to be written too. I've done a good handful of projects that need a VF page to do something, and it needs to be done today. So, I write the code to do what I need it to do and hand off the (urgently needed) deliverable. But since there is so much else to do, I never get around to writing test code so the code I just wrote can be deployed to production. Three months pass, and lo, we (urgently) need the same deliverable again. Since I didn't deploy it to production, only a developer can go into Sandbox to create the new deliverable, and I have to drop everything and create the deliverable again. And there's always so much to do that I find some excuse to not write the test code and to work on something "more important". Then another 3 months rolls by, and the tests still aren't written, and I run into this scenario again.
  • For big, long projects, use the "New Release" model: Have a dedicated sandbox (or developer org) that houses the "final state" of the project. Have all development flow into this org like the "New Release" org. When you have a release version of the project, send a Change Set to the orgWide "New Release" sandbox. Test is there. If all looks good, send it to Production.
  • Regulate the Sandboxes so the only Sandbox connected to Production is the "New Release" Sandbox. This way, the "New Release" will always house the actual meta-data state of the Production org.

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.