Salesforce - Como implantar entre os ambientes (caixas de areia, ao vivo etc)

Question

Nós estamos olhando para a criação de um processo de implantação adequada.

Pelo que tenho lido, parece haver 4 métodos de fazer isso.

1. Copiar e Colar - Nós não queremos fazer isso
2. Usando o mecanismo de "Pacote" embutido no Salesforce Interface Web
3. IDE Eclipse Force "Deploy ao servidor" opção
4. Ant Script (não tentei este ainda)

Alguém tem conselhos sobre a limitação dos vários métodos.

Você pode incluir tudo em um pacote de Interface Web?

Nós estamos olhando para implantar os seguintes itens:

• Classes Apex

• Apex Triggers

• fluxos de trabalho

• E-mail Templates

• MailMerge Templates - Parece que não consegue encontrá-los no Eclipse

• Campos personalizados

• Layout da Página

• RecordTypes (não consigo encontrá-los no site ou Eclipse)

• itens PickList?

• SControls

Answer 1

Eu recomendo o Force.com Migração ferramenta .

Para referência:

• Force.com Migration Tool Documentação
• Guia de Migração Ferramenta

A ferramenta de migração permite que você use alvos de formigas para mover seus metadados entre salesforce.com organzations.

Answer 2

Eu posso falar a este da recente experiência dolorosa.

Embalagem: este é um método muito antigo que antecede a API de metadados em que ambos Ant e Eclipse confiar. Em nossa experiência, único benefício da embalagem é na definição de seu projeto. Se você estiver usando Eclipse (que fazemos, e eu recomendo), você pode definir seu projeto como sendo baseado em um pacote particular. Contanto que você lembre-se de adicionar novos componentes ao seu pacote, seus trava projeto juntos

Uma coisa que nos perplexo por um tempo, aliás, são os muitos usos do pacote. Notamos o seguinte:

Os pacotes instalados: estes vêm em sabores gerenciados e não gerenciados e são realmente, nas palavras de um post recente sobre as placas SFDC, por ISVs para implantar as suas coisas em várias orgs desconhecidos "lá fora". Ambos os pacotes gerenciados e não gerenciados têm limitações que os tornam inadequados e desnecessários para a implantação do desenvolvimento à produção dentro de uma org, ou em qualquer caso em que você está fazendo o desenvolvimento personalizado e não pretende distribuir o código para uma grande base de anonimato.

pacotes não-instalados: este é o que você vê quando você clica em "Pacotes" na interface do usuário da web. Estes, que por vezes chamamos de "pacotes de desenvolvimento", parece ser apenas uma maneira conveniente para manter a definição do projeto em conjunto.

De qualquer forma, a conclusão que eu estou vindo em direção é que nossa equipe (desenvolvimento personalizado, e não um ISV) não precisa de pacotes de qualquer forma.

As outras formas de implantação, tanto Eclipse e Ant, contar com a API de metadados. Em teoria, eles são capazes de exatamente as mesmas coisas. Na realidade, eles parecem ser complementares. A ferramenta de migração Force.com, construída no Force.com IDE para Eclipse, torna a implantação tão fácil como pode ser (que não é muito) e dá-lhe uma aparência agradável para o que se pretende implantar. Por outro lado, temos visto Ant fazer algumas coisas que o IDE não podia. Por isso é provavelmente vale a pena aprender ambos.

O processo que está inclinado em direção é manter todos os nossos projetos no SVN, e usar a estrutura SVN como a definição do projeto (Eclipse irá trabalhar com este e respeitá-lo). E usamos Eclipse e às vezes Ant para a migração. Sem aparente necessidade de pacotes em qualquer lugar.

A propósito, mais uma coisa para estar cientes de - nem todos os componentes são migratable. Algumas coisas devem ser reconfigurado manualmente no ambiente de destino. Um exemplo seria fluxos de trabalho baseados no tempo. Filas e grupos também precisam behand-criado, eu acho. Da mesma forma a API de metadados podem não diretamente eliminações campo processo então se você excluiu um campo em sua fonte, você precisa excluí-lo com a mão no alvo. Há outros casos também.

Hope isso é útil -

- Steve Pista

Answer 3

