zamabraga / api-wiz-template

Wiz DotNet Core API Template

Wiz - API

• Desenvolvimento, por onde começar
• Execução do projeto
• Estrutura
• Dependências
• Build e testes
• NuGet privado
• CI/CD
• README

Desenvolvimento, por onde começar

Passos para execução do projeto:

1. Abrir Prompt de Comando de sua preferência (CMD ou PowerShell);

2. Criar pasta para o projeto no local desejado;

3. Executar os seguintes comandos;

dotnet new -i Wiz.Dotnet.Template.API
dotnet new wizapi -n [NomeProjeto]

4. Executar comando para configurar aplicação em modo (HTTPS);

dotnet dev-certs https --trust

5. Incluir configurações de varíaveis de ambiente no caminho abaixo:

Local

├── src (pasta física)
  ├── Wiz.[NomeProjeto].API (projeto)
    ├── appsettings.{ENVIRONMENT}.json

Dentro do arquivo local.settings.json, há o conteúdo para modificação das variáveis:

{
  "ApplicationInsights": {
    "InstrumentationKey": "KEY_APPLICATION_INSIGHTS"
  },
  "Azure": {
    "KeyVaultUrl": "URL_KEY_VAULT"
  },
  "ConnectionStrings": {
    "CustomerDB": "CONNECTION_DATABASE"
  },
  "WizID": {
    "Authority": "URL_SSO",
    "Audience": "SSO_SCOPE"
  },
  "API": {
    "ViaCEP": "https://viacep.com.br/ws/"
  },
  "Webhook": {
    "Teams": "{URL Webhook do Teams}"
  },
  "HealthChecks-UI": {
    "HealthChecks": [
    ],
    "Webhooks": [],
    "EvaluationTimeOnSeconds": 30,
    "MinimumSecondsBetweenFailureNotifications": 60
  }
}

6. (Opcional) Inserir chave do Application Insights conforme configurado no Azure no arquivo appsettings.{ENVIRONMENT}.json.

Caso não há chave de configuração no Azure, não é necessário inserir para executar o projeto local.

Docker

├── Dockerfile

Dentro do arquivo Dockerfile, há o conteúdo para modificação das variáveis:

ENV ApplicationInsights:InstrumentationKey=KEY_APPLICATION_INSIGHTS
ENV Azure:KeyVaultUrl=URL_KEY_VAULT
ENV ConnectionStrings:CustomerDB=URL_DB
ENV WizID:Authority=URL_SSO
ENV WizID:Audience=SSO_SCOPE

Execução do projeto

Visual Studio

1. Executar projeto via Kestrel;

Executar o projeto via Kestrel facilita a troca de ambientes (environments) e a verificação de logs em execução da aplicação em projetos .NET Core. Os ambientes podem ser configurados dentro das propriedades do projeto, conforme caminho abaixo:

├── Wiz.[NomeProjeto] (solução)
  ├── Wiz.[NomeProjeto].API (projeto)
    ├── Properties (pasta física)
      ├── launchSettings.json

Dentro do arquivo launchSettings.json, há o conteúdo que indica a configuração de ambiente via Kestrel:

    "Wiz.[NomeProjeto].API": {
      "commandName": "Project",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "applicationUrl": "https://localhost:5001;http://localhost:5000"
    }

Visual Studio Code

1. (Recomendado) Instalar extensões para desenvolvimento:

• ASP.NET core VS Code Extension Pack
• Azure Functions
• GitLens — Git supercharged
• NuGet Package Manager
• vscode-icons

2. (Recomendado) Instalar extensões para testes:

• .NET Core Test Explorer
• Coverage Gutters

3. Executar projeto via Kestrel (Tecla F5);

Por padrão, todo projeto executado no Visual Studio Code é executado via Kestrel (Tecla F5). Os ambientes podem ser configurados dentro das propriedades do projeto, conforme caminho abaixo:

├── .vscode (pasta física)
  ├── launch.json

4. Utilizar a função task para executar ações dentro do projeto. A função está presente no caminho do menu abaixo:

Terminal -> Run Task

5. Selecionar a função task a ser executada no projeto:

• clean - Limpar solução
• restore - Restaurar pacotes da solução
• build - Compilar pacotes da solução
• test - Executar projeto de testes
• test with coverage - Executar projeto de testes com cobertura

Docker

1. Executar comando na raiz do projeto:

docker-compose up -d

2. logs de execução:

docker-compose logs

3. Parar e remover container:

docker-compose down

Estrutura

Padrão das camadas do projeto:

