Como configurar uma política de check-in fechado usando o Azure DevOps

Um check-in fechado é um processo que restringe os desenvolvedores de mesclar um código quebrado no sistema de controle de origem - algo que toda empresa de software deseja estabelecer. Ao fazê-lo, as organizações precisam fazer várias perguntas:

  • Como se configura uma política de check-in fechado?
  • Quais são as práticas recomendadas a serem seguidas ao configurar esta política?
  • Quais são os benefícios para uma organização se esta política estiver bem estabelecida?
  • Quais são os recursos que podem ser configurados?

Este guia esclarecerá essas questões e esclarecerá como configurar diferentes políticas que podem ser configuradas para um processo de check-in fechado usando o Azure DevOps Services (anteriormente conhecido como VSTS).

Vamos começar aprendendo sobre políticas de ramificação e recursos relacionados.

Proteja suas filiais

O Azure DevOps tem um recurso chamado políticas de ramificação usadas para configurar um processo de check-in fechado. As políticas de filiais ajudam as equipes a proteger suas ramificações importantes de desenvolvimento. As políticas são aplicadas na equipe para melhorar a qualidade do código e ajudar a melhorar o gerenciamento dos padrões de código.

Em poucas palavras, você pode configurar as seguintes políticas:

  • Configurar políticas de filial
  • Exigir um número mínimo de revisores
  • Verificar itens de trabalho vinculados
  • Verifique a resolução do comentário
  • Validação de compilação
  • Incluir revisores de código automaticamente

Agora é hora de mergulhar fundo em cada política e aproveitar o poder do recurso de políticas de filiais para um processo de check-in fechado. As seções a seguir explicarão cada política em detalhes e fornecerão dicas para configurar políticas de ramificação.

Configurar políticas de filial

Para configurar políticas de branch, navegue até Repos > Branches , conforme mostrado na figura abaixo.

Navegação do menu de ramificações

Ao clicar na opção Filiais , ele inicia a página Filiais no portal da web, conforme mostrado na figura abaixo.

Página do portal da web de filiais

Selecione o botão e, em seguida, selecione Políticas de Filial no menu de contexto.

Menu de contexto de ramificação

Agora você pode configurar várias políticas na página de configuração. Consulte o restante do guia para obter a descrição de cada tipo de política.

Configurar o número mínimo de revisores

A política de exigir um número mínimo de revisores ajuda a maioria dos projetos de desenvolvimento de software. A revisão de código é uma prática recomendada a ser seguida e a maneira recomendada de garantir a melhoria da qualidade do código.

Para exigir que as equipes revisem suas alterações antes de concluir uma pull request, selecione a opção Exigir um número mínimo de revisores . Recomenda-se definir um mínimo de dois revisores como prática recomendada.

Essa política também ajuda todos os setores de software antes que o código do desenvolvedor seja mesclado ao branch master. Ele fornece várias opções para configurar a política junto com um número mínimo de revisores. Vamos explorar essas opções em detalhes.

Número mínimo necessário de dois revisores

Permitir que os solicitantes aprovem suas próprias alterações

Se esta opção for selecionada, o criador do pull request pode votar em sua aprovação. Caso contrário, o voto deles não contará para o número mínimo de revisores . Recomenda-se que o criador da solicitação pull não possa votar em sua própria solicitação.

Proibir o pusher mais recente de aprovar suas próprias alterações

Se você habilitar essa opção, ocorrerá a segregação de funções forçada. Isso significa que o push mais recente automaticamente faz com que o voto do pusher não conte.

Permitir a conclusão mesmo que alguns revisores votem para aguardar ou rejeitar

Se esta opção não estiver habilitada, o pull do código de solicitação não será mesclado ao branch master se alguns revisores votarem para rejeitá-lo. Recomenda-se não habilitar esta opção a menos que seja necessário.

Redefinir votos do revisor de código quando houver novas alterações

Essa opção oferece a capacidade de redefinir os votos dos revisores de código se o criador da solicitação pull enviar novas alterações para o mesmo PR. Dessa forma, os revisores ficam a par das novas mudanças e podem decidir aprovar ou não a PR.

