Partilhar via

Práticas de DevOps para LUIS

  • Artigo

Importante

O LUIS será aposentado em 1º de outubro de 2025 e a partir de 1º de abril de 2023 você não poderá criar novos recursos do LUIS. Recomendamos migrar seus aplicativos LUIS para o entendimento de linguagem conversacional para se beneficiar do suporte contínuo ao produto e dos recursos multilíngues.

Os engenheiros de software que estão desenvolvendo um aplicativo Language Understanding (LUIS) podem aplicar práticas de DevOps em relação ao controle do código-fonte, compilações automatizadas, testes e gerenciamento de versões seguindo estas diretrizes.

Estratégias de controlo de fontes e de sucursais para o LUIS

Um dos principais fatores dos quais o sucesso do DevOps depende é o controle do código-fonte. Um sistema de controle de origem permite que os desenvolvedores colaborem no código e rastreiem as alterações. O uso de ramificações permite que os desenvolvedores alternem entre diferentes versões da base de código e trabalhem independentemente de outros membros da equipe. Quando os desenvolvedores levantam uma solicitação pull (PR) para propor atualizações de uma ramificação para outra, ou quando as alterações são mescladas, elas podem ser o gatilho para compilações automatizadas criarem e testarem continuamente o código.

Usando os conceitos e orientações descritos neste documento, você pode desenvolver um aplicativo LUIS enquanto acompanha as alterações em um sistema de controle do código-fonte e seguir estas práticas recomendadas de engenharia de software:

  • Controlo de Origem

    • O código-fonte do seu aplicativo LUIS está em um formato legível por humanos.
    • O modelo pode ser construído a partir da fonte de forma repetível.
    • O código-fonte pode ser gerenciado por um repositório de código-fonte.
    • Credenciais e segredos, como chaves, nunca são armazenados no código-fonte.

  • Ramificação e fusão

    • Os desenvolvedores podem trabalhar a partir de ramificações independentes.
    • Os desenvolvedores podem trabalhar em várias ramificações simultaneamente.
    • É possível integrar alterações em um aplicativo LUIS de uma ramificação para outra por meio de rebase ou mesclagem.
    • Os desenvolvedores podem mesclar uma RP com a ramificação pai.

  • Controle de versão

    • Cada componente em um aplicativo grande deve ser versionado de forma independente, permitindo que os desenvolvedores detetem alterações ou atualizações de quebra apenas observando o número da versão.

  • Revisões de código

    • As alterações no RP são apresentadas como código-fonte legível por humanos que pode ser revisto antes de aceitar o PR.

Controlo de origem

Para manter a definição de esquema de aplicativo de um aplicativo LUIS em um sistema de gerenciamento de código-fonte, use a representação do formato LUDown (.lu) do aplicativo. .lu o formato é preferido ao .json formato porque é legível por humanos, o que facilita a realização e revisão de alterações em RPs.

Salvar um aplicativo LUIS usando o formato LUDown

Para salvar um aplicativo LUIS no .lu formato e colocá-lo sob controle do código-fonte:

  • OU: Exporte a versão do aplicativo a partir .lu do portal LUIS e adicione-a ao seu repositório de controle do código-fonte

  • OU: Use um editor de texto para criar um .lu arquivo para um aplicativo LUIS e adicioná-lo ao repositório de controle do código-fonte

Gorjeta

Se você estiver trabalhando com a exportação JSON de um aplicativo LUIS, poderá convertê-lo em LUDown. Use a --sort opção para garantir que as intenções e os enunciados sejam classificados em ordem alfabética.
Observe que o arquivo . A capacidade de exportação de LU incorporada no portal LUIS já classifica a saída.

Crie a aplicação LUIS a partir do código-fonte

Para um aplicativo LUIS, construir a partir do código-fonte significa criar uma nova versão do aplicativo LUIS importando o .lu código-fonte , treinar a versão e publicá-la. Pode fazê-lo no portal LUIS ou na linha de comandos:

Arquivos a serem mantidos sob controle do código-fonte

Os seguintes tipos de arquivos para seu aplicativo LUIS devem ser mantidos sob controle do código-fonte:

  • .lu para a aplicação LUIS

  • Arquivos de definição de Teste de Unidade (enunciados e resultados esperados)

  • Arquivos de teste em lote (enunciados e resultados esperados) usados para testes de desempenho

Não é feito check-in de credenciais e chaves

