You need to sign in to do that
Don't have an account?

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?
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?
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!
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.