Configurar verificação de itens de trabalho associados

Essa política fornece a capacidade de configurar uma associação entre uma solicitação pull e um item de trabalho para garantir que as próximas alterações em sua ramificação tenham a rastreabilidade adequada.

Você pode configurar essa política conforme necessário ou opcional para verificar itens de trabalho associados na solicitação pull. Recomenda-se configurar essa opção conforme necessário, o que significa bloquear a conclusão da solicitação pull, a menos que o usuário tenha pelo menos um item de trabalho vinculado.

Verificar itens de trabalho vinculados

Aplicar resolução de comentários

Da mesma forma, as políticas de ramificação fornecem a capacidade de impedir que solicitações de pull sejam concluídas enquanto quaisquer comentários estiverem ativos.

O Azure DevOps oferece duas opções: obrigatório e opcional . Recomenda-se configurar esta opção conforme necessário para que o usuário não possa concluir sua PR a menos que todos os comentários sejam resolvidos.

Verifique a resolução do comentário

Configurar validação de compilação

A configuração da validação de compilação é uma parte crucial do processo de check-in fechado. Essa opção oferece mais controle sobre a qualidade do código, protegendo o código usando vários processos, como exigir que todos os testes de unidade ou integração sejam aprovados, o portão de qualidade do código do SonarQube seja aprovado, a construção tenha sido bem-sucedida etc.

A política de compilação reduz as pausas e mantém o resultado do seu teste passando. Ele pode ser muito bem integrado à Integração Contínua (CI) em suas ramificações de desenvolvimento para detectar problemas antecipadamente.

Validação de compilação

É um pré-requisito ter um pipeline de compilação funcionando antes de configurar essa política. A política de compilação precisa de um pipeline que é acionado quando a ramificação de origem é atualizada. Esta política oferece opções durante a configuração:

1. Opções de gatilho

  • Automático (recomendado): os gatilhos são compilados automaticamente quando a ramificação de origem é atualizada
  • Manual: o usuário precisa acionar a compilação manualmente conforme necessário

2. Requisito da política

  • Obrigatório (recomendado): a compilação deve ser bem-sucedida para concluir a solicitação pull
  • Opcional: a falha de compilação não bloqueará a conclusão da solicitação pull

3. Expiração de compilação

  • Imediato: quando o branch principal é atualizado
  • Duração (recomendado): Após N número de horas se a filial principal tiver sido atualizada
  • Nunca: a compilação nunca expira

Incluir revisores de código automaticamente

Esse filtro fornece a capacidade de incluir revisores de código automaticamente quando uma nova solicitação pull é enviada. Para configurar essa política, uma equipe precisa decidir o nome do revisor e os requisitos da política, conforme mostrado na figura abaixo.

Incluir revisores de código automaticamente

  • Se você selecionar Obrigatório , uma solicitação pull não poderá ser concluída até que todos os usuários adicionados como revisor tenham aprovado as alterações.
  • Se você selecionar Opcional , uma solicitação pull não exigirá sua aprovação para concluir a solicitação pull.
  • Você pode configurar Permitir que os solicitantes aprovem suas próprias alterações .
  • Quando todas as condições acima forem atendidas, uma solicitação pull poderá ser concluída.

Neste guia, você aprendeu sobre como configurar um processo de check-in fechado no Azure DevOps usando o recurso de políticas de ramificação. No geral, isso ajuda uma equipe a configurar melhores processos, melhorar a qualidade do código e focar nos problemas de negócios.

What is GEEK

Buddha Community

How to Extend your DevOps Strategy For Success in the Cloud?

DevOps and Cloud computing are joined at the hip, now that fact is well appreciated by the organizations that engaged in SaaS cloud and developed applications in the Cloud. During the COVID crisis period, most of the organizations have started using cloud computing services and implementing a cloud-first strategy to establish their remote operations. Similarly, the extended DevOps strategy will make the development process more agile with automated test cases.