Não inclua chaves ou valores confidenciais semelhantes em arquivos que você faz check-in em seu repositório onde eles podem estar visíveis para pessoal não autorizado. As chaves e outros valores que você deve evitar do check-in incluem:

  • Chaves de criação e previsão LUIS
  • Pontos finais de criação e previsão LUIS
  • Chaves de recursos do Azure
  • Tokens de acesso, como o token para uma entidade de serviço do Azure usada para autenticação de automação

Estratégias para gerenciar segredos com segurança

As estratégias para gerenciar segredos com segurança incluem:

  • Se você estiver usando o controle de versão do Git, poderá armazenar segredos de tempo de execução em um arquivo local e impedir o check-in do arquivo adicionando um padrão para corresponder ao nome do arquivo a um arquivo .gitignore
  • Em um fluxo de trabalho de automação, você pode armazenar segredos com segurança na configuração de parâmetros oferecida por essa tecnologia de automação. Por exemplo, se você estiver usando as Ações do GitHub, poderá armazenar segredos com segurança nos segredos do GitHub.

Ramificação e intercalação

Sistemas de controle de versão distribuídos, como o Git, dão flexibilidade na forma como os membros da equipe publicam, compartilham, revisam e iteram alterações de código por meio de ramificações de desenvolvimento compartilhadas com outras pessoas. Adote uma estratégia de ramificação Git apropriada para sua equipe.

Seja qual for a estratégia de ramificação adotada, um princípio fundamental de todas elas é que os membros da equipe podem trabalhar na solução dentro de uma ramificação de recurso, independentemente do trabalho que está acontecendo em outras ramificações.

Para apoiar o trabalho independente em filiais com um projeto LUIS:

  • A filial principal tem seu próprio aplicativo LUIS. Este aplicativo representa o estado atual da sua solução para o seu projeto e sua versão ativa atual deve sempre mapear para a .lu fonte que está na ramificação principal. Todas as atualizações da origem deste aplicativo devem ser revisadas e testadas para que ele possa ser implantado para criar ambientes como Produção .lu a qualquer momento. Quando as atualizações para o .lu são mescladas no principal a partir de uma ramificação de recurso, você deve criar uma nova versão no aplicativo LUIS e aumentar o número da versão.

  • Cada ramificação de recurso deve usar sua própria instância de um aplicativo LUIS. Os desenvolvedores trabalham com este aplicativo em uma ramificação de recursos sem risco de afetar os desenvolvedores que estão trabalhando em outras ramificações. Este aplicativo 'dev branch' é uma cópia de trabalho que deve ser excluída quando a ramificação de recurso é excluída.

Ramificação do recurso Git

Os programadores podem trabalhar a partir de sucursais independentes

Os desenvolvedores podem trabalhar em atualizações em um aplicativo LUIS independentemente de outras ramificações:

  1. Criação de uma ramificação de recurso a partir da ramificação principal (dependendo da sua estratégia de ramificação, geralmente principal ou em desenvolvimento).

  2. Crie um novo aplicativo LUIS no portal LUIS (o "aplicativo de ramificação de desenvolvimento") exclusivamente para dar suporte ao trabalho na ramificação de recursos.

    • Se a origem da .lu sua solução já existir em sua ramificação, porque ela foi salva após o trabalho feito em outra ramificação no início do projeto, crie seu aplicativo LUIS de ramificação de desenvolvimento importando o .lu arquivo.

    • Se você está começando a trabalhar em um novo projeto, você ainda não terá a fonte para o .lu seu aplicativo LUIS principal no repositório. Você criará o .lu arquivo exportando seu aplicativo de ramificação de desenvolvimento do portal quando tiver concluído seu trabalho de ramificação de recurso e enviá-lo como parte de seu PR.

  3. Trabalhe na versão ativa do seu aplicativo de ramificação de desenvolvimento para implementar as alterações necessárias. Recomendamos que você trabalhe apenas em uma única versão do seu aplicativo de ramificação de desenvolvimento para todo o trabalho de ramificação de recurso. Se você criar mais de uma versão em seu aplicativo de ramificação de desenvolvimento, tenha cuidado para controlar qual versão contém as alterações que você deseja fazer check-in quando aumentar seu PR.

  4. Teste as atualizações - consulte Testando o LUIS DevOps para obter detalhes sobre como testar seu aplicativo de ramificação de desenvolvimento.

  5. Exporte a versão ativa do seu aplicativo de ramificação de desenvolvimento a .lu partir da lista de versões.

  6. Faça check-in de suas atualizações e convide a revisão por pares de suas atualizações. Se você estiver usando o GitHub, você gerará uma solicitação pull.

  7. Quando as alterações forem aprovadas, mescle as atualizações na ramificação principal. Neste ponto, você criará uma nova versão do aplicativo LUIS principal , usando o atualizado .lu em main. Consulte Controle de versão para obter considerações sobre como definir o nome da versão.

  8. Quando a ramificação de recurso é excluída, é uma boa ideia excluir o aplicativo LUIS de ramificação de desenvolvimento que você criou para o trabalho de ramificação de recurso.