1. Wiz.[NomeProjeto].Domain: domínio da aplicação, responsável de manter as regras de negócio para a API;
2. Wiz.[NomeProjeto].Infra: camada mais baixa, para acesso a dados, infraestrutura e serviços externos;
3. Wiz.[NomeProjeto].API: responsável pela camada de disponibilização dos endpoints da API;
4. Wiz.[NomeProjeto].Integration.Tests: responsável pela camada de testes de integração dos projetos.
5. Wiz.[NomeProjeto].Unit.Tests: responsável pela camada de testes unitários dos projetos.

Formatação do projeto dentro do repositório:

├── src 
  ├── Wiz.[NomeProjeto].Domain (projeto)
  ├── Wiz.[NomeProjeto].Infra (projeto)
  ├── Wiz.[NomeProjeto].API (projeto)
├── test
  ├── Wiz.[NomeProjeto].Integration.Tests (projeto)
  ├── Wiz.[NomeProjeto].Unit.Tests (projeto)
├── Wiz.[NomeProjeto] (solução)

Há possibilidade de inclusão do projeto de testes do tipo Aceitação (e2e) caso necessidade, com o nome: Wiz.[NomeProjeto].Acceptance.Tests

Dependências

• ASP.NET Core
• Patterns RESTful

Build e testes

• Obrigatoriedade de não diminuir os testes de cobertura.

Visual Studio

1. Comandos para geração de build:

• Debug: Executar via Test Explorer (adicionar breakpoint)
• Release: Executar via Test Explorer (não adicionar breakpoint)

2. Ativar funcionalidade Live Unit Testing para executar testes em tempo de desenvolvimento (execução) do projeto.

3. Ativar funcionalidade Code Coverage para cobertura de testes.

As funcionalidades Live Unit Testing e Code Coverage estão disponíveis apenas na versão Enterprise do Visual Studio.

Visual Studio Code

1. Executar task de teste desejada:

• test - Executar projeto de testes
• test with coverage - Executar projeto de testes com cobertura

2. Ativar Watch na parte inferior do Visual Studio Code para habilitar cores nas classes que descrevem a cobertura. É necessário executar os testes no modo test with coverage.

Comandos para geração de relatório de testes:

• PowerShell (Windows):

  1. Abrir pasta scripts;

  2. Executar comando:

  Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine
  

  3. Executar testes e relatório de testes:

  .\code_coverage.ps1

• Shell (Linux/Mac):

  1. Abrir pasta scripts;

  2. Executar testes e relatório de testes:

  ./code_coverage.sh

O relatório dos testes são gerados na pasta code_coverage localizada na raiz do projeto.

Sonar

1. Dentro do arquivo dos projetos (.csproj) no campo PropertyGroup, é necessário adicionar um GUID no formato abaixo:

<PropertyGroup>
  <ProjectGuid>{b5c970c2-a7cc-4052-b07b-b599b83fc621}</ProjectGuid>
</PropertyGroup>

2. O GUID pode ser coletado no arquivo da solution ou criado pelo site: https://www.guidgenerator.com/.

NuGet privado

Visual Studio

1. Adicionar url do NuGet privado no caminho do menu abaixo:

Tools -> NuGet Package Manager -> Package Sources

Visual Studio Code

1. Abrir Prompt de Comando de sua preferência (CMD ou PowerShell) ou utilizar o terminal do Visual Studio Code;

2. Executar script Powershell para adicionar permissão do NuGet na máquina local:

• https://github.com/microsoft/artifacts-credprovider/blob/master/helpers/installcredprovider.ps1 (Windows);
• https://github.com/microsoft/artifacts-credprovider/blob/master/helpers/installcredprovider.sh (Linux/Mac)

3. Localizar source (src) do projeto desejado para instalar o NuGet;

4. Executar comando para instalar NuGet privado e seguir instruções;

*dotnet add package [NomePacote] -s https://pkgs.dev.azure.com/[NomeOrganizacao]/_packaging/[NomeProjeto]/nuget/v3/index.json --interactive

CI/CD

• Arquivo de configuração padrão: azure-pipelines.yml.
• Caso há necessidade de incluir mais tasks ao pipeline, verfique a documentação para inclusão: Azure DevOps - Yaml Schema.

README

• Incluir documentação padrão no arquivo README.md.
• Após inclusão da documentação padrão, excluir este arquivo e TODAS as classes indentificadas como exemplo.
  • O serviço para busca de endereço Via CEP assim como o contexto de Customer foi utilizado apenas como exemplo. O uso do serviço Via CEP está disponível no NuGet corporativo.