- Desenvolvimento, por onde começar
- Execução do projeto
- Estrutura
- Dependências
- Build e testes
- NuGet privado
- CI/CD
- README
Passos para execução do projeto:
-
Abrir Prompt de Comando de sua preferência no modo Administrador (CMD ou PowerShell);
-
Criar pasta para o projeto no local desejado;
-
Executar os seguintes comandos;
dotnet new -i Wiz.Dotnet.Template.API.DataDriven
dotnet new wizapidatadriven -n [NomeProjeto]
-
Executar comando para configurar certificado de desenvolvimento na sua máquina e permitir que a aplicação rode em modo (HTTPS);
dotnet dev-certs https --trust
-
Incluir configurações de varíaveis de ambiente no caminho abaixo:
├── 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/"
},
"HealthChecks-UI": {
"HealthChecks": [
{
"Name": "Customer DB Health",
"Uri": "https://localhost:5001/health"
}
],
"Webhooks": [],
"EvaluationTimeOnSeconds": 30,
"MinimumSecondsBetweenFailureNotifications": 60,
"HealthCheckDatabaseConnectionString": "Data Source=%APPDATA%\\healthchecksdb"
}
}
- (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.
- 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:
{
"iisSettings": {
"windowsAuthentication": false,
"anonymousAuthentication": true,
"iisExpress": {
"applicationUrl": "http://localhost:49657/",
"sslPort": 0
}
},
"$schema": "http://json.schemastore.org/launchsettings.json",
"profiles": {
"IIS Express": {
"commandName": "IISExpress",
"launchBrowser": true,
"launchUrl": "swagger",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
},
"Wiz.Template.API": {
"commandName": "Project",
"launchBrowser": true,
"launchUrl": "swagger",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
},
"applicationUrl": "https://localhost:5001;http://localhost:5000"
}
}
}
- Abra a janela package Manager Console e execute dotnet ef database update
- (Recomendado) Instalar extensões para desenvolvimento:
- ASP.NET core VS Code Extension Pack
- Azure Functions
- GitLens — Git supercharged
- NuGet Package Manager
- vscode-icons
- (Recomendado) Instalar extensões para testes:
- 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
- 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
- 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
- Preencher variáveis de ambiente no arquivo docker-compose-override.yml caso utilize autenticação no seu projeto:
environment:
- WizID:Authority=URL_SSO
- WizID:Audience=URL_SSO
- Executar comando na raiz do projeto:
docker-compose up -d
- Se fizer alterações no prjeto precisará buildar novamente a imagem que foi criada:
docker-compose up -d --build
- logs de execução:
docker-compose logs
- Parar e remover container:
docker-compose down
- O container da api irá rodar em (HTTP) o chrome pode esta configurado para redirecionar requisições http para https, se isso estiver acontecendo execute os passos abaixo:
- chrome://net-internals/#hsts - copie e cole na barra de pesquisa do chrome.
- Em Delete domain security policies, digite localhost e clique em delete.
Padrão das camadas do projeto:
- Wiz.[NomeProjeto].API: responsável pela camada de disponibilização dos endpoints da API e comunicação com serviços externo ou repositórios de dados;
- Wiz.[NomeProjeto].Integration.Tests: responsável pela camada de testes de integração dos projetos.
- 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].API (projeto)
├── test
├── Wiz.[NomeProjeto].Integration.Tests (projeto)
├── Wiz.[NomeProjeto].Unit.Tests (projeto)
├── Wiz.[NomeProjeto] (solução)
- Obrigatoriedade de não diminuir os testes de cobertura.
- Comandos para geração de build:
- Debug: Executar via Test Explorer (adicionar breakpoint)
- Release: Executar via Test Explorer (não adicionar breakpoint)
-
Ativar funcionalidade Live Unit Testing para executar testes em tempo de desenvolvimento (execução) do projeto.
-
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.
- Executar task de teste desejada:
- test - Executar projeto de testes
- test with coverage - Executar projeto de testes com cobertura
- 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):
-
Abrir pasta scripts;
-
Executar comando:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine
- Executar testes e relatório de testes:
.\code_coverage.ps1
-
-
Shell (Linux/Mac):
-
Abrir pasta scripts;
-
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.
- 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>
- É necessário adicionar a chave do projeto criado no sonar dentro do seu arquivo azure-pipelines.yml va variável projectKey conforme abaixo:
variables:
BuildConfiguration: 'Release'
RestoreBuildProjects: '**/*.csproj'
RestoreBuildProjectsTest: '**/*[Tt]ests/*.csproj'
projectKey: '$(Build.Repository.Name)'
# Necessário caso há Wiz.Common (Nuget)
#wizCrossFeed: '09b2821a-2950-4eff-a722-dbc8adf4da55'
- O GUID pode ser coletado no arquivo da solution ou criado pelo site: https://www.guidgenerator.com/.
- Adicionar url do NuGet privado no caminho do menu abaixo:
Tools -> NuGet Package Manager -> Package Sources
-
Abrir Prompt de Comando de sua preferência (CMD ou PowerShell) ou utilizar o terminal do Visual Studio Code;
-
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)
-
Localizar source (src) do projeto desejado para instalar o NuGet;
-
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
- 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.
- 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.