Descreva o melhor ambiente de implantação com o qual você trabalhou [fechado]

O teste Joel inclui a pergunta:

Você pode fazer uma compilação em uma única etapa?

O que é importante, mas estou me perguntando, como foram simplificados alguns dos processos de implantação ?

Todos os softwares, desde o shrink-wrap à web, se aplicam: qual é o melhor ambiente de implantação com o qual você trabalhou e quais etapas foram envolvidas?

É o ambiente que eu montei na minha empresa e estou trabalhando agora.

Descrição do ambiente

Somos uma equipe de 4 desenvolvedores , trabalhando em um projeto de desktop Java . O código fonte está no Mercurial , com o repositório principal hospedado em nosso servidor de desenvolvimento. Usamos principalmente o TortoiseHg para trabalhar com o Mercurial. Os projetos que abrimos são de origem no BitBucket . O projeto é construído com o Maven . O IDE que usamos é o Netbeans , que funciona de maneira impressionante com o Maven (também funciona bem com o Mercurial).

Nosso servidor de desenvolvimento executa o Archiva , que é um repositório proxy Maven. Usamos o maven para construir o projeto, mas também para executá-lo (mvn exec), implantar os artefatos gerados no Archiva (liberação do mvn) e gerar um assembly a partir dos artefatos hospedados no Archiva (mvn assembly).

Também temos um rastreador de bugs do Redmine e ele está ciente dos repositórios do Mercurial. Utilizamos um cliente RSS para ser informado sobre a atividade do projeto (da Redmine e Mercurial). Também temos um servidor Jabber para enviar mensagens e arquivos um para o outro.

Configuramos um servidor Hudson (integração contínua) e um servidor Sonar (métricas de código). Mas, na prática, realmente não o usamos.

Temos a opção de usar Windows ou Linux

Etapas para fazer um lançamento

Exemplo para liberar uma versão 1.1.3

# tags the VCS, updates all the version numbers in the maven config file
mvn --batch-mode release:prepare -DreleaseVersion=1.1.3 -DdevelopmentVersion=1.1.4-SNAPSHOT
# performs a clean build, runs all tests, deploys to the server
mvn release:perform
# creates a unique jar (the final product) from the previously deployed artifacts (no recomilation involved)
<update the version number in a config file to 1.1.3>
mvn assembly:assembly

Usei a malha para configurar a implantação na minha nova inicialização.

A atualização do servidor ativo é tão simples quanto:

fab prod upgrade

Isso obtém toda a fonte mais recente, cria uma página de manutenção, migra o banco de dados, configura o novo código, obtém todas as dependências, interrompe / inicia tudo, etc. Todas as informações pertinentes (senhas, nomes de usuário etc.) são todos perguntaram antecipadamente.

Eu apenas executo o comando, insiro algumas informações e vou pegar uma xícara de café. Tudo está vivo quando eu volto.

Não sei se concordo com Joel neste caso - certamente nenhuma etapa é melhor que uma?

Usamos o Hudson para criar scripts de nossas compilações (continuamente no Mac e no Windows), incluindo instaladores de construção e imagens de CD pelas poucas vezes em que realmente enviamos uma caixa real. Sempre testamos a partir do instalador no controle de qualidade.

Também usamos o Hudson para copiar os instaladores para a área "beta" do nosso site ao vivo uma vez por dia.

Então, basicamente, podemos implantar nos usuários todos os dias em nenhuma etapa. Quando fazemos um lançamento oficial, apenas trocamos os nomes dos arquivos dos instaladores no CMS para tornar os instaladores beta atuais os lançamentos e alteramos o script de construção do Ant para mudar para o novo número da versão (que se torna o novo beta).

Essa configuração e funcionamento torna o dia do lançamento um não evento completo (que é exatamente o que deveria ser). Não há um erro no dia do lançamento há algum tempo (costumava ser uma ocorrência regular)!

Em um de meus clientes, trabalhamos no Rails e temos tudo configurado para que a implantação seja extraída do git. Nós não "construímos", pois é o Rails.

Portanto, o processo de implantação é algo como

git checkout review
git merge whatever-that-was
git push
cap review deploy:migrations

A mistura entre Capistrano e GIT funciona muito bem.

Obviamente, scripts adicionais seriam para pular algumas dessas etapas.

Meu fluxo de trabalho atual é assim.

1. Desenvolver na VM local
2. Testar, confirmar alterações, pressionar para o github
3. ssh no EC2 e puxe alterações

Tudo isso pode ser script em uma etapa.

Temos um aplicativo Java Web Start - estamos prestes a reconstruir o procedimento de implementação para ser um arquivo WAR, com o arquivo JNLP sendo adaptado à URL solicitada quando solicitada pelos usuários.

Eu espero que isso seja extremamente suave.

Ultimamente temos usado muito o git. A idéia de registrar implantações em repositórios git, para que você possa simplesmente solicitar ao git que faça check-out da versão que deseja executar. Atualizações em segundo plano, tempo de check-out muito curto para atualizar arquivos reais, tempo de check-out muito curto para reverter para uma versão anterior em caso de problemas. Eu acho que poderia funcionar muito bem para nós.

Concedido que isso agora é bastante antigo, mas eu costumava ter as seguintes etapas para implantar meu código muitas luas atrás, que eu achei as melhores que já tive:

1. O check-in do meu código é alterado para o Visual SourceSafe.
2. Obtenha a versão mais recente na máquina do meu chefe.
3. Compile a solução que produziu algumas DLLs.
4. Mostre que o novo código funcionou como deveria.
5. Desconecte o servidor de produção da Internet para atualizá-lo sem interferência.
6. Copie os binários no servidor de produção.
7. Inicie o IIS.
8. Rediscar novamente na Internet na linha ISDN usada.

Isso foi no final dos anos 90, quando eu estava programando no Visual C ++ no NT 4.0 para uma pontocom. A maioria dos processos de implantação desde então ficou mais complicada ao ter tarefas nAnt e outras coisas extras, como lidar com servidores de produção com balanceamento de carga, enquanto no passado tínhamos apenas uma caixa de produção.

É claro que entregar o processo a um engenheiro de lançamento é melhor, mas não é o mesmo que colocar o código em estado selvagem.

Não é à toa, mas clicar com o botão direito do mouse em um aplicativo Web ASP.NET e selecionar Publicar foi uma surpresa agradável quando tive que implantar um aplicativo. Concedido, eu tive que configurar o diretório virtual e outros no IIS de antemão, mas a implantação de novas versões está a alguns cliques de distância.