According to the survey in EMEA, IT decision-makers have observed a 129%* improvement in the overall software development process when performing DevOps on the Cloud. This success result was just 81% when practicing only DevOps and 67%* when leveraging Cloud without DevOps. Not only that, but the practice has also made the software predictability better, improve the customer experience as well as speed up software delivery 2.6* times faster.

3 Core Principle to fit DevOps Strategy

If you consider implementing DevOps in concert with the Cloud, then the

below core principle will guide you to utilize the strategy.

  • It is indispensable to follow a continuous process, including all stages from Dev to deploy with the help of auto-provisioning resources of the target platform.
  • The team always keeps an eye on major and minor application changes that can typically appear within a few hours of development to operation. However, the support of unlimited resource provisioning is needed at the stage of deployment.
  • Cloud or hybrid configuration can associate this process, but you must confirm that configuration should support multiple cloud brands like Microsoft, AWS, Google, any public and private cloud models.

Guide to Remold Business with DevOps and Cloud

Companies are now re-inventing themselves to become better at sensing the next big thing their customers need and finding ways with the Cloud based DevOps to get ahead of the competition.

#devops #devops-principles #azure-devops #devops-transformation #good-company #devops-tools #devops-top-story #devops-infrastructure

Nabunya  Jane

Nabunya Jane

1624939448

A side-by-side comparison of Azure DevOps and GitHub

Collaboration is a crucial element in software development; having the right collaboration tools can make a difference and boost the entire team’s productivity. Microsoft introduced its Application Lifecycle Management product with Team Foundation Server (aka TFS) on March 16th, 2006. This software had to be installed on a server within your network and had a user-based license. To reduce the complexity of setting up and maintaining the server, Microsoft released Visual Studio Online–an Azure-based, server-hosted version of TFS. Microsoft manages and administers the servers as well as taking care of backups. To clarify its commitment to agile and DevOps, Microsoft rebranded Visual Studio Online in 2015 as Visual Studio Team Services and later as Azure DevOps in 2018.

Since its beginning, this platform has changed significantly. For example, it introduced a customizable, task-based build service, release gates, and much more. Many organizations across the world made a significant investment to run their businesses on Azure DevOps. For this reason, after Microsoft announced the acquisition of GitHub in mid-2018, GitHub announced its automated workflow system, which is much like Azure Pipelines. It’s called GitHub Actions. Due to the switch, some companies became afraid of having to migrate their practices again. In the past few months, I have gotten several questions about whether it is still worth starting new projects on Azure DevOps, especially after the release of features like GitHub Advanced Security and GitHub Codespaces (similar to Visual Studio Codespaces). In this article, I’ll clarify the differences between these two platforms, and I’ll give you some advice on how you should be using them to your advantage.

Data Residency

To meet the needs of companies that want to keep their data within their network, both GitHub and Azure DevOps provide a server version of their platform. GitHub version is called GitHub Enterprise Server, and the Azure DevOps version is called Azure DevOps Server. Both versions require the client to install and maintain both software and machine.

On the other hand, there is a critical difference between their cloud-hosted version. While Azure DevOps Service allows you to choose the Azure region, which is closes to your organization’s location, to decrease the eventuality of networking latency during the creation of your organization (collection of projects). GitHub doesn’t provide this feature.

Project management and bug tracking

GitHub

At the core of GitHub project management, we can find the issues. This task can be used to track any work item, from feature to bugs, and can be sorted into a Kanban-style board for easy consultation. The issue’s description also supports markdown syntax. Adding a specific keyword #issue-number (ex: #3) can associate the issue with another one. Each issue can be assigned to multiple developers, be linked to pull requests, and have various labels assigned to it. One can link a pull request to an issue to show that a fix is in progress and automatically close the issue when someone merges the pull request.

GitHub Kanban board

  • Lastly, multiple issues can be grouped into milestones that will give immediate feedback about the completion percentage. Milestones can also include a due date.

#azure-devops #microsoft #azure #github #azure devops #azure devops and github

Como configurar uma política de check-in fechado usando o Azure DevOps

