Ferramentas para ajudar a gerenciar o processo de promoção do aplicativo em um ambiente corporativo

Question

Estou curioso para saber como os outros gerenciam a promoção de código de Dev para teste para Prod dentro de uma empresa.

Quais ferramentas ou processos você usa para gerenciar o lado da "burocracia", o lado das coisas dos critérios de entrada/saída?

Minha organização atual está meio presa entre alguns formulários on -line personalizados, funcionalidade e dependências baseadas em papel para enviar documentos, reunir aprovações e revisões.

Tudo isso é deixado nas mãos dos gerentes de projeto para rastrear o que foi enviado, aprovada, aprovada e aconselhar gerenciamento se houver algum obstáculo que possa precisar de aprovação para ser "negligenciado" antes que um aplicativo possa ser promovido ao próximo ambiente.

Um aplicativo baseado no navegador seria ideal ... então o que está lá fora? Por favor, mostre -me que você Googlefu é melhor que o meu.

Answer 1

É difícil encontrar um que seja bom no Google. Existe uma vasta gama de ferramentas para gerenciamento de problemas, então mencionarei o que usamos e o que gostaríamos de usar.

Atualmente, usamos produtos Serena. Eles trabalharam bem para nós no passado. O Team Track é o gerenciamento de problemas e lida com o ciclo de vida de qualquer problema em que trabalhemos. O Versing Manager é o nosso controle de origem e possui o recurso de implementar grupos promocionais como o Dev Test e o PROD. Usamos Dev, TStage, Test, Pstage e Prod para significar o movimento de um para o outro, mas é o mesmo. Os dois produtos se integram bem para que a fonte associada aos problemas esteja vinculada, mas não temos configuração de processo de construção nesse ambiente. É caro, mas funciona bem.

Estamos olhando para um sistema mais comum usando o JIRA para gerenciamento de problemas, subversão para controle de origem, Fisheye para vincular os dois e o controle de cruzeiro para o gerenciamento de construção. Isso é mais barato, totalizando alguns milhares para uma empresa corporativa e fornece os mesmos recursos, mas com o bônus adicional de SVN, que é uma versão muito boa da versão de código.

Espero que isso ajude.

Answer 2

Existem alguns cenários diferentes que experimentei ao longo dos anos:

Dev -> Teste: Geralmente, há uma data de congelamento de código que interrompe o trabalho em novos recursos e obtém um ambiente de teste o código que foi marcado/rotulado/arquivado que é construído. Isso então é copiado nas máquinas e os testes vão bem. Este também é geralmente o menos detalhado de qualquer empurrão.

Teste-> Prod: Isso requer a pequena alteração que a produção precisa descer, o que pode significar que uma página "Gone Fishing" aumenta ou o IIS não é executado em qualquer sites em execução e o código é copiado novamente. Existem casos especiais para isso em que um balanceador de carga pode atuar como um interruptor, para que a promoção aconteça e nenhum dos clientes experimente o tempo de inatividade, pois os do servidor mais antigo se moverão assim que a sessão terminar.

Para elaborar essa ideia de troca, a configuração é ter 2 servidores potencialmente vivos, com apenas um servidor solicitando solicitações de que o balanceador de carga envie todo o tráfego para uma máquina que pode ser alterada quando o outro servidor tiver o código atualizado para ir ao ar livre .

Também pode haver um ambiente de encenação entre teste e produção, onde o processo é semelhante em termos de uma data definida quando a promoção acontece.

Onde eu costumava trabalhar, haveria dias de mesclagem em que um desenvolvedor passava a maior parte do dia em Perforce mesclando código para que pudesse ser promovido de um ambiente para outro.

Agora existem alguns casos em que isso não é usado:

"Hotfixes" ou "Hot Patches" ocorreria onde eu costumava trabalhar e, nesse caso Alguma coisa nova que teve que ser feita que leva 2 minutos é feita. Nesse caso, a alteração do código que é pressionada teve que ser revisada e aprovada antes de sair.

Essas são as diferentes abordagens que eu vi usadas, onde geralmente existem cronogramas e cronogramas potencialmente precisam ser alterados ou recursos adicionais trazidos para fazer uma data difícil, como se uma conferência fosse em um fim de semana específico que isso e tal estes está pronto para isso.

É claro que em alguns lugares houve o "Oh, isso estava quebrado? Deixe -me ver ..." E alguns minutos depois, "não, ver que não está quebrado para mim", onde alguém mudou as coisas sem perguntar permissão ou qualquer coisa em que uma empresa ainda tenha o que chama de "programação de cowboys".

Outro ponto é a escala do lançamento: 1) Tiny - este é o caso em que uma página da web sobe para que o usuário X possa fazer y.

2) Pequeno - um punhado de arquivos que não é realmente complicado, mas não é exatamente trivial.

3) Médio - onde ir de um ambiente para outro exige alterar vários arquivos e geralmente tem scripts para se mover.

4) Big - onde há promoções programadas e vários desenvolvedores são solicitados a quem está recebendo quais mudanças quando o empurrão ao vivo é feito. Eu tive isso em um caso em que havia uma migração de dados para fazer, além da liberação de alguns novos sites de comércio eletrônico.

5) Mammoth - onde tudo é novo, incluindo como isso seria usado. Acho que nunca vi um desse tamanho, mas imagino que a Microsoft ou o Google teriam lançamentos desse tamanho.

Em algum lugar desse espectro, a maioria dos lançamentos cai e, portanto, quanto planejamento e preparação podem variar bastante e não devemos esquecer que a conformidade regulatória pode ser sua própria dor ao fazer algumas coisas.