Marcação de recurso
Como expor progressivamente seus recursos com marcações de recursos.
Ian Buchanan
Engenheiro Principal de Soluções
Se o plano é a integração contínua de recursos ao seu aplicativo durante o desenvolvimento, considere sinalizadores de funcionalidade. Afinal, você pode querer alternar, ocultar, desativar ou ativar os recursos. Você também pode querer revelar diferentes variações de recursos para os usuários, a fim de descobrir qual deles é melhor. As marcações de recursos, também conhecidas como “alternâncias”, “bits”, “flippers” ou “switches” oferecem essas possibilidades e muito mais.
O que são marcações de recursos?
Marcações de recursos (também bastante conhecidos como alternâncias de recursos) é uma técnica de engenharia de software que ativa e desativa a funcionalidade de seleção durante o tempo de execução, sem implementar novo código. Ela permite que as equipes façam alterações sem enviar código adicional e permite uma experimentação mais controlada ao longo do ciclo de vida dos recursos. Por esse motivo, marcações de recursos permitem vários novos fluxos de trabalho que são muito úteis para um estilo de gerenciamento ágil e ambientes de CI/CD.
Durante o desenvolvimento, os engenheiros de software envolvem os caminhos de código desejados em uma marcação de recurso. Veja a seguir um exemplo de uma marcação de recurso básico escrito em JavaScript:
if(featureFlags[‘new-cool-feature’] == true){
renderNewCoolFeature();
} Este código demonstra uma instrução simples que verifica se um “new-cool-feature” está habilitado. Mesmo com estruturas e ferramentas avançadas que ajudam a gerenciar dados de marcação ou injeção e remoção do novo caminho lógico, as marcações de recursos são, na essência, apenas instruções "se". Portanto, este interruptor binário é o que todos os sinônimos têm em comum.
Ver solução
Crie e opere softwares com o Open DevOps
Material relacionado
Descubra o que é desenvolvimento baseado em troncos
Benefícios dos sinalizadores de funcionalidade
Em um nível fundamental, as marcações de recursos permitem que o código passe por commit e seja implementado na produção em um estado inativo e ativado mais tarde. Assim as equipes têm mais controle sobre a experiência do usuário do produto final. As equipes de desenvolvimento podem escolher quando e para quais usuários os novos códigos são entregues.
Validação da funcionalidade do recurso
Os desenvolvedores podem promover sinalizadores de funcionalidade para realizar uma "implementação suave" dos novos recursos. Novos recursos podem ser criados com integração imediata de alternâncias de recursos como parte da versão esperada. O sinalizador de funcionalidade pode ser definido como "desativado" por padrão para que, uma vez que o código for implantado, ele permaneça inativo durante a produção e o novo recurso vai ser desativado até que a alternância do recurso seja explicitamente ativada. As equipes escolhem quando ativar o sinalizador de funcionalidade, que ativa o código, permitindo que as equipes executem o controle de qualidade e verifiquem se ele se comporta conforme esperado. Se a equipe descobrir um item durante esse processo, ela pode desativar na hora o sinalizador de funcionalidade para desativar o novo código e minimizar a exposição do usuário ao item.
Reduzir riscos
Com base na ideia discutida acima, as equipes podem alavancar sinalizadores de funcionalidade em conjunto com o monitoramento do sistema e as métricas como resposta a quaisquer problemas intermitentes observáveis. Por exemplo, se um aplicativo tiver um pico no tráfego e o sistema de monitoramento relatar um aumento nos itens, a equipe vai poder usar marcações de recursos para desativar recursos com desempenho ruim.
Modificação de comportamento do sistema sem alterações conflituosas
Os sinalizadores de funcionalidade podem ser usados para ajudar a reduzir cenários complicados de integração e implementação de código. Novos recursos complicados ou trabalho de refatoração sensível podem ser desafiadores para se integrar na ramificação de produção principal de um repositório. Fica ainda mais complicado se vários desenvolvedores trabalharem em partes sobrepostas da base de código.
As marcações de recurso podem ser usadas para isolar novas alterações enquanto o código estável e conhecido continua funcionando. Elas ajudam os desenvolvedores a evitar ramificações de recurso de longa duração, ao fazer commits frequentes à ramificação principal de um repositório por trás da alternância de recursos. Quando o novo código estiver pronto, um cenário de merge e implementação colaborativa disruptiva é desnecessário; a equipe pode alternar a marcação de recurso para ativar o novo sistema.
Casos de uso da marcação de recurso
A nova utilidade das marcações de recursos permite uma variedade de casos de usos criativos para equipes trabalhadoras. Os exemplos a seguir destacam alguns aplicativos populares de sinalizadores de funcionalidade em um ambiente ágil.
Teste de produtos
Os sinalizadores de funcionalidade podem ser usados para lançar aos poucos os novos recursos do produto. Pode ser pouco claro no início se um novo recurso proposto vai ser adotado pelos usuários e se ele vale o retorno do investimento. As equipes podem lançar um novo recurso de produto ou uma ideia parcial do recurso em um sinalizador de funcionalidade e implementar em um subconjunto de usuários para coletar feedback. O subconjunto de usuários pode ser usuários vocais experientes que ficam contentes em revisar e testar versões beta. Se a ideia do novo produto se comprovar um sucesso, a equipe de desenvolvimento pode então implementar o sinalizador de funcionalidade para uma base de usuários maior. Se, em vez disso, a ideia do novo produto for um fiasco, é fácil para a equipe de desenvolvimento desativar e remover o sinalizador de funcionalidade da base de código.
Condução de experimentos
Experimentos ou testes A/B são exemplos principais de sinalizadores de funcionalidade. Na sua forma mais simples, as marcações de recursos atuam como uma alternância do estado “on” e “off” para um recurso. Marcações de recursos avançadas utilizam várias marcações de uma só vez para ativar experiências diferentes para subconjuntos de usuários. Por exemplo, imagine que você vai dividir sua base de usuários em terços. Cada terço recebe sua marcação e experiência do usuário únicas. É possível, então, medir o desempenho dessas três sinalizações umas contra as outras para determinar a versão final com commit.
Migrações
Há momentos em que um aplicativo precisa de migração de dados que exige alterações de código de aplicativo dependentes. Esses cenários são tarefas de implementação multifásicas sensíveis. Um campo de banco de dados pode ser modificado, removido ou adicionado em um banco de dados de aplicativo. Se o código do aplicativo não estiver preparado para essa alteração de banco de dados, ele vai causar falhas e erros. Se esse for o caso, é necessária uma implementação coordenada entre as alterações do banco de dados e o código do aplicativo.
As marcações de recursos ajudam a aliviar a complexidade desse cenário, permitindo que as equipes preparem com antecedência alterações de aplicativos em uma marcação de recurso. Assim que a equipe fizer as alterações no banco de dados, ela pode alternar na hora a marcação de recurso para corresponder ao código do aplicativo. Assim são removidos o risco e o atraso de esperar para implementar o novo código do aplicativo e possivelmente ver a implementação falhar e dessincronizar o aplicativo do banco de dados.
Implantação do canário
O canário nesse contexto faz referência a uma antiga e mórbida prática de mineradores de carvão, que levavam canários às minas de carvão para detectar monóxido de carbono. As aves têm taxas de metabolismo mais elevadas e frequências de respiração mais rápidas, o que as faziam sucumbir ao monóxido de carbono antes dos mineiros.
Lançamentos canários no desenvolvimento de software ocorrem quando um novo recurso ou alteração de código é implementado em um pequeno subconjunto de usuários para monitorar seu comportamento antes da liberação para o conjunto completo de usuários. Se o novo recurso mostrar qualquer indicação de erros ou falha, ele vai ser automaticamente revertido. As marcações de recursos são essenciais para esse processo, pois restringem o pool de público e podem alternar recursos com facilidade.
Interrupção do sistema
Um sinalizador de funcionalidade também pode ser usado como uma ferramenta de interrupção do sistema. Um aplicativo web pode utilizar um sinalizador de funcionalidade para “desligar” todo o site para manutenção ou tempo de inatividade. O sinalizador de funcionalidade pode ser instrumentado em toda a base de código para enviar transações sensíveis e exibir conteúdo de interrupção para os usuários finais. Esse recurso pode ser muito útil ao fazer implementações confidenciais ou se um problema inesperado for encontrado e precisar ser resolvido com urgência. Ele dá às equipes a confiança e a capacidade de fazer uma interrupção controlada, se for necessário.
Implementação contínua
Os sinalizadores de funcionalidade podem ser usados como componentes integrais para criar um verdadeiro sistema de implementação contínua. A implementação contínua é um pipeline automatizado que leva novos códigos dos desenvolvedores e o implementa automaticamente para usuários finais de produção. A implementação contínua depende de camadas de testes automatizados que verificam o novo código se comporta conforme esperado em relação a uma especificação correspondente à medida que ele se move pelo pipeline.
As marcações de recursos tornam mais segura a implementação contínua, separando as alterações de código de recursos reveladores para os usuários. O novo código pode passar por merge e implementação automáticos na produção e, em seguida, esperar atrás de uma marcação de recurso. O sistema de implementação contínua pode monitorar o comportamento e o tráfego de usuários e ativar automaticamente a marcação de recurso. Inversamente, o sistema de implementação contínua pode monitorar o novo código de marcação de recurso para ver se ele se comporta como esperado e, se não for assim, fazer a reversão.
Ramificações de recursos vs. marcações de recursos
Embora os nomes sejam parecidos, as ramificações de recursos e as marcações de recursos são bem diferentes. As ramificações de recurso são um padrão de fluxo de trabalho importante para os repositórios de controle de origem do Git. Quando os desenvolvedores iniciam um novo recurso de produto, criam uma nova ramificação do Git correspondente que se desvia da ramificação principal e vai conter o código para o novo recurso. Quando os desenvolvedores terminam um novo recurso, fazem o merge da ramificação do recurso de volta à ramificação principal e implementam. As ramificações de recurso são autônomas e distintas das marcações de recurso.
As marcações de recurso podem ser usadas com ramificações de recursos. Para criar uma marcação de recurso, um desenvolvedor cria uma ramificação de recurso e faz o commit do novo código de marcação de recurso para a ramificação de recurso. Uma vez instrumentada, a ramificação de recurso passa por merge e implementação, e a marcação de recurso passa a ser acessível na produção.
Durante o desenvolvimento da ramificação de versão, um projeto pode passar a ser de longa duração ou se desviar da ramificação principal e conter vários commits. Os desenvolvedores precisam garantir que uma ramificação de recurso seja sempre atualizada para que os conflitos sejam mínimos quando a ramificação de recurso estiver pronta para o merge. É preciso um esforço a mais para garantir que uma ramificação de recurso seja sempre atualizada para que os conflitos sejam mínimos quando a ramificação de recurso estiver pronta para o merge. Marcações de recurso podem ser usadas para corrigir um cenário assim. Ao invés de criar uma ramificação de recurso de longa duração e fazer um merge volumoso quando o novo recurso estiver pronto, uma marcação de recurso pode ser criada e logo em seguida passar por merge para ramificação principal.
Como implementar marcações de recursos
Há muitos caminhos para implementar sinalizadores de funcionalidade com considerações logísticas variadas e retorno sobre o investimento. O caminho a seguir depende das necessidades e objetivos organizacionais da sua equipe.
A marcação de recursos tem algumas dependências de infraestrutura que precisam ser endereçadas para funcionar corretamente. À medida que as equipes escalam seu uso de marcações de recursos e o ligar/desligar das marcações se torna uma decisão comercial, passa a ser fundamental ter um armazenamento de dados autoritário e um mecanismo de gerenciamento para as marcações. Muitos serviços de marcação de recursos de terceiros têm essa dependência de armazenamento de dados.
Os serviços de marcação de recursos hospedados por terceiros em geral são a melhor solução. Eles lidam com a logística pesada e oferecem bibliotecas fáceis de integrar que agilizam o processo de instalação. Assim as equipes podem manter o foco nos principais deveres de negócios em vez de gerenciamento de infraestrutura. No entanto, se sua equipe tiver problemas de segurança de terceiros, pode ser do seu interesse implementar seu back-end de marcação de segurança.
Em separado, os engenheiros precisam instrumentar a nova lógica de código que recupere o estado da marcação do serviço para ativar o conteúdo marcado. Então, eles precisam de merges de código e implementações do código de marcação antes de ser ativado. Como muitas marcações de recursos são temporárias, não se esqueça de remover as marcações de recursos que não são mais necessárias.
Conclusão...
As marcações de recursos são uma poderosa adição a um arsenal de desenvolvimento ágil. Existem muitas maneiras criativas de utilizar marcações de recursos. As marcações de recursos são complementares à implementação contínua e ao controle de versão do Git. Em geral, as marcações de recursos dão às equipes mais controle sobre sua base de código, sua implementação e a experiência do usuário final.
Confira os tutoriais de sinalização de funcionalidades de DevOps, que revelam as melhores práticas em uma cadeia de ferramentas de Open DevOps.
Compartilhe este artigo
Próximo tópico
Leitura recomendada
Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.
Comunidade de DevOps
Leia o blog
