ApexDeployAll with destructive changes about vim-force.com HOT 25 CLOSED

Thank you for the suggestion. Will have to think about this, as it looks pretty dangerous at first glance. Especially if the plugin does not handle all possible situations (which will be the case initially if it is implemented).
Have you considered adding a git hook to write paths of deleted resources to stage and then calling :ApexRemoveStaged on those?

from vim-force.com.

I would like for the deployment and destruction to happen all at once rather than 2 separate steps. The reason being is if some of the code changes break a class or trigger, then it will fail to deploy.

from vim-force.com.

Hi @gostrc

I have added a new command :ApexDeployDestructive.
It is a file based operation which will remove from SFDC any files which no longer exist in the local version of vim-force.com project.

Note - unlike ApexDeployAll command :ApexDeployDestructive depends on prior knowledge about current vim-force.com project. It will not remove every single file in SFDC if it simply does not exists on your local machine as this would be slow and very dangerous because other people might have added new files to SFDC since your local copy had last refresh.

Instead it checks what files used to exist in your local vim-force.com project but are no longer available locally in .vim-force.com/session.properties
FYI - every time when you call commands like ApexRefresh or ApexDeploy all files processed by these commands are recorded in session.properties.
This way we can make sure that we do not inadvertently remove from SFDC any files added by someone else and of which we have had no knowledge.

If you want to test new command you need to:

1. checkout branch DeployModifiedDestructive of vim-force.com
2. replace your tooling-force.com.jar with this one.
3. run :ApexToolingVersion. You should get "version: 0.3.1.1"

Be VERY careful when you test it and do not test against an Org with important data/files.

You may want to run :ApexPrintChanged before :ApexDeployDestructive to make sure that you know what files will be deployed and what files will be be deleted.

from vim-force.com.

Thanks for the update!
This seems really promising, I will try to test it in a sandbox when I have time.

1. I checked out your changes in the branch DeployModifiedDestructive and they made sense to me.
2. Is there a branch that includes the changes for the tooling-force.com.jar file you linked? I'm interested in how this is implemented in the command line tool. The reason is that we could potentially make this into an easy, vim agnostic method of salesforce deployments from the command line. Imagine people that use git or any other vcs as their source of truth, something like deploy-tool <destination> would be gobbled up by those people.

dangerous command

This is only a dangerous command when you treat what's on the server as the source of truth, but if everyone's workflow is centered around deploying from git and treating git as the source of truth, this shouldn't be an issue imo.

refresh before deploying destructive changes

So the deployment workflow to production using git would then look like:

1. do an apex refresh from the server to get the latest list of files on the master/production branch
2. clean up any changes produced by the refresh, (e.g. we made it a policy to include new lines at the end of our source files in git, but salesforce truncates these when we refresh from the server, so each time this happens, we need to git checkout those files or git clean -df)
3. merge the development/sandbox branch into master/production
4. open up vim in master
5. type in :ApexPrintChanged and confirm the changes
6. type in :DeployModifiedDestructive to do the destructive deployment

In my opinion steps 1 and 2 should be unnecessary for the mentioned git flow, but I don't want to sound ungrateful This is already way more than I expected so thank you :)

from vim-force.com.

Thank you for the feedback.

I think I see what you mean now.
Your source of truth is your git repository and you do not really care about the state of SFDC as long as it originated from git, right?

If that is the case, then next step would probably be a command like DeployAllReallyVeryDestructive

The process then would look like so:

1. using local package.xml retrieve all metadata matching this package.xml in a temp folder - this will give us a list of files
2. Compare local project files with the list obtained on step 1. and note files that exist in temp but do not exist in local project
3. run DeployAll to push all local files to SFDC
4. delete all files noted on step 2 from SFDC

Is this what you meant?

PS: neither metadata nor tooling API support both deploy and delete in one go, hence multi step process above.

from vim-force.com.

one more thing - there was a typo in a method call, please pull branch DeployModifiedDestructive again, I had to make a small update in apexTooling.vim

from vim-force.com.

Your source of truth is your git repository

correct

The process then would look like so: ... Is this what you meant?

that's almost correct.
There is a class of issues with the mentioned flow demonstrated in the following scenario:

1. Trigger A has been renamed to Trigger B
2. We run deployall, and that deploys Trigger B
3. at this point in time, Trigger A and Trigger B exist in the org which might cause tests to fail, other uncertain behavior in live code, and as a result the deployment will probably fail because the tests failed to validate during the deployment

I'm wondering if we could detect the files that changed and have a 2 step process for deletion.

1. during the deploy all step we would either disable these triggers/classes in the metadata (though not sure if they still have to be valid) or create blank container files for them with empty bodies so we clear out the logic so we can deploy.
2. delete the inactived files or just delete the shell files we created in step 1

I'm not sure if we can inactivate all metadata objects but I think we can create empty shells for those metadata objects (e.g. classes, triggers, components, visualforce pages)

from vim-force.com.

