Sign Up ›

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Dan Olson 5Dan Olson 5 

SFDC Integration with custom applications: How to create sensible development environments

We have five developers working on integrating a Salesforce installation with a custom app we've built. We're using Canvas for a number of things, including a custom quoting tool. Each developer has a Developer Edition account, and our org has one production and one sandbox instance. Prod/Sandbox are being configured by an administrator who is adding custom objects, fields, and relationships that are needed for our org's sales process.

Unable to keep up with the pace of schema (metadata) changes happening on the Production/Sandbox environments, the five developers have had to abandon their Developer Edition accounts and use the Sandbox as a shared development environment. Part of the integration involves keeping data in sync between the database that our custom application uses, and the database our SFDC account uses. The problem we have now is that five developers share an SFDC dataset, but have different local datasets for the custom application data. We need to reference data in SFDC in the database for our custom application, so naturally, we constantly run into issues where the references to SFDC data only exist in the local DB of one developer, causing problems for the other four.

One solution would be to share a database for the custom application's data as well. This would be less than ideal, since as it's a development environment, the data is often erased and regenerated. Any need by one developer to do this would cause issues for four others.

I mentioned we use Canvas for a number of integrations. Currently, to enable development, we configure the canvas app to point at https://localhost. This means the five developers are the only ones who can view or demo the integrations. We could change it to point at our custom application's staging environment, but that would mean the developers would have to deploy every minor change to the custom application to staging in order to test them.

I can't imagine we're the first organization to run into these issues. How do others deal with them?
Jason Curtis NBSFDGJason Curtis NBSFDG
Dan, this is a big challenge for any organzation doing serious devleopment on the platform (and an area that Salesforce can improve upon). Most ISV's developing applications are using a method of Dev environments, ANT integration tool, a repository of some type (we use TFS) and a continous integration org. But everyone's situation is a little different.

First place to start is the Development Lifecycle Guide, it goes into the differences between Sandbox/Dev org development, essential reading if you haven't alreayd: http://www.salesforce.com/us/developer/docs/dev_lifecycle/salesforce_development_lifecycle.pdf

And then when you are ready to go forward you'll need the Force.com Migration Tool Guide: http://www.salesforce.com/us/developer/docs/daas/salesforce_migration_guide.pdf

Also, one company I've been looking into Techsophy has a product called AutoRabit (http://www.autorabit.com/) has a product that handles a lot of this, plus testing and data migration.

And the partner community (partners.salesforce.com) is another excellent resource. One of the member's there recently wrote up a nice blog post on development management tools for Salesforce: http://www.nimbleams.com/blog/2014/8/17/gus-the-atlassian-way/

Good luck!
Michael SampsonMichael Sampson
Do most companies pay for more than one sandbox so that each developer can have their own? 

The Force.com migration tool doesn't seem to work well with the free developer accounts. The paid for sandbox has paid for packages that don't exist in the free developer accounts. 

You can't use change sets because the free developer accounts are not link to the paid for production and sandbox accounts. 
Jason Curtis NBSFDGJason Curtis NBSFDG
Basically there are two different paradigms, if you are developing managed packages then you’ll be using dev orgs, if you are developing an application for one specific customer, than you’ll be using sandboxes (in one of the many flavors that they are offered in). And I do think most orgs will have multiple sandboxes if they are trying to keep developers from stepping on each other’s toes. Here is a pretty good/short overview: http://www.soliantconsulting.com/blog/2013/03/salesforcecomforcecom-team-development Also, if you aren’t a partner, it is easy to sign up (not so easy to get a formal agreement, but that comes later) and then you’ll be able to create as many dev orgs as you need.