So I've developed a couple of Salesforce / Force.com projects but the one thing I really hate is migrating changes between orgs. Maybe I'm doing it wrong, or I'm missing tools but something just snapped today.
I'm working on a fairly easy Salesforce project, a lot of custom fields, some custom objects, couple of queue's, some assignment rules here and there. I've got 1 production org and 1 dev org. I've made some profile changes, layout changes, visualforce page changes and I've added some fields. So now the hard part, some changes are made via the IDE and some via the GUI. I want to deploy the "neat" way so I wanted to use the change sets. I've set them up and then. I don't remember all of the fields I added, I don't know all the dependencies, so I've added them all.
This all concluded in 1 big bloated change set. It gave me a couple of errors when I tried to upload it about some missing fields... So with these cryptic messages I changed over to the IDE, selected all the things I thought I needed and managed to deploy it to production.
So it's a pain to deploy changes, especially if those changes have been made between 1 - 2 months. The project isn't in source control (I know very bad working on it) but what about all those changed made via the GUI. Why can't SF tell me what the DIFFS are between my "master" or production org and Sandboxes?
I guess I'm missing all the cool kid tools/scripts, but I couldn't find any good tutorials about it. This leading to another somewhat related question. How do you set-up your development environment? I want to use the newest Eclipse, but it errors on me when I try to add the Force.com plugin, so i'm stuck with the IDE force.com provided. Which gives me errors along the lines of:
com.salesforce.ide.api.metadata.types.Metadata$JaxbAccessorF_fullName cannot be cast to com.sun.xml.bind.v2.runtime.reflect.Accessor
So, what am I missing?
Attribution to: Daniël Zwijnenburg
Possible Suggestion/Solution #1
In one sentence - you're right, deploying salesforce is a pain ... I find it frustrating that the leading SaaS product has such a poor set of deployment tools, I regularly report deployment issues to support, hopfully this wiull improve over time.
I find eclipse a much better tool then changeset, for projects. changesets are good for minor changes and quick fixes
I'd recommend the following:
1) Pick and choose the metadata in your project xml (in eclipse - force.com -> add/remove metadata objects). do you really need all the layouts? profiles? etc I'd pick all classes and triggers, common objects such as account and opportunity (unless you sure you did not touch them) and any custom objects you've built. add any related objects you've touched, and it's probably good to add reports.
2) then - refresh a sandbox from production , and run a mock deployment to it. This should highlight any manual steps you'll have to take before deploying from eclipse (SFDC deployment is imperfect - you'll have to manually create some items before or after the migration - e,g, workflow on a new custom object can only be created AFTER the object was deployed)
3) check your code coverage and test classes both in the sandbox and production and correct as needed
4) run a validate only deployment to production BEFORE your actual production
This means you should set aside somewhere between 2 to 5 days for deployment activities. Ideally you can do this while your customer's UATs the release though it's better to do so AFTER UAT (so no more code changes take place)
5) last but not least- deploy profiles using eclipse after the actual deployment, and then manually validate them between source and target org. Yes, it sounds horrible because it IS. If you have the time and skills, you can export the profiles and do a diff on unix or any other diff tool to save you staring at a screen...
Good luck - and please be sure to raise any deployment issues with SFDC support!
Guy
Attribution to: Guy Keshet
Possible Suggestion/Solution #2
One hint that we've found helpful is to go to the highest level of objects and use the "dependency" feature on the change set.
For example, if you've got apps, tabs, page layouts, objects, pages, and classes, list those. Then use the dependency to get all the fields that are referenced in the higher level things.
If you wrapped it all up in an app, that may catch it all. Then you just have to add the profiles.
Attribution to: Shane McLaughlin
Possible Suggestion/Solution #3
When you're building something you know will be deployed, start building the change set at the same time. Every change you make to metadata, add it to the change set or to some spreadsheet you're keeping of required manual changes.
Also, every time I make a new change set I mark it as "v1", since I generally get up to at least v3 before the change set can be deployed. Inevitably I've forgotten a field or something and have to go back and clone v1, add the thing I forgot to v2, and re-upload. Have your change set uploaded and validated against the target org in advance of when you want to deploy, and then deployment can go quickly and smoothly, and you can just run through your manual actions. These things all mostly apply no matter whether you're using Change Sets, Eclipse, or the migration tool.
Note that Eclipse allows for archiving of deployment and target metadata, so there is some record, admittedly not as complete as we would like. To see changes made in the UI, you can use the Setup Audit Trail log.
Attribution to: Jeremy Nottingham
Possible Suggestion/Solution #4
You aren't mad, the whole story is a bit of a mess in my opinion, although SF is working to resolve the situation from what I've seen.
If you find the Setup Audit Log in the Setup menu you'll find that SF has tracked all the changes you've made over the last 6 months or so, you can use that to more accurately piece together your change set. This should mitigate some of your issues.
I wouldn't use the latest eclipse, just stick with full package they provide as I have had issues in the past. I believe I did resolve them, but I can't recall the specifics I'm afraid.
I've also found Eclipse IDE deployment painful anyway (breakages), so the Ant based Migration Tool is a better longer term story, again however, its not straightforward - generating the package.xml for instance is not done automatically (which puts you in the situation of using Eclipse to create the package.xml file and copying it over to Ant.
To further complication there are also changes you can't migrate automatically (by any means), but that should be resolved come Spring '13 as from what I heard at Dreamforce as SF works to make everything meta data deployable.
Attribution to: Steven Herod
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/1535