Nossas equipes praticam a abordagem de desenvolvimento baseado em tronco - novo código é adicionado imediatamente ao branch master, branches de terceiros vivem por no máximo vários dias. E para que os commits não interfiram uns com os outros, os desenvolvedores usam Feature Flags - opções no código que iniciam e param o trabalho de seus componentes.
Considere uma iteração de desenvolvimento típica: planejamento, especificação de requisitos, criação de tarefas no rastreador, desenvolvimento. Quando as tarefas estão prontas, elas são implantadas no ambiente de teste para teste, a ramificação de lançamento se estabiliza. Então o lançamento finalmente chega e a equipe pode finalmente obter feedback real dos usuários.
Se você deseja reduzir o tempo de chegada ao mercado, isso é muito longo. Quanto mais cedo você receber feedback dos usuários, quanto mais cedo corrigir os erros, menos tempo gastará com ideias ruins e mais recursos poderá dedicar às ideias de sucesso.
Para que as atualizações cheguem à venda mais rapidamente, uma iteração deve incluir um recurso. É por isso que é necessário encurtar a vida útil dos ramos.
Problemas de longa duração no ramo
Conflitos entre commits (Merge hell). Atrasar a liberação, integração com um sistema externo e outros fatores externos podem tornar a contagem inoperante.
Dificuldades com compartilhamento de código. Outros membros da equipe podem precisar do código do novo branch se os recursos dependerem uns dos outros. Temos que iniciar outro branch apenas para acessar este código.
Problemas de ambiente de teste. Se houver apenas um servidor de teste e muitas ramificações de recursos, não funcionará testar tarefas em paralelo.
É difícil reverter as alterações. Os problemas após um lançamento são comuns e, se um novo ramo de recurso começar a falhar, os desenvolvedores devem escolher entre o hotfix e o reverso, acessar o código-fonte e recarregar a solução.
Como o desenvolvimento baseado em tronco resolve esses problemas
Trunk Based Development ( . trunk – « ») – . Gitflow, TBD master. feature- , .
Trunk Based Development , trunk. , , , -. .
trunk -. , . trunk , .
, - , ? Feature Flags.
Feature Flags
, IF-, . – , . : , - . – , .
(toggle router), . , , . ( ), (, , , ..).
Feature Flags
- , :
(release toggles): , , . .
(experiment toggles): A/B , . % , .
(permission toggles): . , .
(ops toggles): . , – , .
### Feature Flags
– .
– - , .
– TBD , .
: LaunchDarkly, Bullet-Train, Unleash. - , - . , .
Open source : Moggles, Esquilo. , , . , , .
: , . , . .
Feature Flags Portal (FF-Portal): Web + REST API . .
Feature Flags Storage (FF-Storage): .
Kubernetes ConfigMap (FF-configmap): k8s ConfigMap , , FF-Storage . FF-Portal FF-configmap.
Microservice (MS): , FF-configmap . FF-configmap, .
FF-ConfigMap, Pod- . ConfigMap, k8s , .
As sinalizações são alteradas por meio do portal, que envia uma mensagem de integração ao barramento quando o status é atualizado. O componente Config Updater atualiza os valores dos sinalizadores no FF-ConfigMap por meio da API K8S.
Finalmente sobre o teste
Surge a pergunta: como testar um produto com sinalizadores de recursos? À primeira vista, os sinalizadores complicam esse processo - se houver muitos switches, o número de todos os estados possíveis aumenta dramaticamente.
Mas as bandeiras nem sempre dependem umas das outras. Portanto, estamos testando dois casos limites para o lançamento: 1) todos os novos sinalizadores estão desligados e 2) todos os sinalizadores estão ligados.
A prática mostra que geralmente isso é suficiente.