Working with multiple Developer Editions

By Sandeep Bhanot | Published: February 24, 2011

I don't know about you, but I often work in multiple Developer Edition (DE) instances of Force.com. I might be developing a customer prototype in one, using another for an upcoming webinar etc. It is therefore important for me to manage all the different DE Orgs efficiently. To that end, over time I have developed a small checklist of configuration changes that I make to each new DE Org that I sign-up for. I thought that this list might be helpful for some of the Force.com developers out there and so here goes.

  1. Keeping track of my multiple logins across all the different DE Orgs is probably the most vexing problem for me. There are of course many different ways to address this issue. Having a consistent and easy-to-remember naming convention for all usernames/pwds, using OS/Browser specific tools like Trapdoor and 1Password for Macs and RoboForm for Windows to name a few. I have my own solution. I simply bookmark each new DE Org as such - https://login.salesforce.com/?un=<URL Encoded Username Name>&pw=<Password> – and label the bookmark appropriately (e.g 'Spring 11 Webinar'). That way, I don't have to remember my different logins and each login is only a click away.
  2. Most of my development typically involves testing with multiple users (to test/simulate different User Roles/Profiles/Privileges etc). Once I create any additional test user and login in for the first time as that user, I make sure to 'Grant login access to your administrator' (Setup–>My Personal Information–>Grant Login Access). That way, I can easily switch between different users without having to login and logout every time and I don't have to remember yet another set of login credentials.
  3. I enable 'Development Mode' for my user record (Setup–>My Personal Information–>Personal Information). This allows me to create and edit Visualforce pages via the browser.
  4. When I'm developing in a DE Org, I don't like to get the daily Chatter email digests (or even Chatter email notifications). I typically disable all Chatter email in my DE org via Setup–>Personal Setup–>My Chatter Settings–>Chatter Email Settings. 
  5. You might also want to add your corporate IP range to the Trusted IP Ranges for the Org (Setup–>Security Controls–>Network Access) to avoid getting activation link emails. If you plan on developing from outside your corporate firewall, you can also edit your User Profile (typically 'System Administrator') and set the Trusted IP Range to '0.0.0.0 – 255.255.255.255'. 
  6. I set the User Password policy (Setup–>Security Controls–>Password Policies) to never expire. That saves me from having to think of new passwords every couple of months.

 

Please remember that the above tips are only applicable for a development/prototyping environment such as a DE Org. The security related configuration changes in particular (never expiring passwords, trusting all IP addresses etc.) should never be done in a Production Org since they violate security best practices and possibly your company's security policies. In addition, even if you only apply these tips to a DE Org, make sure that you don't store any sensitive data in that Org (which you shouldn't be doing anyway!).

Any other interesting DE Org tips and tricks you'd like to share with the community? Just comment on this post.

tagged Bookmark the permalink. Trackbacks are closed, but you can post a comment.
  • http://www.infowelders.com Nick Hamm

    Very good tips, Sandeep. We use multiple DE and demo orgs company wide, so we have also created a custom object in our production instance to track these logins and pws, is it ok for demo, description of what the org contains, as well as a link that will take you to the login page with the user/pw pre-populated. We’ve found this is very helpful for keeping track of what you have, especially when you may need to demo a piece of functionality you worked on years ago on short notice.

  • http://www.redargyle.com Tom Patros

    I like to use a common email address for all my development orgs (e.g. sf.dev@redargyle.com) and make the username specific to the app we’re going to build in that org (e.g. sf.amazingapp1@redargyle.com). This has the nice effect of not consuming your personally-named email address as an SF username (which has to be unique) and also funneling all system email communication through a common email address, which could be an alias for your development team.

  • http://www.thefurygroup.com Paul K Fury

    We setup a Google apps account (gmail works too) just for this. Google allows you to take your email address before the @ and add +anything. So you can have myname+clientname@gmail.com That gives you a unique email address AND you can easily create folders and filters to auto-file or forward the emails all from one account.
    This is also a nice trick by the way when signing up for newsletters or webforms. If they sell your email address, it is easy to tell who did it and filter out emails to that address.

  • http://www.awfulcode.com Ryan G

    Using My Domain can let you login to multiple developer editions at the same time.

  • http://quintonwall.com Quinton Wall

    great topic, and great comments.

  • Sandeep

    Thanks for the great tips guys. Keep em coming….

  • http://www.cirruscg.com Ryan Huff

    Ditto the custom “Password” object with the username, password and automatic login link. We also use My Domains so you can log in to multiple at the same time — with the side benefit that most password managers will save that username for that specific subdomain, so you get 1-click login from the salesforce login page too.
    But our biggest time saver: an Ant script that clears out all of the custom fields, sample Apex and VF code, etc. Brings a DE org back to a clean state.

  • http://profile.typepad.com/6p01156ff0213d970c Sandeep Bhanot

    Ryan – the Ant script sounds very cool and is something that would be very useful for some folks. Any chance I could convince you to share it with the community?

  • http://fulcrumcollaborations.com John D

    Sandeep,
    Excellent topic.
    Do you have an thoughts surrounding best practices for Force.com development and SCM’s such as GIT or SVN??
    I have found certain objects seem to work great when they are controlled by an SCM (i.e. triggers and classes) but other objects seem to cause trouble (i.e. sites and profiles). The trouble comes from the Force.com IDE trying to load these objects into a fresh clean ORG when the code is checked out from a SCM.
    I have read articles like http://wiki.developerforce.com/index.php/Checkout_Force.com_Metadata_From_Subversion but they don’t quite address this subject matter. In the case of the SVN article here, they actually advocate performing an SVN Export to get the code locally as oppose to a standard SVN Checkout.
    I realize that “best practice SCM” topic is not the necessarily the main focus with this article, but it is something that I would love to get more information and tips on.
    And Ryan Huff, I second Sandeep’s request for that ANT script. That really does sound very useful. Any chance that we could get a copy of it???
    Thanks for the help.
    Cheers!

  • Chris Bellamy

    I use LastPass, a free (and very secure) web-based password management system. It allows you to label each username/password combination, and when you go to login.salesforce.com, you can pick the logins from a list.