0

Every time I switch the source for my project (between sandboxes or between production and a sandbox) it defaults to "Work Online", and I need to remember to switch that or else it starts deploying things willy nilly.

I'm using version control, so I want to be in control of what's on the server and what's not. I think I may have accidentally saved something to my production org because I didn't remember to uncheck that (there's a deployment with a random hash name that says I deployed it).

Is there a way to make it default to working offline?

|improve this question
  • You should have a separate project for each org. Changing the source for a specific project is a bad idea. – Adrian Larson♦ Mar 12 '18 at 16:06
  • @AdrianLarson wait, really? How do you handle version control if you use a different project for each feature, dev, staging, and prod? – Nathan Hinchey Mar 12 '18 at 16:10
  • Each org should also be a separate repo. Not per feature, per instance. – Adrian Larson♦ Mar 12 '18 at 16:11
  • So your production org should be a separate repo from the sandbox where you test things for production? – Nathan Hinchey Mar 12 '18 at 16:13
  • Yes absolutely. See my answer below. I will be clearing these comments out shortly since they are reflected in my answer. – Adrian Larson♦ Mar 12 '18 at 16:18
0

The way we typically manage this flow as consultants (at least in my experience) is to have one repository/project per org. You should never change the source org for any of your projects locally.

When using the Force.com IDE to manage multiple instances, I use a naming convention that indicates production/sandbox, client, and sandbox name. What that looks like for me is something like:

  • Production - MyClient1
  • Production - MyClient2
  • Sandbox - MyClient1 (adrian)
  • Sandbox - MyClient1 (dev)
  • Sandbox - MyClient1 (staging)
  • Sandbox - MyClient2 (asdf)
  • Sandbox - MyClient2 (staging)

Your version control will then have a detailed view of your development flow. You will see very granular changes in dev, then hopefully some bigger chunks and some reactive in staging, and ideally only complete feature deployments in each commit to your production repository.

|improve this answer
  • So to get changes from dev to staging, you merge from the one repo into the other? – Nathan Hinchey Mar 12 '18 at 16:46
  • Yeah that's definitely the direction DX is headed. For us it was usually a cycle of deploy -> pull down locally -> commit. You don't need it to be source driven for this model to work, it just lessens friction. – Adrian Larson♦ Mar 12 '18 at 16:53

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.