Java Web Implantação: código de construção, ou .war implantar?

Question

Duas maneiras principais para implantar um J2EE / app Java Web (em um sentido muito simplista):

Implantar montados artefatos para a caixa de produção

Aqui, nós criamos o .war (ou qualquer outro) em outro lugar, configure-o para a produção (possivelmente criando inúmeros artefatos para inúmeras caixas) e coloque os artefatos resultantes nos servidores de produção.

• Pros : Nenhuma ferramenta dev em caixas de produção, pode reutilizar os artefatos de teste diretamente, equipe fazer a implantação não precisa de conhecimento do processo de construção
• Contras : dois processos para criação e implantação de artefatos; configuração potencialmente complexo de artefatos pré-construídos poderia tornar o processo difícil de script / automatizar; tem que artefatos versão binários

construir os artefatos em caixa de produção

Aqui, o mesmo processo usado no dia-a-dia para criar e implantar localmente em caixas de desenvolvedor é usado para implantar a produção.

• Pros : Um processo para manter; e é fortemente testado / validado pelo uso freqüente. Potencialmente mais fácil de personalizar a configuração no momento da criação artefato em vez de customize artefato pré-construídos posfácio; Sem controle de versão dos artefatos binários necessários.
• Contras : ferramentas potencialmente complexas desenvolvimento necessárias em todas as caixas de produção; equipe de implantação precisa entender processo de construção; você não implantando o que você testou

Eu usei principalmente o segundo processo, é certo que em caso de necessidade (sem tempo / prioridade para outro processo de implantação). Pessoalmente eu não compro argumentos como "caixa de produção tem que ser limpo de todos os compiladores, etc.", mas eu pode ver a lógica em implantar o que você testou (em oposição à construção de um outro artefato).

No entanto, as aplicações Java Enterprise são tão sensíveis a configuração, ela se sente como pedir sarilhos ter dois processos para a configuração de artefatos.

Os pensamentos?

Atualização

Aqui está um exemplo concreto:

Nós usamos OSCache, e habilitar o cache de disco. O arquivo de configuração deve estar dentro do arquivo .war e faz referência a um caminho de arquivo. Este caminho é diferente em cada ambiente. O processo de compilação detecta localização e garante que o arquivo de propriedades colocado na guerra é o correto para o seu ambiente configurado do usuário.

Se fôssemos usar o processo de compilação de implantação, seria uma questão de criar a configuração certa para o ambiente de produção (por exemplo production.build.properties).

Se fôssemos seguir a "implantar artefatos reunidos para a caixa de produção", seria necessário um processo adicional para extrair os (incorretos) propriedades OSCache e substituí-lo com um apropriado para o ambiente de produção.

Isso cria dois processos para realizar a mesma coisa.

Assim, as perguntas são:

• É este evitável sem "compilar sobre a produção"?
• Se não, é isso vale a pena? É o valor de "não compilar sobre a produção de" maior que "Do not Repeat Yourself"?

Answer 1

Estou firmemente contra a construção na caixa de produção, porque isso significa que você está usando uma versão diferente do que você testou com. Significa, também, cada máquina de implementação possui um arquivo JAR / WAR diferente. Se nada mais, fazer uma compilação unificada apenas de modo que quando bug tracking você não terá que se preocupar com inconsistências entre os servidores.

Além disso, você não precisa colocar o constrói no controle de versão se você pode facilmente mapear entre uma compilação ea fonte que o criou.

Onde eu trabalho, o nosso processo de implantação é a seguinte. (Isto é em Linux, com Tomcat.)

1. Test muda e verificar em Subversion. (Não necessariamente nessa ordem, nós não exigem que o código comprometido é testado Eu sou o desenvolvedor só em tempo integral, então a árvore SVN é essencialmente o meu ramo de desenvolvimento Sua milhagem pode variar...)

2. Copie os arquivos de guerra para um servidor de produção em um diretório compartilhado com o nome do número de revisão Subversion JAR /. Os servidores web só tem acesso de leitura.

3. O diretório de implantação contém links simbólicos relativos aos arquivos nos diretórios chamado-de revisão. Dessa forma, uma listagem de diretório será sempre mostrar-lhe qual a versão do código-fonte produziu a versão em execução. Ao implantar, nós atualizar um arquivo de log que é pouco mais do que uma listagem de diretório. Isso faz roll-backs fáceis. (Uma pegadinha, embora;. Cheques Tomcat para novos arquivos WAR por data de modificação do arquivo real, não o link simbólico, por isso temos de tocar o arquivo de idade, quando rolando para trás)

