Libertação antecipada / liberar frequentemente para software comercial? [fechadas]

Question

Há alguém com experiências / exemplos em liberar cedo / liberando muitas vezes por software comercial? Será que funciona?

Eu estava pensando em VMware, onde eles têm um monte de revisões liberar entre cada versão principal. E a experiência de instalação foi horrível, às vezes eles iria quebrar as VMs existentes e outras vezes as VMware Tools dentro SOs hóspedes seria mau funcionamento / não instalar. É simplesmente horrível.

E eu estava pensando em ClickOnce implantações, bem como, uma vez que com ClickOnce quando você atualizar seu software, todos os clientes automaticamente é notificado do lançamento, e com um clique eles estão atualizados para a nova versão. Se o seu software tem bugs, então eles vão automaticamente "atualizado" para obter esses erros também.

Você tem experiência \ exemplo \ sugestão para aplicar a libertação antecipada / liberar frequentemente princípio de software comercial?

Eu estou olhando para aplicá-la a um.

Answer 1

Kenny tem razão:. Isso depende

Trabalhamos com software da empresa, onde um cliente pode executar um projeto interno 3+ mês para atualizar para uma nova versão. Nesse ambiente lançamentos freqüentes fazer não trabalho. Os clientes vão ficar em uma versão antiga por anos e nós temos que manter apoiá-los, de modo que os mais lançamentos que estão ativos mais o trabalho de apoio.

No outro extremo, eu estava correndo Google Chrome e ler sobre uma atualização beta. Fui ver como obtê-lo e descobriu que o Chrome já havia se atualizado. Se houve qualquer notificação eu perdi, e que é bom para mim.

A questão principal é como perturbador uma nova versão é . Por exemplo, se o MS lançou novas versões do Visual Studio a cada 3 meses com uma nova versão .NET, C tempo de execução, etc, em seguida, que seria passar uma boa parte do nosso tempo lidando apenas com a atualização, o que não seria bom. Mas se eles querem lançar novas versões do Windows media player com algum novo widget que é bom para mim -. Apenas fazer o download / instalar processo tão simples quanto possível

Answer 2

Eu acho que sempre vai depender do seu mercado ou base de clientes. Alterar / atualizar software é sempre doloroso e ainda mais dolorosa em alguns ambientes e empresas. ciclos de liberação rápida pode ser perturbador. Estas interrupções muitas vezes se estendem para suas operações internas também, dependendo de como fluência característica bem é gerido pelo marketing / gestão.
Assim, os clássicos sempre verdadeiros 'depende' resposta anéis novamente.
Se você está realmente agregar valor ao produto, os clientes, especialmente os novos vai querer isso. O melhor caso, é remover a dor mudança upgrade, como em, ele funciona o mesmo, mas melhor de maneiras óbvias. Grande.

Answer 3

Preste atenção ao homem atrás da cortina :.
A única coisa que a soltura prematura - Libere Freqüentemente prática quer que você faça é ter falhar cedo e rápido, em vez de no final do projeto, quando é tarde demais. Dá-lhe mais oportunidades para mostrar o que você está construindo para o cliente final, obter feedback valioso e se adaptar a um custo menor. A pessoa no papel 'cliente' deve ser capaz de obter facilmente a última versão; brincar com ela e responder com feedback construtivo tão regularmente quanto possível.

No caso de você está construindo algo crítico por exemplo algo que monitores ou controles de uma usina de energia, você provavelmente vai querer ter cuidado com esta prática. Você não quer que as pessoas com tochas como um feedback para o seu novo lançamento. Em tais casos, faz sentido para implantar regularmente para uma cama de teste, vê-lo durante X dias (de acordo com seu nível de confiança) e, em seguida, ir ao vivo! Você pode dar a seu cliente acesso a esta cama de teste para jogar e construir o seu medidor de confiança.
Se seu um aplicativo não-crítica e você teve um bom registo histórico de bons lançamentos, fazer algo como ClickOnce .. mas também certificar-se do seu igualmente fácil de reversão para o cliente.

Answer 4

Se você estiver indo para fazer isso, certifique-se que quando as pessoas comprar o seu produto que eles vão conseguir upgrades gratuitos para novas versões por um ano, ou algum outro período de tempo para que eles não se sentem como eles tem arrancado quando uma nova versão sai 2 meses depois de terem comprado uma cópia. Além disso, garantir que você apoia versões antigas para que aqueles que não deseja atualizar, quer apenas correções de bugs pode fazê-lo sem correr o risco de quebrar suas instalações atuais com as novas versões do software. Eu, pessoalmente, acho que vai ser mais trabalho, mas você vai acabar com um produto melhor, e você vai permitir que as pessoas usando o seu software para tirar mais proveito dos recursos mais recentes mais rápido se eles escolherem.

Answer 5

Nós executar um aplicativo SaaS, por isso, em princípio, ele pode ser atualizado tão frequentemente como nós gostamos.

Por outro lado, na prática, fica apenas a alguns grandes lançamentos por ano (menores versões de patch são colocados a cada poucas semanas tipicamente).

A razão para isto é que libera criar interrupção para a equipe de operações; às vezes parte das necessidades de aplicação a tomar para baixo. Cada para alterações não voltados para o cliente, há um monte de trabalho que vai para realmente fazer o lançamento em oposição a fazer a engenharia.

Assim, enquanto StackOverflow parece ficar atualizado a cada poucos dias, nós não fazemos nada parecido. Vários bugs pode ser fixado em um dia, mas eles estão corrigido em uma versão posterior que sai como um "big bang". Ou algo assim.

Answer 6

Depende de seus recursos. Se você é da Microsoft, você pode início de lançar um POS bug-ridden que rima com Sista, e confiar em seu poder de marketing para fazer as pessoas esquecerem suas primeiras experiências com o produto.

Se você está esperando por um bom boca-a-boca, liberando uma versão inicial não é uma boa idéia (a menos que você está planejando para mudar o nome ou algo antes do lançamento final).