Environment specific variables in SalesForce

If you are developing web-service callouts in development or sandbox and moving them to production, you have to manually change the properties of the out-bound webservices.  For example, you are developing a callout that updates the customer information to an external system when a new customer record is created in SalesForce in Sandbox.  After completing the testing of the callout, you would want to move your apex code to production org.  But, the end point, authentication details of the outbound service will be different than the one in test environments. 

Unfortunately, SalesForce doesn't provide the flexibility of configuration/property files that Java provides.  Luckily SalesForce now provides Custom Label functionality that can be used for this purpose.  

I normally define the endpoints, authentication details as custom labels in sandbox and production orgs.  The advantage is, 

• the apex classes need not change from sandbox to production.  
• The test cases run perfectly fine in sandbox and production orgs.  
• When there is a change in environment specific property value, you need not create a change-set or migrate your code.  
• Better Apex code development

To create custom labels

Setup->Create->Custom Labels

There are other way of externalizing the properties 

• Create Properties__C object and store the properties.  The disadvantage of this approach is you are maintaining an object for properties and issuing SOQL queries to retrieve the properties.  
• Using URLRewrite:  While this solves the purpose like the one mentioned above.  It involves find the parsing various formats of SalesForce's representation of the URLs, i.e.. different urls for internal users, portal users and sites users and you have to understand them
• Page References:  Using page reference to get the url is limited by developing VF pages and would not address the purpose of this discussion
• Get Organization ID:  Getting the org. id will also solve the purpose and you can determine based on the org. id which property to use.  But this can lead to issues when you have more than 2 orgs and also multiple outbound web-service environments