5

I'm doing a big deployment (for me anyway) of 6 custom objects and a hundred or so custom fields.

I'm now starting to build the outbound change set but I'm worried that I may forget to add some changes either due to errors using the interface, bad documentation etc.

What is the best way of ensuring that everything that is meant to be uploaded is and nothing that isn't isn't.

At the moment I'm looking at a brute force approach but I'm sure that there must be a more elegant solution

Improve this question
0

8 Answers 8

Reset to default
3

If your package is the only new development in the Sandbox then simply using Eclipse or another IDE to pull down the content of both orgs and running a file-by-file diff will help you identify everything that needs to be added.

When it comes to adding everything to the change set, I often find the best way to do it is to add all the Visualforce pages first, as the dependency resolver will then pull in all Apps, Tabs, Classes, Components, Static Resources, Custom Settings, Custom Objects, Custom Fields etc. that need to be in there.

Typically after doing that the only other pieces I need to add are things like triggers etc., and of course, test classes.

Improve this answer
2

Here some thoughts from my SF experience. In order to make sure that all components are in place you should have the starting point for comparison. Usually, such a starting point is the documentation of the project or some art of ticket system where all edited by developer components/classes/pages etc are saved. No matter how produced deployment (SF Change Sets, Migration Tool etc.) - you will have to check everything manually by yourself or write the helper programm for that. To make sure that the deployment works well - it makes sense to run the "validate only" deployment first. Hope this helps. (understanding deploy)

Improve this answer
3
  • Good points :) From my point of view the migration tool (wiki.developerforce.com/page/Migration_Tool_Guide) is great for being able to see everything in one place and repeat the same deployment or make incremental changes. It also is a record of what you deployed. However there is a much steeper learning curve than you have with change sets, and for many small orgs it might be overkill.
    – Doug B
    Commented May 31, 2013 at 10:08
  • Thanks. It's the "check everything manually by yourself" that for me is the really difficult bit (the rest of the tools are beyond our capability - 5 man company). Do you check on a category basis (i.e. custom object, custom field), by object, by formula or workflow logic. And for the lazy amongst us - how do you identify any un-documented changes that need to be migrated? (and if all this sounds very amateur it is. Learning by doing has some benefits but also costs)
    – Denis Oakley
    Commented May 31, 2013 at 11:51
  • @DenisOakley There is no undocumented changes in my company - it is strongly prohibited (very easy to check who did that). Yes, i check on category basis (is more convenient). In general, I can recommend this article (as the checklist for deployment): Change Sets Best Practices and Change Sets Implementation Tips
    – Sergej Utko
    Commented May 31, 2013 at 12:02
2

You can also create an unmanaged package and add all required components to this package. It will automatically pull any dependent components to the package. Then use eclipse to deploy.

Improve this answer
1
  • Thanks. Eclipse is overkill for me - but I guess that I could then go in and see a complete change list that I could then check my change set against?
    – Denis Oakley
    Commented May 31, 2013 at 11:42
1

You could use SpringTool to achieve your goal. SpringTool helps you identify all the metadata that was changed. You can use filters to only see changes made by a specific user or since a specific date or just for some type of metadata (objects, fields, trigger, VF pages, etc.). The free version contains the "Package Assistant" feature that should answer your need. You can then generate and download the package.xml file and use it with ant for instance. Or with a higher plan (starter for instance) you could even automate this and deploy your packag with SpringTool with a few clicks.

Improve this answer
0

A quick way to get a diff is to build an Eclipse project from your sandbox with all metadata components selected and then start a deploy against Production. Eclipse will show you which metadata files have changed or are new. This is limited because it won't single out a custom field but only shows you that its sObject has changed.

You can also use Eclipse to diff the entire metadata set and thus get a line-by-line comparison. This may be the brute force you're referring to. Combining this will using the dependency-checker in Change Sets would cover the changes well.

Improve this answer
0

In your change set add your custom objects. then add your fields. On the add fields page, sort by type and find your object(s). then you can add all the fields for the object at once.

Add classes triggers etc.

In you change set be sure to add the system administrator profile (and others ) such that security on the new fields will be set and visible for that profile.

Improve this answer
0

I know old post bumped by Community so going to add my two cents

There is a point when building the changeset that the add dependencies button becomes useless as it will pul in existing objects etc that are not really new and can contain hundreds of results. This usually becomes true once you add classes.

With that said I usually build it in this order:

  1. Add the custom objects
  2. Click the view / add dependencies button 2a. Add all the items found in #2
  3. Add the tabs (since they are not added in #2
  4. Add all VF Pages 4a. Check dependencies again, add appropriate results
  5. Add workflow rules, field updates, etc
  6. LAST - Add classes and triggers

You need to manage the intelligence of the Check Dependencies button by not adding code that references existing objects or all those objects / fields will be pulled in and the value of the button is greatly diminished.

Best practice would be to build the changeset as you build the objects / fields / code, that way you are less likely to miss thing.

Improve this answer
3
  • The exact order to add things in depends on the project. I personally add top level elements first, like tabs, Visualforce pages, test classes, page layouts and triggers. From there, add dependencies will make sure you don't miss fields, objects, components, links, and so on. Saving classes for last means you might miss fields. I'd rather add too much than too little. Also, I'd mention adding profiles to copy permissions for new elements.
    – sfdcfox ♦
    Commented Apr 3, 2015 at 16:59
  • @sfdcfox - Agreed, differ order for different needs. In my case if I add code that references the Opportunity in any way, I get almost 1K dependencies so i try to avoid it :) all depends on the use case i guess. If adding profiles, sometimes you may not want to add existing objects as the permission will be copied for those objects and they may have changed in the sandbox vs production. Lots to consider.......
    – Eric
    Commented Apr 3, 2015 at 17:06
  • @sfdcfox - Adding the class last you can still get the dependencies if it all works out but if it brings in a bunch of junk, adding the class first nullifies the ability to use the dependencies in any way......Just my thought process.
    – Eric
    Commented Apr 3, 2015 at 17:08
0

Eclipse, or Mavens, and pulling the files down then using Beyond Compare or something to do file by file diff'ing can be a decent way to do this.

I work for https://gearset.com where we are building a tool to automate lots of that for you. We want to make complex deployment problems simple, things like deploying just portions of a profile or complex dependencies should just work.

Gearset Deploy

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .