Quais são as formas de dissociar a implantação da liberação?

Um método de implantação contínua é dissociar a implantação da liberação, ou seja, implantar atualizações sem ativar as alterações imediatamente.

Sei que alternância de recursos pode ser usada para isso, mas estou me perguntando se existem outras técnicas para "não-recursos".

Por exemplo, você criaria uma alternância de recurso para uma correção de bug? Provavelmente não, e pode-se argumentar que as correções de erros devem ser implantadas o mais rápido possível, porque elas só podem melhorar. E depois que uma correção de bug foi lançada, com certeza não quero mais desativá-la. Mas é este o caso? Pode ser uma mudança arriscada que você deseja liberar de forma controlada. E se não são efeitos colaterais inesperados, é bom ser capaz de revertê-lo. Então, sinalizadores de recursos para cada alteração?

E as mudanças visuais? Por exemplo, você pode implementar algo como um sinalizador de recurso em CSS? Isso faz algum sentido?

Para o software na categoria de aplicativo da web, dependendo do provedor de infra-hospedagem / hospedagem, esse desacoplamento pode ser possível alternar o tráfego de entrada entre (ou dividi-lo entre) diferentes versões implantadas do sw, cobrindo praticamente qualquer uma das alterações mencionadas: correções de bugs, visuais etc.

Esse suporte normalmente não exigiria alternância de recursos. E pode ser aplicável independentemente do aplicativo ser monolítico ou dividido em microsserviços.

Por exemplo, a oferta Paas do Google App Engine oferece suporte para divisão e migração de tráfego.

De divisão de tráfego :

Você pode usar a divisão de tráfego para especificar uma distribuição percentual de tráfego em duas ou mais das versões em um serviço. A divisão de tráfego permite realizar testes A / B entre suas versões e fornece controle sobre o ritmo ao implementar os recursos.

Da migração de tráfego :

A migração de tráfego alterna o roteamento de solicitação entre as versões em um serviço do seu aplicativo, movendo o tráfego de uma ou mais versões para uma única nova versão.

Embora com monólitos você possa estar restrito a comutadores, com arquiteturas de microsserviço, é possível dividir todos os conjuntos de nós de implantação que fornecem um serviço (por exemplo, pods). Em seguida, você ativa a implantação do produto recém-alterado em um subconjunto de conjuntos e monitora-o com cuidado; você pode até escolher qual quantidade de pool implantar a alteração para, por exemplo, ativar a alteração para 15% do tráfego. Você pode encontrar o recurso chamado "atualização sem interrupção" na literatura.