A partir de Primavera '09, modelos de mala direta não são suportados em metadados, mas os tipos de registro são. Você vai encontrar tipos de registro como um elemento XML no arquivo para o objeto a que pertencem. Tudo o resto em sua lista é suportado com uma pequena excepção. Os valores da lista de opções para campos padrão não pode ser editado na Primavera '09. Fique atento para notícias sobre Summer '09 anúncios metragens.

Update: picklists padrão em objetos padrão são agora metadados expostos (a partir de v16 API): http://www.salesforce.com/us/developer/ docs / api_meta / Content / meta_picklist.htm

Caso contrário, a resposta de Steve Lane é bastante precisa. A vantagem de usar pacotes não gerenciados (o que Steve chama pacotes não instalados) é que quando você adicionar metadados a um pacote, será adicionado automaticamente metadados que depende. Por isso é mais fácil de agarrar um conjunto completo de metadados contendo todas as suas dependências. Se você está se movendo repetidamente metadados de um org (sandbox) para outro (produção), a abordagem de Steve é ??provavelmente a melhor maneira de ir e certamente o mais comum hoje em dia. Eu freqüentemente usam pacotes não gerenciados "Developer" para mover algo que eu desenvolvi em um org para outra org independentes. Para o meu propósito, eu gostaria de ter o pacote definido no org em oposição a um projeto Eclipse / SVN. Mas isso provavelmente não faz sentido se você estiver fazendo o desenvolvimento da equipe através de muitos orgs dev / sandbox e estiver usando SVN já.

Jesper

Answer 4

Outra opção é usar alterar o conjunto de se você deseja mover meta-dados de uma caixa de areia para a produção.

Atualmente algumas limitações sobre como podem ser usados ??conjuntos de mudanças:

O envio de uma mudança definida entre duas organizações exige uma implantação conexão. Atualmente, conjuntos de alterações só podem ser enviadas entre organizações que estejam associadas com a organização da produção, para exemplo, a organização da produção e uma caixa de areia, ou duas caixas de areia criado a partir da mesma organização.

Answer 5

De docs:

Um pacote deve ser gerenciado para que possa ser divulgado publicamente no AppExchange, e para que possa suportar atualizações . Uma organização pode criar um único pacote gerenciado que pode ser baixado e instalado por muitas organizações diferentes. Eles diferem dos pacotes não gerenciados em que alguns componentes estão bloqueadas, permitindo que o pacote conseguiu ser atualizado mais tarde. pacotes não gerenciados não incluem componentes bloqueado e não pode ser atualizado. Além disso, pacotes gerenciados ofuscar certos componentes (como Apex) em organizações subscritoras, de modo a proteger a propriedade intelectual do desenvolvedor.

Advantage para pacote gerenciado seria que ele permite que você facilmente versão e distribuir as coisas através de várias organizações SFDC.

Answer 6

Eu ainda estou lutando com isso mesmo. Nem o IDE da ferramenta de migração de ter resolvido os principais problemas que enfrentam, que são as seguintes:

1. Os pacotes instalados não pode ser implantado em um desenvolvedor Org . Voce tem que instalá-los manualmente, um por um na Dev Org.

   Se um pacote não pode ser instalado na org (por exemplo, porque exige senha, como Marketo Vendas introspecção , ou porque tem -se obsoleta, como Salesforce para Google Adwords ) e nosso aplicativo tem dependências sobre ele (como referências a campos em objetos que pertencem ao pacote), então não será capaz de implantar o aplicativo.

   Solução : se um pacote não pode ser instalado manualmente em um Dev Org cada desenvolvedor terá seu próprio desenvolvedor Sandbox. Sandboxes adicionais para desenvolvedores pode ser encomendado a partir Salesforce. (O cliente tem que estar dispostos a pagar por eles, embora ...)

2. Quando o sandbox é atualizado desde a produção e nós refrescar nossa projeto local (que é conectado ao SVN) do servidor tudo arquivos adicionais / código que estava em no antigo Sandbox, mas não é em produção vai ser transferida para o New Sandbox.

   Solução : todos alterações feitas na produção deve ser replicada no Sandbox eo Desenvolvedores Orgs. (um tipo de dor, mas ok ...)

Answer 7

Em qualquer Salesforce implantação de produção, a API de metadados é uma das melhores opções para fazê-lo. Existem ferramentas que simplificam o trabalho. Confira este post: https://www.deploypkg.com/deploy-to-production/