Working with code within the constraints of Salesforce's workflow can be a challenge. First, you have the restriction on changing anything in production. Second, you have the requirement for 75% or greater unit test coverage. Third, you have the fact that certain metadata cannot be pushed to production through a changeset (which means the only way to sync record IDs is by re-deploying the development environment from production).
Fourth - and this is what I'd like to blog about today - you cannot delete classes from production through the Salesforce UI. The only way to delete a class from production is to download the class (and its associated metadata file) into the Eclipse IDE (which you have previously set up with the Apex add-on), change the "status" flag to "Deleted", then deploy the changed metadata file to production. And (here's the kicker)...sometimes it doesn't work because...reasons.
So let's start with the workflow of a file deletion. We'll make the assumption that the class in question is simply no longer needed. Here is the process:
Fourth - and this is what I'd like to blog about today - you cannot delete classes from production through the Salesforce UI. The only way to delete a class from production is to download the class (and its associated metadata file) into the Eclipse IDE (which you have previously set up with the Apex add-on), change the "status" flag to "Deleted", then deploy the changed metadata file to production. And (here's the kicker)...sometimes it doesn't work because...reasons.
So let's start with the workflow of a file deletion. We'll make the assumption that the class in question is simply no longer needed. Here is the process:
- On the sandbox server, comment out the body of the file and any associated test classes
- Create an "outbound changeset" that includes the altered class files
- Upload the changeset to production Salesforce
- Wait five to ten minutes for the changeset to become available in production
- On the production server, check for "inbound changesets" - the one you pushed will probably be available by now (keep trying if it isn't)
- Click the "Validate" button and the "Run default tests" option and validate
- If there are any errors in any related classes, methods, triggers, etc...you will have to go back to the sandbox and fix them before you can deploy your changes again
- Once validation has passed, you can deploy your now commented-out file
- In Eclipse, right click on "Apex" at the top of your navigation panel
- Hover over the "Force.com" menu item, then select "Refresh from server"
- After refreshing, make sure you see the commented-out file. (If you don't see the file at all, you will need to toggle the view in your Force.com -> Project Properties -> Force.com -> Project Contents by clicking "Add/Remove...")
- Now find the metadata file for your class and its related test class. They will have the same class name but end with "-meta.xml"
- Toggle the "status" on each file to "Deleted" and save
- Right-click on the metadata file and from the Force.com menu, select "Save to server"
- You will have to select the environment to save to ("production") and then provide your Salesforce credentials for each save
- On production, open up the developer console (which allows you to look at your Apex classes, but not change them) and verify that the files are, in fact, deleted
- If the files are not deleted, close Eclipse and reopen, then start again from step #9 (above)
That's it! That's all you have to do to delete an Apex class (basically, a Java class) from a Salesforce production instance. Easy, right?
Okay, not so much. But the really irksome thing is that just renaming a class requires all of the above steps. In other words, if you rename a class in sandbox, you no longer have that class in sandbox but it still exists in production. So that means that in production, you now have two classes with the same content duplicating the same work, possibly in a very destructive manner.
So to rename a class, you have to create another class with the name you want with the same content as your old class, then do steps 1 through 17 above but include your new classes in your changeset in step #3. You MUST make sure that your old classes are commented out and your new classes are working in production or it could be catastrophic to your org and you will probably be fired.
Welcome to Salesforce development!
Okay, not so much. But the really irksome thing is that just renaming a class requires all of the above steps. In other words, if you rename a class in sandbox, you no longer have that class in sandbox but it still exists in production. So that means that in production, you now have two classes with the same content duplicating the same work, possibly in a very destructive manner.
So to rename a class, you have to create another class with the name you want with the same content as your old class, then do steps 1 through 17 above but include your new classes in your changeset in step #3. You MUST make sure that your old classes are commented out and your new classes are working in production or it could be catastrophic to your org and you will probably be fired.
Welcome to Salesforce development!
Comments
Post a Comment