Se você trabalha em uma ORG do Salesforce por algum tempo, você provavelmente já precisou remover classes do APEX de produção, se não preciso parabéns, mas acredito que mais cedo ou mais tarde você vai precisar, então continue a leitura que um dia tenho certeza que essa dica lhe será muito útil :)

Mas atenção, o conteúdo aqui apresentado pode afetar o funcionamento da sua ORG do Salesforce, tenha certeza de que tenha backup dos metadados que deseja remover e de fazer os testes prévios em uma Sandbox, siga por sua conta e risco.

O problema

Não é comum encontrarmos esse cenário, mas sim, eles ocorrem, eu mesmo já me deparei com ele em praticamente todas as ORGs do Salesforce que trabalhei, quando pegamos um projeto que já esta no meio do caminho, muitas vezes precisamos refatorar algumas classes, em algumas vezes abandonar a classe de vez (ou porque o nome não faz sentido para só refatorar ou porque aquela funcionalidade não tem mais sentido) e quando nos deparamos com esse problema descobrimos que metadados não podem ser renomeados, dessa forma a solução é a exclusão e criação de um novo, e ai uma nova descoberta, não podemos excluir uma classe do APEX ou uma trigger de produção via clique de um botão, para isso precisamos de um pacote, e mais uma descoberta, não é um simples pacote que você cria no Change Sets e envia para produção, até mesmo porque estamos removendo um classe, para removermos então as classes de produção, precisamos de um pacote especial, denominado destructiveChanges.

Eu precisei fazer isso a alguns dias atrás, das outras vezes simplesmente abandonei as classes em produção, mas dessa vez resolvi ir a fundo, pois queria deixar esta ORG Salesforce bem organizada, e de quebra aproveitar para fazer esse post :)

O que pode ser removido com o Destructive Changes

Bom, basicamente todo e qualquer tipo de metadado que você consegue enviar para produção via pacote, você consegue remover também do ambiente produtivo usando um pacote destructiveChanges. Se você não sabe o que é um Metadado sugiro que de uma olhada no post do Arthur.

Mão na massa

Para conseguir fazer isso vamos precisar de dois arquivos, mas antes, sugiro que crie uma pasta na sua área de trabalho, com o nome que preferir. Em seguida crie um novo arquivo de texto utilizando o seu editor de textos preferido (Notepad, Notepad++, Sublime, VSCode), esse arquivo deverá se chamar package.xml, e o seu conteúdo deve ser:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
     <version>45.0</version>
</Package>

Agora basta salvar como package.xml e partir para o próximo arquivo, esse sim vai dar um pouco mais de trabalho, mas nada impossível.

Crie um novo arquivo usando seu editor de texto preferido, e esse deve ter um nome também especial destructiveChanges.xml, se atente ao C em maiúsculo, sim, ele fará diferença.

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>MinhaClasse</members>
        <members>MinhaClasse2</members>
        <name>ApexClass</name>
    </types>
    <version>45.0</version>
</Package>

Lembrando que você pode deletar qualquer tipo de metadado, basta verificar o name correto dele nessa lista e os members sendo o nome de API do que deseja remover, no exemplo abaixo eu removo Apex Class, Trigger e Páginas do Visualforce, tudo de uma vez.

<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>MinhaClasseApex</members>
        <name>ApexClass</name>
    </types>
    <types>
        <members>MinhaTrigger</members>
        <name>ApexTrigger</name>
    </types>
    <types>
        <members>MinhaPagina</members>
        <name>ApexPage</name>
    </types>
    <version>45.0</version>
</Package>

Sim, você pode excluir as Páginas do Visualforce atráves do botão excluir na lista de Páginas do Visualforce diretamente em produção, mas só quero te mostrar que você também pode excluir elas por aqui, dessa forma você consegue remover tudo de uma só vez, páginas e controllers por exemplo.

Criando o pacote para remover classes do APEX de produção

O próximo passo é criar o pacote, que nada mais é do que um .ZIP contendo os dois arquivos criados, para isso certifique-se de que ambos arquivos estejam salvos e na mesma pasta, acesse a pasta e selecione os dois arquivos, em seguida clique com o botão direito e escolha a opção Compactar, geralmente disponível no Windows e Mac.

O nome do arquivo pode ser qualquer um, no nosso caso vamos considerar que o arquivo se chama package.zip

E agora que a tensão aumenta e começa aquele friozinho na barriga, rs

Para enviar o pacote para produção, acesse o Workbench apontando para o servidor de produção (Mas tenho certeza que você já terá testado isso em uma Sandbox, siga daqui em diante por sua conte e risco).

Após logado, selecione o menu Migration -> Deploy

Na tela que se abrirá, localize o arquivo clicando no botão [Choose file], em seguida marque as caixas de seleção [Rollback On Error] e [Single Package] e no dropdown Test Level, selecione a opção RunLocalTests, nem preciso falar que nessa hora sua ORG do Salesforce precisa ter 75% de cobertura e todos os testes rodando, não é mesmo?

Clique no botão [Next], e aguarde a mágica acontecer, isso pode demorar alguns minutos, você poderá acompanhar o deploy da janela seguinte e também do menu status de implantação no setup da sua ORG do Salesforce.

Conclusão

Se você precisa remover classes do APEX de produção, essa sem dúvida é uma das formas mais simples, sim existem outras utilizando ANT e Eclipse (que deus o tenha) mas fazendo via pacote e enviar ele para produção via Workbench é uma tarefa que requer sim um pouco de atenção, mas que é possível concluir em poucos minutos, espero que esse passo-a-passo possa ser útil para você um dia.

Um forte abraço trailblazers, até o próximo post :)

 

Fernando Sousa

Fernando Sousa

Senior Salesforce Developer

Bacharel em Sistemas da Informação pela Universidade de Taubaté (UNITAU) e MBA em Projeto de Aplicações para Dispositivos Móveis pelo IGTI – Instituto de Gestão em Tecnologia da Informação. 

Comecei a programar bem cedo, por volta de 10 anos de idade, de maneira auto-didata passei por várias linguagens.

Em 2015 me conectei a plataforma Salesforce pela primeira vez, para fazer una integração entre um Aplicativos Mobile em android e o Salesforce Platform. 

Atualmente com as certificações Salesforce Certified Platform Developer I, Salesforce Certified Platform App BuilderSalesforce Certified Platform Developer IISalesforce Administrator e Sharing and Visibility.

Acompanhe meu Trailhead aqui.