Como você aborda gerenciamento de liberação para uma aplicação web (SaaS)?

Question

O que é a melhor abordagem para lançar uma nova versão de um aplicativo web hospedado, e quantas vezes você costuma liberar? Você escolhe uma data arbitrária, dizer a cada semana, mês, etc, para rollout um conjunto acumulado de correções (talvez usando uma abordagem semelhante à abordagem de Joel para as datas de envio )? Esperando muito mais tempo do que parece parte derrota da grande vantagem de um aplicativo hospedado. Por outro lado, você não gostaria de rolar constantemente novos recursos que possam confundir o usuário (ou seja, se não foi diferente a cada vez que ele / ela logado algo).

Até recentemente minha experiência tem sido principalmente com aplicativos baseados em servidor ou Desktop instalado. Estou curioso para ver que tipo de gerenciamento de liberação pessoas usam com um aplicativo hospedado.

Answer 1

A abordagem do Google é provavelmente o melhor para o usuário final, mas ele vem com o custo de complexidade.

Eles lançar novas versões (e mudanças às vezes apenas individuais) em uma base bastante constante (como muitas vezes como diária, dependendo do projeto). Mas aqui está o kicker:. Apenas uma pequena parcela dos usuários são dadas a nova versão

O Google tem um grande número de usuários para os seus grandes produtos, por isso é prático para colocar em regras como "5% dos usuários deve ver este recurso".

Eles podem, em seguida, analisar os resultados e planejar seu próximo lançamento, talvez para outros 15% da população de usuários.

Answer 2

Por mais que os engenheiros deseja definir uma rotina para viver, ele é realmente vai ser impulsionado pelas demandas de negócios por trás do sistema. Também realmente depende da natureza das atualizações, etc ...

Conteúdo e HTML atualizações não deve ser um grande negócio para empurrar para fora. mudanças aplicação deve ser um grande negócio, e percorrer as rotinas de testes estabelecidos em um site de visualização antes de ser empurrado ao vivo.

Uma coisa certa é que você precisa ter uma maneira muito "limpa" para implantar (e undeploy) muda. Você também precisa de uma maneira "fácil" para revisão e auditar as alterações antes de entrar ao vivo.

Usando uma mistura de "git" e "rsync" permite o controle total sobre o processo. Todas as alterações ao nosso projeto são desenvolvidos em um ramo que foi ramificada do ramo "Produção". Antes de qualquer mudança pode ir ao vivo, o ramo "Produção" deve ser totalmente incorporada em. O ato de ir ao vivo é simplesmente mesclando o ramo apropriado em "Produção" e rsyncing-lo para os servidores ao vivo. Git faz isso realmente fácil.

Isso garante que as mudanças em curso podem viver possivelmente não entram em conflito com outras mudanças em curso.

Desde a adoção desse sistema, nossa rotina implantação aumentou drasticamente na eficiência e clareza. E pelo jeito, nossas implementações variam de várias vezes por dia para uma vez a cada vários meses. Tudo depende. Eu preferiria uma liberação 1-2 por ciclo de semana em um projeto ativo.

Answer 3

Release cedo e muitas vezes é o que eu faço, eo que fazemos onde trabalhamos. Nós também blog sobre nossas atualizações sempre que torná-los. É provavelmente mais fácil para você se você rolar todas as suas atualizações em uma atualização de cada vez (para QA, tendo a reversão, etc) como o melhor que puder. Da perspectiva do usuário Eu não acho que haja qualquer problema com muitas atualizações. Enquanto eles não são atualizações ruins. Eu acho que é um problema se você esperar por um ano inteiro ou seis meses, e rolar todas as suas atualizações em um grande lançamento. Isso é o que matou um projeto que eu usei para trabalhar em (a feedreader popular você provavelmente já ouviu falar). As pessoas pensavam que estávamos mortos, ea percepção tornou-se realidade. Nós fomos abandonados. Então, eu sou todo para calendários de lançamento firehose.

Answer 4

A cada duas semanas deve ser suficiente, mas isso depende muito do seu mercado.

Answer 5

No Planbox (web-based ágeis SaaS de gerenciamento de projeto) nós liberamos todos os dias. Podemos fazer isso porque a maioria da nossa lógica de aplicação, e toda a nossa lógica de apresentação estão no front-end (Javascript). Até mesmo o HTML é gerado via Javascript usando um motor de templates. Mas o backend (PHP) e sua API REST raramente mudam. Isso nos permite empurrar novas versões do cliente a qualquer momento sem quebrar a compatibilidade.

Se você pode mover-se para tal arquitetura, você vai economizar toneladas de tempo e ganhar muita eficiência.