The “empty shells” approach sounds like it may actually work in many cases if we apply it for code type files only. Deploying empty files for things like .object, .labels or .layout will have zero effect on the end result (that's the way metadata API works).

I am not sure what will happen if empty classes are deployed in Prod since they will not be covered by unit tests.
Will this just slightly reduce code coverage and deployment still succeed or will SFDC complain about 0% coverage for such classes and fail the deployment?

from vim-force.com.

I am not sure what will happen if empty classes are deployed in Prod since they will not be covered by unit tests.

I tested and here are my results:

I created an empty class and trigger. I checked the code coverage in the Developer Console, and the files I created where not listed.

I then created a changeset and validated it in production, and it said: "validate: succeeded" so I'm assuming it wont lower the code coverage and it will deploy just fine since there is no code in it.

from vim-force.com.

There is now a new command :ApexDeployAllDestructive
In addition to DeployAll it deploys "empty shells" of files which need to be deleted and if deploy is successful then next step also tries to perform deletions.

In order to detect what files need to be deleted we use project's package.xml and retrieve list of files which is covered by the package.xml. All files retrieved from SFDC Org that do not exist in the local project are scheduled for deletion.

If you want to test new command you need to:

1. checkout branch DeployModifiedDestructive of vim-force.com
2. replace your tooling-force.com.jar with this one.
3. run :ApexToolingVersion. You should get "version: 0.3.1.2"

from vim-force.com.

FYI - there was a bug in the uploaded jar, so I have updated it and if you have already downloaded version in step 2 above, please download again (link is updated)

from vim-force.com.

@neowit hah, I haven't tried it out, but I will pretty soon since I have a deployment that involves deleting code :) I'll definitely try to deploy to another sandbox first though.

from vim-force.com.

@neowit is the code the most recent on: https://github.com/neowit/tooling-force.com ? I would like to read the code before destructive deploying since I am probably the first one to use it in production :)

from vim-force.com.

yes, master branch of https://github.com/neowit/tooling-force.com is the current version with all changes included in the linked above jar.

I am probably the first one to use it in production :)

yes you are, and I seriously do not recommend to test it anywhere near real production.

from vim-force.com.

I checked out the branch DeployModifiedDestructive and tried to autocomplete ApexDeploy and I got options for both ApexDeployDestructive and ApexDeployAllDestructive, is this an issue? I noticed that ApexDeployAllDestructive does not exist in the help file associated. If we had to choose, I would prefer ApexDeployAllDestructive since it makes it explicit that it's deploying everything.

edit: nevermind, I read the code, the none "all" is the modified version and the "all" version does the full destructive deployment.

edit2: Hmm, I think ApexDeployAllDestructive should be mentioned in the doc.

from vim-force.com.

tried to autocomplete ApexDeploy and I got options for both ApexDeployDestructive
and ApexDeployAllDestructive, is this an issue?

That's how vim displays commands for autocomplete - everything which starts from already entered character sequence is offered. You may want to check out :help wildmode and :help wildmenu

If we had to choose, I would prefer ApexDeployAllDestructive since it makes it explicit that it's    
deploying everything.

For me it is the opposite. I have a different workflow and can see myself using ApexDeployDestructive much more frequently than ApexDeployAllDestructive.
If presence of both options bothers you then you could map a different command (e.g. MyDeploy) in your .vimrc to call same thing that real :ApexDeployAllDestructive calls.

edit2: Hmm, I think ApexDeployAllDestructive should be mentioned in the doc.

Certainly. Care to send a pull request? :-)
If you decide to do it please make a change in DeployModifiedDestructive branch. Will be easier to merge it.

from vim-force.com.

I tested the latest code in the development branch for vim & tooling-force.com.

I ran ApexDeployAllDestructive and it gave me the following error:

Operation failed
Component failures
  Trigger name exists on different SObject type: Assignment_Group_Queues__c
/Users/thomas/.apex/projects/sandbox-ash/.vim-force.com/response_deployAllDestructive
Press ENTER or type command to continue

/Users/thomas/.apex/projects/sandbox-ash/src/triggers/AssignmentGroupQueues.trigger|6 col 1| Trigger name exists on different SObject type: Assignment_Group_Queues__c

It looks like we need to keep the sobject type in the trigger body itself and we can not switch it to Account for all triggers. Maybe a good workaround is to get rid of all code between the top level curly braces.

Care to send a pull request?

It's the least I could do, expect a pull request :)

from vim-force.com.

Pull request sent: #37

from vim-force.com.

As you might have guessed by now I did not have a chance to test this command.
Updated the trigger stub handling.
New version is available here. Version number is still 0.3.1.2

from vim-force.com.

No worries. I don't mind testing stuff like this, especially if the end result benefits myself in particular.
Also, this isn't something you can find documentation on. I wish the stuff we were implementing was natively supported by salesforce because it is such a predominant workflow outside of salesforce development.

from vim-force.com.

So, I just did a test deployment to a sandbox that includes a class removal, and a trigger removal that references that class. It deployed fine, and after a refresh, the files to be deleted didn't come back :)

The only changes that appeared after the refresh were salesforce removing new lines from my source files (wtf salesforce?). FYI, there is a feature request that asks salesforce to not remove new lines at the end of code: https://success.salesforce.com/ideaView?id=08730000000kpRVAAY
I am not new to salesforce making these changes but it always makes me drop my jaw that they do this.

from vim-force.com.

Good that it seems to be working at first glance. Will close this ticket then.
When you find problems (which I am sure you will do) please open a new bug report.

Regarding EOL - added my vote, but judging by the number of votes there this idea is unlikely to be looked at by SFDC in the near future.
Depending on whether or not you use any tools which depend on the presence of new line (like cat over several files) you may want to consider removing last new line proactively in your git config as described here: http://stackoverflow.com/questions/1050640/vim-disable-automatic-newline-at-end-of-file/6503415#6503415
Do not recommend using git way with vim-force.com though because we calculate file checksum before it is passed through to git and use it to decide if a file has changed or not. For vim's case you could consider other suggestions in the stackoverflow thread I linked above.
Either way - I personally have gotten used to this quirk of SFDC and it does not annoy me as much as it used to.

from vim-force.com.

Just curious, when do you expect to merge the DeployModifiedDestructive branch into master?

from vim-force.com.

Ideally I would like this to be verified on some real deployments first. Not sure when I will get a chance to do that myself though.
Have you had a chance to use this new function beyond your initial test?

from vim-force.com.

I was able to deploy to our production server using the tool but outside of that, I have not done any other deployments.

from vim-force.com.