Os desenvolvedores podem trabalhar em várias ramificações simultaneamente

Se você seguir o padrão descrito acima em Os desenvolvedores podem trabalhar a partir de ramificações independentes, então você usará um aplicativo LUIS exclusivo em cada ramificação de recurso. Um único desenvolvedor pode trabalhar em várias ramificações simultaneamente, desde que alterne para o aplicativo LUIS de ramificação de desenvolvimento correto para a ramificação em que está trabalhando no momento.

Recomendamos que você use o mesmo nome para a ramificação de recurso e para o aplicativo LUIS de ramificação de desenvolvimento que você cria para o trabalho de ramificação de recurso, para tornar menos provável que você trabalhe acidentalmente no aplicativo errado.

Como mencionado acima, recomendamos que, para simplificar, você trabalhe em uma única versão em cada aplicativo de ramificação de desenvolvimento. Se você estiver usando várias versões, certifique-se de ativar a versão correta ao alternar entre aplicativos de ramificação de desenvolvimento.

Vários desenvolvedores podem trabalhar na mesma ramificação simultaneamente

Você pode oferecer suporte a vários desenvolvedores que trabalham na mesma ramificação de recursos ao mesmo tempo:

  • Os desenvolvedores verificam a mesma ramificação de recursos e enviam e puxam as alterações enviadas por eles mesmos e por outros desenvolvedores enquanto o trabalho prossegue, normalmente.

  • Se você seguir o padrão descrito acima em Os desenvolvedores podem trabalhar a partir de ramificações independentes, então essa ramificação usará um aplicativo LUIS exclusivo para dar suporte ao desenvolvimento. Esse aplicativo LUIS 'dev branch' será criado pelo primeiro membro da equipe de desenvolvimento que começa a trabalhar no ramo de recursos.

  • Adicione membros da equipe como colaboradores ao aplicativo LUIS da ramificação de desenvolvimento.

  • Quando o trabalho de ramificação de recurso estiver concluído, exporte a versão ativa do aplicativo LUIS de ramificação de desenvolvimento a .lu partir da lista de versões, salve o arquivo atualizado .lu no repositório e faça check-in e PR as alterações.

Incorporação de alterações de uma ramificação para outra com rebase ou mesclagem

Alguns outros desenvolvedores da sua equipe que trabalham em outra ramificação podem ter feito atualizações na .lu fonte e mesclado com a ramificação principal depois que você criou a ramificação de recurso. Você pode querer incorporar suas alterações em sua versão de trabalho antes de continuar a fazer as próprias alterações dentro de sua ramificação de recursos. Você pode fazer isso rebaseando ou mesclando para principal da mesma forma que qualquer outro ativo de código. Como o aplicativo LUIS no formato LUDown é legível por humanos, ele suporta mesclagem usando ferramentas de mesclagem padrão.

Siga estas dicas se você estiver rebaseando seu aplicativo LUIS em uma ramificação de recursos:

  • Antes de rebasear ou mesclar, verifique se a .lu cópia local da fonte do seu aplicativo tem todas as alterações mais recentes que você aplicou usando o portal LUIS, reexportando seu aplicativo do portal primeiro. Dessa forma, você pode garantir que quaisquer alterações feitas no portal e ainda não exportadas não se percam.

  • Durante a mesclagem, use ferramentas padrão para resolver quaisquer conflitos de mesclagem.

  • Não se esqueça de que, após a conclusão da rebase ou mesclagem, importe novamente o aplicativo para o portal, para que você esteja trabalhando com o aplicativo atualizado à medida que continua a aplicar suas próprias alterações.

Mesclar RPs

