Azure DevOps Server 2022 Notas de versão da Atualização 2
| Comunidade | de desenvolvedores Requisitos do sistema e compatibilidade | Termos | de licença DevOps Blog | Hashes SHA-256 |
Neste artigo, você encontrará informações sobre a versão mais recente do Azure DevOps Server.
Para saber mais sobre como instalar ou atualizar uma implantação Azure DevOps Server, consulte Azure DevOps Server Requisitos.
Para baixar produtos Azure DevOps Server, visite a página Downloads do Azure DevOps Server.
A atualização direta para Azure DevOps Server 2022 Atualização 2 tem suporte de Azure DevOps Server 2019 ou Team Foundation Server 2015 ou mais recente. Se a implantação do TFS estiver no TFS 2013 ou anterior, você precisará executar algumas etapas provisórias antes de atualizar para Azure DevOps Server 2022. Consulte a página Instalar para obter mais informações.
Azure DevOps Server 2022.2 RTW Data de lançamento: 9 de julho de 2024
Resumo das novidades no Azure DevOps Server 2022.2 RTW
Azure DevOps Server 2022.2 RTW é um pacote cumulativo de correções de bugs. Ele inclui todos os recursos do Azure DevOps Server 2022.2 RC lançado anteriormente. Você pode instalar diretamente Azure DevOps Server 2022.2 ou atualizar de Azure DevOps Server 2020, 2019 ou Team Foundation Server 2015 ou mais recente. Os seguintes problemas e vulnerabilidades foram resolvidos com esta versão:
- CVE-2024-35266: vulnerabilidade de falsificação do Azure DevOps Server
- CVE-2024-35267: vulnerabilidade de falsificação do Azure DevOps Server
- Tíquete de comentários da Comunidade de Desenvolvedores: a versão do agente não é atualizada após a atualização para Azure DevOps Server 2022.1 e o uso do Agente de Atualização na configuração do Pool de Agentes
- Tíquete de feedback da comunidade de desenvolvedores: problema ao carregar a página de configuração da equipe
- Tíquete de feedback da comunidade de desenvolvedores: correção do tratamento incorreto de datas na notificação por email de PR para determinados formatos regionais
Azure DevOps Server 2022 Atualização 2 RC Data de lançamento: 7 de maio de 2024
Azure DevOps Server 2022.2 RC inclui muitos novos recursos. Alguns dos destaques incluem:
- Limites para caminhos de área e iteração
- Ignorar aprovações e verificações em pipelines
- Validação YAML aprimorada
- Suporte do Azure Artifacts para Caixas de Carga
- Nova experiência de diretório do painel
- Cópia rápida e importação com plano de teste ou ID do pacote
Você também pode pular para seções individuais para ver todos os novos recursos de cada serviço:
Geral
Tarefa de publicação de Resultados de Teste
A tarefa Publicar Resultados do Teste agora oferece suporte a anexos de execução de teste para o formato de relatório JUnit.
Nova versão do SDK da Extensão da Web do Azure DevOps
Com esta atualização, estamos lançando uma nova versão do SDK da Extensão da Web do Azure DevOps. O SDK do cliente permite que as extensões da Web se comuniquem com o quadro do host. Pode ser usado para:
- Notifique o host de que a extensão está carregada ou tem erros
- Obter informações contextuais básicas sobre a página atual (informações atuais de usuário, host e extensão)
- Obter informações sobre o tema
- Obter um token de autorização a ser usado em chamadas REST de volta para Azure DevOps
- Obter serviços remotos oferecidos pelo quadro de host
Você pode encontrar uma referência completa da API na documentação do pacote azure-devops-extension-sdk. Esta nova versão oferece suporte para os seguintes módulos:
Suporte ao módulo ES: O SDK agora oferece suporte a módulos ES (ECMAScript), além dos módulos AMD (Asynchronous Module Definition) existentes. Agora você pode importar o SDK usando a sintaxe do módulo ES, que fornece melhorias de desempenho e reduz o tamanho do aplicativo.
Compatibilidade com versões anteriores para módulos AMD: O suporte existente para módulos AMD permanece intacto. Se o seu projeto estiver usando módulos AMD, você poderá continuar a usá-los como antes, sem nenhuma alteração.
Modo de utilização:
Para módulos ES, você pode importar nossos módulos usando a instrução import:
import * as SDK from 'azure-devops-extension-sdk';
// Use the module here
Se você estiver usando módulos AMD, poderá continuar a importar o SDK usando a require função:
require(['azure-devops-extension-sdk'], function(SDK) {
// Use the module here
});
Boards
Limites para caminhos de área e iteração
Os limites desempenham um papel importante na manutenção da saúde e eficiência de um grande serviço global. Com esta versão, estamos introduzindo limites rígidos de 10.000 por projeto para caminhos de área e iteração. Visite a página Acompanhamento de trabalho, processo e limites de projeto para saber mais sobre os diferentes limites no serviço.
Controles de desenvolvimento e implantação
Agora removemos os controles de Desenvolvimento e/ou Implantação do item de trabalho, dependendo de como seu projeto está configurado. Por exemplo, você pode definir as configurações do projeto para desativar Repos e/ou Pipelines.
Quando você for para o item de trabalho, os controles de Desenvolvimento e Implantação correspondentes serão ocultados do formulário.
Se você decidir conectar um repositório GitHub ao Azure Boards, o controle de desenvolvimento para repositórios GitHub será exibido.
Repos
Nova "Política de ramificação" impedindo que os usuários aprovem suas próprias alterações
Para melhorar o controle sobre quais alterações o usuário aprova e corresponder a requisitos regulatórios/de conformidade mais rígidos, oferecemos uma opção para impedir que o usuário aprove suas próprias alterações, a menos que seja explicitamente permitido.
O usuário com capacidade de gerenciar as políticas de branch agora pode alternar a opção recém-adicionada "Exigir pelo menos uma aprovação em cada iteração" em "Quando novas alterações são enviadas". Quando essa opção é selecionada, é necessário pelo menos um voto de aprovação para a última alteração do branch de origem. A aprovação do usuário não é considerada em relação a nenhuma iteração anterior não aprovada enviada por ele. Como resultado, a aprovação adicional da última iteração deve ser feita por outro usuário.
A imagem a seguir mostra a solicitação de pull criada pelo usuário A e 4 confirmações adicionais (iterações) feitas a essa solicitação de pull pelos usuários B, C, A novamente e C. Depois que a segunda iteração (commit feito pelo usuário B) foi feita, o usuário C aprovou isso. Naquela época, isso implicava a aprovação do primeiro commit do usuário A (quando a solicitação de pull foi criada) e a política recém-introduzida será bem-sucedida. Após a quinta iteração (último commit do usuário C), a aprovação foi feita pelo usuário A. Isso implicava aprovação para o commit anterior feito pelo usuário C, mas não implicava aprovação para o segundo commit feito pelo usuário A na quarta iteração. Para que a política recém-introduzida seja bem-sucedida, a iteração quatro não aprovada deve ser aprovada pela aprovação do usuário B, C ou de qualquer outro usuário que não tenha feito nenhuma alteração na solicitação de pull.
Observação
Há um problema conhecido em que as políticas de branch usarão um grupo, configurado como revisor, como entidade de aprovação. Vamos imaginar que haja uma aprovação necessária feita por qualquer usuário do Grupo G. O usuário A é membro desse Grupo G. Depois que o usuário A fornece a aprovação como na imagem acima (após a quinta iteração), a aprovação do Grupo G aprova a alteração feita pelo usuário A. Isso não é esperado e será resolvido na versão RTW.
Suporte a filtros sem blob e sem árvores
O Azure DevOps agora dá suporte a duas filtragens adicionais durante a clonagem/busca. Estes são: --filter=blob:none e --filter=tree:0 A primeira opção (clone sem blob) é melhor usada para desenvolvimento regular, enquanto a segunda opção (clone sem árvore) se encaixa melhor nos casos em que você descarta o clone depois, por exemplo, executando uma compilação.
Descontinuação do SSH-RSA
Azure Repos fornece dois métodos para os usuários acessarem um repositório git em Azure Repos – HTTPS e SSH. Para usar o SSH, você precisa criar um par de chaves usando um dos métodos de criptografia suportados. No passado, oferecemos suporte apenas ao SSH-RSA e pedimos aos usuários que habilitassem o SSH-RSA aqui.
Com essa atualização, estamos anunciando a substituição do SSH-RSA como um método de criptografia com suporte para se conectar a Azure Repos usando SSH. Você pode ver mais detalhes na postagem no blog Fim do suporte SSH-RSA para Azure Repos .
Pipelines
Evite execuções de pipeline não intencionais
Hoje, se o pipeline YAML não especificar uma trigger seção, ele será executado para todas as alterações enviadas por push para seu repositório. Isso pode criar confusão sobre por que um pipeline foi executado e levar a muitas execuções não intencionais.
Adicionamos uma configuração de Pipelines no nível da coleção e do projeto chamada Desabilitar gatilho de CI YAML implícito que permite alterar esse comportamento. Você pode optar por não disparar pipelines se a seção de gatilho estiver ausente.
Repetir um estágio quando as aprovações e verificações atingirem o tempo limite
Quando as aprovações e verificações atingem o tempo limite, o estágio ao qual pertencem é ignorado. Os estágios que têm uma dependência do estágio ignorado também são ignorados.
Agora você pode repetir um estágio quando as aprovações e verificações atingirem o tempo limite. Anteriormente, isso só era possível quando uma aprovação expirava.
Ignorar aprovações e verificações
Aprovações e verificações ajudam a proteger o acesso a recursos importantes, como conexões de serviço, repositórios ou pools de agentes. Um caso de uso comum é usar Aprovações e Verificações ao implantar na produção e você deseja proteger a conexão de serviço do ARM.
Digamos que você tenha adicionado as seguintes verificações na conexão de serviço: uma verificação de Aprovação, uma verificação de Horário Comercial e uma verificação de Invocar Função do Azure (para impor um atraso entre regiões diferentes).
Agora, imagine que você precisa fazer uma implantação de hotfix. Você inicia uma execução de pipeline, mas ela não prossegue, ela aguarda a conclusão da maioria das verificações. Você não pode esperar que as aprovações e verificações sejam concluídas.
Com esta versão, tornamos possível ignorar as aprovações e verificações em execução, para que você possa concluir seu hotfix.
Você pode ignorar a execução de verificações de Aprovações, Horário Comercial, Invocar Função do Azure e Invocar API REST.
Ignorar uma aprovação.
Ignorar verificação do horário comercial.
Ignorar a verificação Invocar Função do Azure. Ignorar verificação do horário comercial.
Quando uma verificação é ignorada, você pode vê-la no painel de verificações.
Você só poderá ignorar uma verificação se for um administrador do recurso no qual as verificações foram definidas.
Executar novamente as verificações de função do Azure
Imagine que você implanta seu sistema em vários estágios. Antes de implantar o segundo estágio, há uma verificação de Aprovação e Invocar Função do Azure que executa uma verificação de integridade na parte já implantada do sistema.
Ao revisar a solicitação de aprovação, você percebe que a verificação de integridade foi executada dois dias antes. Nesse cenário, você pode estar ciente de outra implantação que afetou o resultado da verificação de integridade.
Com essa atualização, você pode executar novamente as verificações Invocar Função do Azure e Invocar API REST. Essa funcionalidade está disponível apenas para verificações bem-sucedidas e sem novas tentativas.
Observação
Você pode executar novamente uma verificação somente se for um administrador do recurso no qual as verificações foram definidas.
Suporte para servidor corporativo GitHub na verificação de modelo necessária
Os modelos são um mecanismo de segurança que permite controlar os estágios, trabalhos e etapas de pipelines em sua coleção de projetos.
A verificação Exigir modelo permite que você imponha que um pipeline se estenda de um conjunto de modelos aprovados antes de acessar um recurso protegido, como um pool de agentes ou conexão de serviço.
Agora você pode especificar modelos localizados em repositórios do GitHub Enterprise Server.
Função de administrador para todos os ambientes
Os ambientes em pipelines YAML representam um recurso de computação no qual você implanta seu aplicativo, por exemplo, um cluster do AKS ou um conjunto de VMs. Eles fornecem controles de segurança e rastreabilidade para suas implantações.
Gerenciar ambientes pode ser bastante desafiador. Isso ocorre porque, quando um ambiente é criado, a pessoa que o cria automaticamente se torna o único administrador. Por exemplo, se você quiser gerenciar as aprovações e verificações de todos os ambientes de forma centralizada, terá que pedir a cada administrador de ambiente para adicionar um usuário ou grupo específico como administrador e, em seguida, usar a API REST para configurar as verificações. Essa abordagem é tediosa, propensa a erros e não é dimensionada quando novos ambientes são adicionados.
Com esta versão, adicionamos uma função de administrador no nível do hub de ambientes. Isso coloca os ambientes em pé de igualdade com conexões de serviço ou pools de agentes. Para atribuir a função de Administrador a um usuário ou grupo, você já precisa ser um administrador do environments-hub ou proprietário da coleção de projetos.
Um usuário com essa função de administrador pode administrar permissões, gerenciar, exibir e usar qualquer ambiente. Isso inclui a abertura de ambientes para todos os pipelines.
Quando você concede a um usuário a função de administrador no nível do hub de ambientes, ele se torna administrador de todos os ambientes existentes e de todos os ambientes futuros.
Validação YAML aprimorada
Para verificar se a sintaxe YAML está correta, você pode usar a funcionalidade Validar do editor da Web do Azure Pipelines. Portanto, é importante que essa funcionalidade capture o maior número possível de problemas YAML.
A validação YAML agora é mais completa quando se trata de expressões.
Ao escrever pipelines YAML, você pode usar funções para definir valores variáveis.
Imagine que você defina as seguintes variáveis:
variables:
Major: '1'
Minor: '0'
Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]
A Patch variável é definida usando a counter função e as outras duas variáveis. No código YAML acima, a palavra format é escrita incorretamente. Anteriormente, esse erro não era detectado. Agora, a funcionalidade Validar detectará isso e exibirá uma mensagem de erro.
O Azure Pipelines detectará definições de variáveis incorretas no nível do pipeline/estágio/trabalho.
Em pipelines YAML, você pode ignorar a execução do estágio usando condições. Erros de digitação também podem aparecer aqui, como no exemplo a seguir.
steps:
- task: NuGetCommand@2
condition: eq(variable.Patch, 0)
inputs:
command: pack
versioningScheme: byPrereleaseNumber
majorVersion: '$(Major)'
minorVersion: '$(Minor)'
patchVersion: '$(Patch)'
A NuGetCommand tarefa será executada somente se o valor da Patch variável for 0. Novamente, há um erro de digitação na condição e a funcionalidade Validar o exibirá.
O Azure Pipelines detectará condições YAML incorretas definidas no nível do pipeline/estágio/trabalho.
APIs REST para ambientes
Um ambiente é uma coleção de recursos que você pode direcionar com implantações de um pipeline. Os ambientes fornecem histórico de implantação, rastreabilidade para itens de trabalho e confirmações e mecanismos de controle de acesso.
Sabemos que você deseja criar ambientes programaticamente, por isso publicamos a documentação para sua API REST.
Melhorias na API REST de aprovações
Melhoramos a localização de aprovações atribuídas a um usuário, incluindo os grupos aos quais o usuário pertence nos resultados da pesquisa.
As aprovações agora contêm informações sobre a execução do pipeline à qual pertencem.
Por exemplo, a seguinte chamada https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending da API REST GET retorna
{
"count": 1,
"value":
[
{
"id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
"steps":
[],
"status": "pending",
"createdOn": "2023-11-09T10:54:37.977Z",
"lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
"executionOrder": "anyOrder",
"minRequiredApprovers": 1,
"blockedApprovers":
[],
"_links":
{
"self":
{
"href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
}
},
"pipeline":
{
"owner":
{
"_links":
{
"web":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
},
"self":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
}
},
"id": 73222930,
"name": "20231109.1"
},
"id": "4597",
"name": "FabrikamFiber"
}
}
]
}
Os logs de pipeline agora contêm a utilização de recursos
Os logs de pipeline do Azure agora podem capturar métricas de utilização de recursos, como memória, uso da CPU e espaço em disco disponível. Esses logs também incluem recursos usados pelo agente do pipeline e processos filho, incluindo tarefas executadas em um trabalho.
Se você suspeitar que seu trabalho de pipeline pode ter restrições de recursos, habilite logs detalhados para que as informações de utilização de recursos sejam injetadas nos logs de pipeline. Isso funciona com qualquer agente, independentemente do modelo de hospedagem.
O agente do Azure Pipelines agora dá suporte ao Alpine Linux
O agente de pipeline v3.227 agora oferece suporte ao Alpine Linux versões 3.13 e superiores. O Alpine Linux é popular para a imagem de contêiner (base). Você pode encontrar o agente na página de versões . As versões do agente do Alpine Linux têm um prefixo vsts-agent-linux-musl , por exemplo, vsts-agent-linux-musl-x64-3.227.1.tar.gz.
As tarefas do Azure Pipelines usam o Nó 16
As tarefas no pipeline são executadas usando um executor, com Node.js usado na maioria dos casos. As tarefas do Azure Pipelines que utilizam um nó como executor agora usam o nó 16. Como o Node 16 é a primeira versão do Node a oferecer suporte nativo ao Apple Silicon, isso também conclui o suporte completo a tarefas para macOS no Apple Silicon. Os agentes em execução no Apple Silicon não precisam do Rosetta para serem executados.
À medida que a data de fim da vida útil do Nó 16 avançou, iniciamos o trabalho para executar tarefas com o Nó 20.
Limites do Azure Pipeline aumentados para alinhar com o tamanho máximo de 4 MB do modelo do ARM (Azure Resource Manager).
Você pode usar a tarefa de Implantação de Modelo do Azure Resource Manager para criar a infraestrutura do Azure. Em resposta aos seus comentários, aumentamos o limite de integração do Azure Pipelines de 2 MB para 4 MB. Isso se alinhará com o tamanho máximo dos Modelos do ARM de 4 MB , resolvendo restrições de tamanho durante a integração de modelos grandes.
A tarefa AzureRmWebAppDeployment dá suporte à autenticação de ID do Microsoft Entra
As tarefas AzureRmWebAppDeploymentV3 e AzureRmWebAppDeployment@4 foram atualizadas para dar suporte ao Serviço de Aplicativo com a autenticação básica desabilitada. Se a autenticação básica estiver desabilitada no Serviço de Aplicativo, as tarefas AzureRmWebAppDeploymentV3/4 usarão a autenticação de ID do Microsoft Entra para executar implantações no ponto de extremidade Kudu do Serviço de Aplicativo. Isso requer uma versão recente do msdeploy.exe instalada no agente, que é o caso dos agentes hospedados windows-2022/windows-latest (consulte a referência da tarefa).
Substituição desabilitada do status da política de cobertura de código para Falha quando a compilação está falhando
Anteriormente, o status da política de cobertura de código era substituído por 'Falha' se o build na PR estivesse falhando. Este foi um bloqueador para alguns de vocês que tinham a compilação como uma verificação opcional e a política de cobertura de código como uma verificação obrigatória para PRs, resultando no bloqueio de PRs.
Agora, a política de cobertura de código não será substituída por 'Falha' se o build falhar. Esse recurso será habilitado para todos os clientes.
Artifacts
Apresentando o suporte do Azure Artifacts para Caixas de Carga
Temos o prazer de anunciar que o Azure Artifacts agora oferece suporte nativo para caixas de carga. Esse suporte inclui paridade de recursos em relação aos nossos protocolos existentes, além de crates.io estar disponível como uma fonte upstream. Os desenvolvedores e equipes do Rust agora podem consumir, publicar, gerenciar e compartilhar suas caixas de carga sem problemas, tudo isso enquanto usam a infraestrutura robusta do Azure e permanecem no ambiente familiar do Azure DevOps.
Anúncio de substituição para tarefas de pipeline de Restauração do NuGet v1 e Instalador do NuGet v0
Se você estiver usando as tarefas de pipeline Restauração do NuGet v1 e Instalador do NuGet v0, faça a transição imediatamente para a tarefa de pipeline NuGetCommand@2. Você começará a receber alertas em seus pipelines em breve, se a transição não tiver sido feita. Se nenhuma ação for tomada, a partir de 27 de novembro de 2023, suas compilações resultarão em falha.
Suporte do Azure Artifacts para auditoria npm
O Azure Artifacts agora dá suporte npm audit a comandos e npm audit fix comandos. Esse recurso permite que os usuários analisem e corrijam as vulnerabilidades de seus projetos atualizando automaticamente as versões de pacotes inseguros. Para saber mais, visite Usar a auditoria npm para detectar e corrigir vulnerabilidades de pacote.
Reporting
Nova experiência de diretório do painel
Ouvimos seus comentários e estamos entusiasmados em apresentar a nova experiência do diretório Dashboard. Ele não apenas apresenta um design de interface do usuário moderno, mas também permite classificar por cada coluna, com a adição da coluna Última configuração . Esta coluna fornecerá melhores insights sobre o uso geral do painel em sua coleção de projetos. Além disso, agora você pode filtrar por painéis no nível da equipe ou do projeto, permitindo acessar apenas a lista do que precisa ver enquanto oculta os painéis que não deseja visualizar.
Experimente agora e deixe-nos saber o que você pensa em nossa comunidade Azure DevOps
Filtragem de item de trabalho
Temos o prazer de anunciar a filtragem de gráfico de item de trabalho. Esse recurso permitirá que você passe o mouse sobre o gráfico de item de trabalho para obter uma visão geral rápida e faça uma busca detalhada em segmentos de gráfico específicos para obter insights detalhados. Você não precisa mais criar consultas personalizadas para acessar os dados exatos de que precisa. Agora você pode mergulhar em seus itens de trabalho em gráficos de item de trabalho com apenas alguns cliques.
Seu feedback é inestimável para moldar o futuro desse recurso. Experimente agora e deixe-nos saber o que você pensa em nossa comunidade do Azure DevOps.
Resultados de cobertura de código para pastas
Os resultados para a cobertura de código agora estão disponíveis para cada arquivo e pasta individual, em vez de apenas como um número de nível superior. A exibição de cobertura de código aparece quando o botão Modo de exibição de pasta é alternado. Nesse modo, você pode fazer uma busca detalhada e ver a cobertura de código para essa subárvore selecionada. Use o botão de alternância para alternar entre as visualizações nova e antiga.
Test Plans
Cópia rápida e importação com plano de teste ou ID do pacote
Agora você pode lidar com vários planos de teste no Azure Test Plans com facilidade! Reconhecendo os desafios enfrentados anteriormente com longos menus suspensos para importar, copiar ou clonar casos de teste, especialmente para planos ou suítes extensas, tomamos medidas para simplificar seu fluxo de trabalho.
Temos o prazer de anunciar o recurso Test Plan e Suite ID Search. Insira seu Plano de Teste ou ID do Suite para importação ou cópia rápida de Casos de Teste sem atrasos. Esta atualização faz parte do nosso compromisso contínuo de melhorar sua experiência de gerenciamento de testes, tornando-a mais intuitiva e menos demorada.
Atualização para o Azure Test Runner
Temos o prazer de compartilhar que o Azure Test Runner foi atualizado para uma versão mais recente. Esta atualização melhora a estabilidade e o desempenho, permitindo que você execute seus testes sem interrupções ou atrasos. Não há mais suporte para a versão mais antiga do Azure Test Runner. Para obter o melhor desempenho e confiabilidade de suas operações de teste, recomendamos que você atualize para a versão mais recente o mais rápido possível.
Novidades
- Estabilidade e desempenho aprimorados: Fizemos melhorias significativas no Test Runner, resolvendo problemas que alguns usuários enfrentaram. Essa atualização garante um processo de teste mais confiável, minimizando interrupções em seu trabalho.
- Prompt de atualização: para tornar a transição para a nova versão perfeita, você encontrará um prompt para atualizar. Isso garante que todos possam mudar facilmente para a versão aprimorada conforme sua conveniência, aprimorando a compatibilidade e o desempenho.
Comentários
Adoraríamos ouvir o que você tem para nos dizer! Você pode relatar um problema ou fornecer uma ideia e rastreá-la por meio da Comunidade de Desenvolvedores e obter conselhos sobre o Stack Overflow.