Um check-in fechado é um processo que restringe os desenvolvedores de mesclar um código quebrado no sistema de controle de origem - algo que toda empresa de software deseja estabelecer. Ao fazê-lo, as organizações precisam fazer várias perguntas:

  • Como se configura uma política de check-in fechado?
  • Quais são as práticas recomendadas a serem seguidas ao configurar esta política?
  • Quais são os benefícios para uma organização se esta política estiver bem estabelecida?
  • Quais são os recursos que podem ser configurados?

Este guia esclarecerá essas questões e esclarecerá como configurar diferentes políticas que podem ser configuradas para um processo de check-in fechado usando o Azure DevOps Services (anteriormente conhecido como VSTS).

Vamos começar aprendendo sobre políticas de ramificação e recursos relacionados.

Proteja suas filiais

O Azure DevOps tem um recurso chamado políticas de ramificação usadas para configurar um processo de check-in fechado. As políticas de filiais ajudam as equipes a proteger suas ramificações importantes de desenvolvimento. As políticas são aplicadas na equipe para melhorar a qualidade do código e ajudar a melhorar o gerenciamento dos padrões de código.

Em poucas palavras, você pode configurar as seguintes políticas:

  • Configurar políticas de filial
  • Exigir um número mínimo de revisores
  • Verificar itens de trabalho vinculados
  • Verifique a resolução do comentário
  • Validação de compilação
  • Incluir revisores de código automaticamente

Agora é hora de mergulhar fundo em cada política e aproveitar o poder do recurso de políticas de filiais para um processo de check-in fechado. As seções a seguir explicarão cada política em detalhes e fornecerão dicas para configurar políticas de ramificação.

Configurar políticas de filial

Para configurar políticas de branch, navegue até Repos > Branches , conforme mostrado na figura abaixo.

Navegação do menu de ramificações

Ao clicar na opção Filiais , ele inicia a página Filiais no portal da web, conforme mostrado na figura abaixo.

Página do portal da web de filiais

Selecione o botão e, em seguida, selecione Políticas de Filial no menu de contexto.

Menu de contexto de ramificação

Agora você pode configurar várias políticas na página de configuração. Consulte o restante do guia para obter a descrição de cada tipo de política.

Configurar o número mínimo de revisores

A política de exigir um número mínimo de revisores ajuda a maioria dos projetos de desenvolvimento de software. A revisão de código é uma prática recomendada a ser seguida e a maneira recomendada de garantir a melhoria da qualidade do código.

Para exigir que as equipes revisem suas alterações antes de concluir uma pull request, selecione a opção Exigir um número mínimo de revisores . Recomenda-se definir um mínimo de dois revisores como prática recomendada.

Essa política também ajuda todos os setores de software antes que o código do desenvolvedor seja mesclado ao branch master. Ele fornece várias opções para configurar a política junto com um número mínimo de revisores. Vamos explorar essas opções em detalhes.

Número mínimo necessário de dois revisores

Permitir que os solicitantes aprovem suas próprias alterações

Se esta opção for selecionada, o criador do pull request pode votar em sua aprovação. Caso contrário, o voto deles não contará para o número mínimo de revisores . Recomenda-se que o criador da solicitação pull não possa votar em sua própria solicitação.

Proibir o pusher mais recente de aprovar suas próprias alterações

Se você habilitar essa opção, ocorrerá a segregação de funções forçada. Isso significa que o push mais recente automaticamente faz com que o voto do pusher não conte.

Permitir a conclusão mesmo que alguns revisores votem para aguardar ou rejeitar

Se esta opção não estiver habilitada, o pull do código de solicitação não será mesclado ao branch master se alguns revisores votarem para rejeitá-lo. Recomenda-se não habilitar esta opção a menos que seja necessário.

Redefinir votos do revisor de código quando houver novas alterações

Essa opção oferece a capacidade de redefinir os votos dos revisores de código se o criador da solicitação pull enviar novas alterações para o mesmo PR. Dessa forma, os revisores ficam a par das novas mudanças e podem decidir aprovar ou não a PR.

Configurar verificação de itens de trabalho associados

