Tradicionalmente, o release do software é considerado como um aperto de mão entre a engenharia e os negócios. A Engenharia passa o código testado para os negócios, que por sua vez promove o software ao mercado, assim completando o ciclo. No entanto, com agile, o release do software pôde ser encaixado dentro de duas categorias de release interno e externo. Isso ajuda na criação de um aclopamento solto entre os dois. Releases internos são feitos pela engenharia e os negócios tem a opção de usar um deles como um release externo.
Em um artigo recente no Cutter Consortium (código de download RELEASEMYTH), Israel Gat do BMC fez um argumento interessante para separar os “dois” releases no mundo do software. Segundo ele o release interno e externo deveria ser visto nos dois lados de uma mesma moeda.
Um corpo de código que entrega certas características e funcionalidades é uma coisa. O uso desse corpo de código pelo marketing e pela vendas para conseguir resultados comerciais é outra completamente diferente. Não só as duas atividades se diferem, mas elas não necessariamente precisam estar ligadas através de um relacionamento 1-to-1.
Ele deu o exemplo de uma metáfora interessante de uma piscina de água com dois canos, um de encher e o outro de esvaziar. Ele comparou a engenharia com cano de encher e os negócios com o cano de esvaziar:
Pense no cano de encher neste exemplo como a engenharia e o cano de esvaziar como os negócios. Engenharia pode postar releases no seu próprio ritmo. Os negócios pode seletivamente escolher a partir dos releases postados. Neste paradigma, o marketing não é obrigado a promover um release após sua conclusão. Marketing pode fazer isso em três meses, talvez escolha promover o release atual com outro release devido em um posterior, talvez escolha por fazer um release disponível em uma base limitada ou até mesmo escolha nunca promover um release.
Israel mencionou que desde que a engenharia é agora gradualmente acoplada com os negócios, eles podem mover em direção de fluído de release conceito no qual o software torna-se vivo e continuo. Engenharia pode produzir uma série de releases internos em um ritmo adequado para eles e os negócios podem fazer uma decisão em que recebe o release do cliente como um release externo.
Comentando sobre o artigo, Ryan forneceu algumas introspecções adicionais que a equipe do Israel lançou três releases internos para um release externo. Ele sugeriu que o benefício é obter feedback valioso e o negócio poder comercializar o release externo melhor. De acordo com Ryan:
Isto funcionou muito bem! Como resultado, eu treino mais as equipes ágeis para começar me certificando que sua cadência de " releases interno" é duas vezes mais rápida no marketing, operações e no mercado é usado para fazer. Desta forma você obterá um release onde pode ganhar um feedback e orientar o " release externo" para comercializar melhor.
Segundo Israel, com a Agile, releases internos rápidos e freqüentes tornam o software mais vivo e fluído. Isto torna os processos de release tradicional obsoleto. A separação dos releases ajuda tanto a engenharia quanto os negócios para trabalhar de acordo com seus padrões de releases sem perturbar a freqüência do release de cada outro.