Depois que seu PR for aprovado, você poderá mesclar suas alterações à sua filial principal. Nenhuma consideração especial se aplica à fonte LUDown para um aplicativo LUIS: é legível por humanos e, portanto, suporta mesclagem usando ferramentas de mesclagem padrão. Quaisquer conflitos de mesclagem podem ser resolvidos da mesma forma que com outros arquivos de origem.

Depois que o RP for mesclado, é recomendável limpar:

  • Excluir a ramificação em seu repositório

  • Exclua o aplicativo LUIS 'dev branch' que você criou para o trabalho de ramificação de recurso.

Da mesma forma que com os ativos de código de aplicativo, você deve escrever testes de unidade para acompanhar as atualizações do aplicativo LUIS. Você deve empregar fluxos de trabalho de integração contínua para testar:

  • Atualizações em um PR antes que o PR seja mesclado
  • O aplicativo LUIS da filial principal depois que um PR foi aprovado e as alterações foram mescladas na principal.

Para obter mais informações sobre como testar o LUIS DevOps, consulte Testando o DevOps para LUIS. Para obter mais detalhes sobre a implementação de fluxos de trabalho, consulte Fluxos de trabalho de automação para LUIS DevOps.

Análises de código

Um aplicativo LUIS no formato LUDown é legível por humanos, o que suporta a comunicação de alterações em um RP adequado para revisão. Os arquivos de teste de unidade também são escritos no formato LUDown e também podem ser facilmente revisados em um PR.

Controlo de Versão

Um aplicativo consiste em vários componentes que podem incluir coisas como um bot em execução no Serviço de Bot do Azure AI, QnA Maker, serviço de Fala do Azure AI e muito mais. Para atingir o objetivo de aplicativos de acoplamento flexível, use o controle de versão para que cada componente de um aplicativo seja versionado de forma independente, permitindo que os desenvolvedores detetem alterações ou atualizações de quebra apenas observando o número da versão. É mais fácil fazer a versão do seu aplicativo LUIS independentemente de outros componentes se você mantê-lo em seu próprio repositório.

O aplicativo LUIS para a ramificação principal deve ter um esquema de controle de versão aplicado. Ao mesclar atualizações do aplicativo LUIS para o .lu principal, você importará essa fonte atualizada para uma nova versão no aplicativo LUIS para a ramificação principal.

É recomendável usar um esquema de controle de versão numérico para a versão principal do aplicativo LUIS, por exemplo:

major.minor[.build[.revision]]

A cada atualização, o número da versão é incrementado no último dígito.

A versão principal/secundária pode ser usada para indicar o âmbito das alterações à funcionalidade da aplicação LUIS:

  • Versão principal: uma alteração significativa, como o suporte para uma nova intenção ou entidade
  • Versão secundária: uma pequena alteração compatível com versões anteriores, como após um novo treinamento significativo
  • Build: Nenhuma alteração de funcionalidade, apenas uma compilação diferente.

Depois de determinar o número da versão para a última revisão do seu aplicativo LUIS principal, você precisa criar e testar a nova versão do aplicativo e publicá-lo em um ponto de extremidade onde possa ser usado em diferentes ambientes de compilação, como Garantia de Qualidade ou Produção. É altamente recomendável automatizar todas essas etapas em um fluxo de trabalho de integração contínua (CI).

Veja:

  • Fluxos de trabalho de automação para obter detalhes sobre como implementar um fluxo de trabalho de CI para testar e liberar um aplicativo LUIS.
  • Release Management para obter informações sobre como implantar seu aplicativo LUIS.

Controle de versão do aplicativo LUIS 'feature branch'

Quando você estiver trabalhando com um aplicativo LUIS de "ramificação de desenvolvimento" que você criou para dar suporte ao trabalho em uma ramificação de recurso, você estará exportando seu aplicativo quando seu trabalho estiver concluído e incluirá o atualizado 'lu em seu PR. A ramificação em seu repositório e o aplicativo LUIS 'dev branch' devem ser excluídos depois que o PR for mesclado no principal. Como este aplicativo existe apenas para suportar o trabalho na ramificação de recursos, não há nenhum esquema de controle de versão específico que você precise aplicar dentro deste aplicativo.

Quando as alterações no PR são mescladas na principal, é quando o controle de versão deve ser aplicado, para que todas as atualizações para a versão principal sejam versionadas independentemente.

Próximos passos