Octopus Feature Flags sai do preview e chega ao Octopus 2027.0 self-hosted

A Octopus trocou o formulário por ambiente por um modelo de regras. Cada ambiente tem zero ou mais regras, e cada regra tem uma ou mais condições. A regra casa quando todas as condições são satisfeitas, e a flag liga quando qualquer regra casa. As condições cobrem tenant (lista ou tag), atributos do contexto de avaliação do OpenFeature (e-mail, região, tipo de licença), versão mínima, percentual de tenants e percentual por targeting key. A condição de versão só casa depois que o release chegou ao ambiente, porque o Octopus sabe o que está implantado onde.

Os rollouts automatizados são sequências de fases, e cada fase agrupa regras. Uma fase pode ser ativada manualmente ou por trigger, em data e hora fixas ou um intervalo após a fase anterior. Dá para misturar os dois modos. Se algo der errado, desligue a flag na hora ou segure o rollout removendo o trigger da próxima fase. Quem tem flags existentes verá a opção de atualizar todas de uma vez. A Octopus diz que tudo o que o formulário expressa pode ser expresso em regras, então o comportamento não muda, mas os client SDKs precisam estar em versão compatível antes do upgrade. As novas versões são retrocompatíveis.

Na disponibilidade, o Cloud tira o rótulo de Preview, e o Octopus Server self-hosted recebe o recurso na versão 2027.0. As flags valem em todas as faixas de licença, inclusive a Free, e usam OpenFeature, o que a Octopus apresenta como ausência de lock-in.

Em 14 de agosto de 2026, o CEVIU noticiou "Octopus Easy Mode Otimiza Rollouts Progressivos com Validação Automática", sobre um mesmo release passando por Desenvolvimento, Produção 10, Produção 50 e Produção 100. Ali a progressão era por ambientes. Agora a Octopus leva a progressão para dentro da flag, com fases de regras e triggers. Já a cobertura de 24 de junho de 2026, sobre GitHub Connections, também trouxe um recurso do Cloud ao self-hosted (2026.2), mas é outro recurso.

Para quem opera Octopus self-hosted, isso significa poder separar deploy de release sem trocar de ferramenta, e tirar o plano de rollout da wiki. Na leitura editorial, o ponto de atenção é o upgrade: inventarie os SDKs em uso antes de migrar as flags existentes, porque é aí que o risco prático aparece.