Essa política fornece a capacidade de configurar uma associação entre uma solicitação pull e um item de trabalho para garantir que as próximas alterações em sua ramificação tenham a rastreabilidade adequada.

Você pode configurar essa política conforme necessário ou opcional para verificar itens de trabalho associados na solicitação pull. Recomenda-se configurar essa opção conforme necessário, o que significa bloquear a conclusão da solicitação pull, a menos que o usuário tenha pelo menos um item de trabalho vinculado.

Verificar itens de trabalho vinculados

Aplicar resolução de comentários

Da mesma forma, as políticas de ramificação fornecem a capacidade de impedir que solicitações de pull sejam concluídas enquanto quaisquer comentários estiverem ativos.

O Azure DevOps oferece duas opções: obrigatório e opcional . Recomenda-se configurar esta opção conforme necessário para que o usuário não possa concluir sua PR a menos que todos os comentários sejam resolvidos.

Verifique a resolução do comentário

Configurar validação de compilação

A configuração da validação de compilação é uma parte crucial do processo de check-in fechado. Essa opção oferece mais controle sobre a qualidade do código, protegendo o código usando vários processos, como exigir que todos os testes de unidade ou integração sejam aprovados, o portão de qualidade do código do SonarQube seja aprovado, a construção tenha sido bem-sucedida etc.

A política de compilação reduz as pausas e mantém o resultado do seu teste passando. Ele pode ser muito bem integrado à Integração Contínua (CI) em suas ramificações de desenvolvimento para detectar problemas antecipadamente.

Validação de compilação

É um pré-requisito ter um pipeline de compilação funcionando antes de configurar essa política. A política de compilação precisa de um pipeline que é acionado quando a ramificação de origem é atualizada. Esta política oferece opções durante a configuração:

1. Opções de gatilho

  • Automático (recomendado): os gatilhos são compilados automaticamente quando a ramificação de origem é atualizada
  • Manual: o usuário precisa acionar a compilação manualmente conforme necessário

2. Requisito da política

  • Obrigatório (recomendado): a compilação deve ser bem-sucedida para concluir a solicitação pull
  • Opcional: a falha de compilação não bloqueará a conclusão da solicitação pull

3. Expiração de compilação

  • Imediato: quando o branch principal é atualizado
  • Duração (recomendado): Após N número de horas se a filial principal tiver sido atualizada
  • Nunca: a compilação nunca expira

Incluir revisores de código automaticamente

Esse filtro fornece a capacidade de incluir revisores de código automaticamente quando uma nova solicitação pull é enviada. Para configurar essa política, uma equipe precisa decidir o nome do revisor e os requisitos da política, conforme mostrado na figura abaixo.

Incluir revisores de código automaticamente

  • Se você selecionar Obrigatório , uma solicitação pull não poderá ser concluída até que todos os usuários adicionados como revisor tenham aprovado as alterações.
  • Se você selecionar Opcional , uma solicitação pull não exigirá sua aprovação para concluir a solicitação pull.
  • Você pode configurar Permitir que os solicitantes aprovem suas próprias alterações .
  • Quando todas as condições acima forem atendidas, uma solicitação pull poderá ser concluída.

Neste guia, você aprendeu sobre como configurar um processo de check-in fechado no Azure DevOps usando o recurso de políticas de ramificação. No geral, isso ajuda uma equipe a configurar melhores processos, melhorar a qualidade do código e focar nos problemas de negócios.

Osborne  Durgan

Osborne Durgan

1591093172

Create, Build, Deploy and Configure an Azure Function with Azure DevOps and Azure CLI

This post shows how to create, build, deploy and configure an Azure Function using Azure DevOps, Azure CLI and Powershell. An Azure Function is created in Azure using Azure DevOps with Azure CLI and Powershell. The Azure Function (V3) project is created and built using Visual Studio and C#. This project is deployed to the Azure infrastructure using a second Azure DevOps Pipeline. The Azure Function configuration settings is configured to use Azure Key Vault for secrets.

#asp.net core #azure #devops #.net core #azure devops #azure functions #cli #powershell