Nossos servidores web descompactar os arquivos WAR em um diretório local. A abordagem é escalável, uma vez que os arquivos WAR estão em um único servidor de arquivos; poderíamos ter um número ilimitado de servidores web e apenas fazer uma única implantação.

Answer 2

A maioria dos lugares que eu trabalhei têm utilizado o primeiro método com informações de configuração do ambiente específico implantados separadamente (e atualizado muito mais raramente) fora da guerra / orelha.

Answer 3

Eu recomendo "Implantar montados artefatos para a caixa de produção" como um arquivo de guerra. É por isso que nossos desenvolvedores usar o mesmo script de construção (Ant no nosso caso) para construir a guerra em seu sandbox de desenvolvimento, como é usado para criar o finalmente artefato. Desta forma, ele é depurado, bem como o próprio código, para não mencionar completamente repetível.

Answer 4

Existem serviços de configuração, como o peso pesado ZooKeeper , ea maioria dos recipientes permitir você usar JNDI para fazer alguma configuração. Estes irão separar a configuração da compilação, mas pode ser um exagero. No entanto, eles existem. Muito depende de suas necessidades.

Eu também usei um processo pelo qual os artefatos são construídas com espaços reservados para valores de configuração. Quando o WAR é implantado, é explodida e os espaços reservados substituído com os valores apropriados.

Answer 5

Eu defendem o uso de uma solução de integração contínua que apoios distribuídos constrói. Código verificado em seu SCM pode desencadear constrói (para teste imediato) e você pode agendar constrói para criar artefatos para QA. Você pode então promover esses artefatos para produção e tê-los implantado.

Este é atualmente o que eu estou trabalhando na criação de, usando AnthillPro .

EDIT: Estamos agora usando Hudson . Recomendo!

Answer 6

Se você está fazendo esta pergunta em relação ao gerenciamento de configuração, em seguida, sua resposta deve ser baseada no que você considera ser um artefato gerenciado. De uma perspectiva CM, é uma situação inaceitável para ter alguma coleção de arquivos de origem de trabalho em um ambiente e não em outro. CM é sensível a variáveis ??de ambiente, configurações de otimização, versões de compilador e tempo de execução, etc, e você tem que conta para estas coisas.

Se você está fazendo esta pergunta relativa à criação processo repetitivo, então a resposta precisa ser com base na localização e quantidade de dor que você está disposto a tolerar. Usando um arquivo .war pode envolver dor mais up-front a fim de economizar esforço de teste e ciclos de implantação. Usando arquivos de origem e ferramentas de compilação pode salvar up-front custo, mas você terá que suportar a dor adicional para lidar com problemas no final do processo de implantação.

Atualização para o exemplo concreto

Duas coisas a considerar em relação ao seu exemplo.

1. A .war arquivo é apenas um arquivo .zip com uma extensão alternativa. Você pode substituir o arquivo de configuração no local usando utilitários zip padrão.

2. Potencialmente reconsiderar a necessidade de colocar o arquivo de configuração dentro do arquivo .war. Seria o suficiente para tê-lo no classpath ou ter propriedades especificadas na linha de comando de execução na inicialização do servidor.

Geralmente, tento manter implantação requisitos de configuração específica para o local de implantação.

Answer 7

Usando 1 arquivos de guerra embalados para implanta é uma boa prática.
usamos formiga para substituir os valores que são diferentes entre os ambientes. Nós verificar o arquivo com um @@@ variável que será substituído pelo nosso script ant. O script ant substitui o item correto no arquivo e, em seguida, atualiza o arquivo de guerra antes do deploy para cada

<replace file="${BUILDS.ROOT}/DefaultWebApp/WEB-INF/classes/log4j.xml" token="@@@" value="${LOG4J.WEBSPHERE.LOGS}"/>


<!-- update the war file We don't want the source files in the war file.-->
<war basedir="${BUILDS.ROOT}/DefaultWebApp" destfile="${BUILDS.ROOT}/myThomson.war" excludes="WEB-INF/src/**" update="true"/>

Para summarize- formiga faz tudo e usamos formigueiro para gerenciar formiga. formiga constrói o arquivo de guerra, substitui os caminhos de arquivo, atualiza o arquivo de guerra, em seguida, implanta ao environement alvo. Um processo, de facto, um clique de um botão no formigueiro.