DEV Community

Cover image for Deploy: Cenário: Azure App Service + Github + SQL Server
Yuri Peixinho
Yuri Peixinho

Posted on

Deploy: Cenário: Azure App Service + Github + SQL Server

#azure #devops #github #sql

Introdução

Deploy não é um botão. É um processo consciente de levar software para o mundo real. Geralmente quando não temos conhecimento sobre os processos de deploy ficamos com algumas questões pendentes em nossa mente:

  • Onde o código roda?
  • Como ele chega lá?
  • Como ele acessa o banco?
  • Como configuro sem expor segredo (secret)?
  • Como atualizo sem quebrar tudo?

Vamos passar por todo esse processo com aplicação em um cenário real.

As peças do cenário que vamos montar

  • Azure App Service: onde a aplicação roda
  • Github: onde seu código vive
  • Github Actions (opcional, mas recomendado): automação de build e deploy
  • Azure SQL Database (SQL Server): onde seus dados ficam 
GitHub (código)
↓
Pipeline (build / deploy)
↓
Azure App Service (API / App)
↓
Azure SQL Database (dados)
Enter fullscreen mode Exit fullscreen mode

1. O que é o Azure App Service?

Como já vimos nos tipos de servidores, podemos dizer que o Azure Service é um serviço gerenciado. Isso significa que você:

  • Não cria servidor
  • Não instala Windows/Linux
  • Configura IIS, Kestrel, Nginx manualmente

1.1 App Service

A plataforma Azure cuida de todas essas questões pra você e quando você cria um App Service, você está definindo

  • Runtime (ex: .NET 8)
  • Plano de hospedagem (CPU / memória / custo)
  • Região (onde o servidor fica)

Que resulta em uma URL pública e um ambiente pronto pra a execução do seu código:

https://minha-api.azurewebsites.net
Enter fullscreen mode Exit fullscreen mode

Nesse momento, não tem código nenhum rodando ainda.

1.2 Como o código chega na Azure? (Github Actions)

Após a configuração do Azure App Service ser concluída precisamos efetivamente subir o nosso código de um determinado repositório para o Azure. Em nossa abordagem vamos utilizar o Github Actions e entender o problema que ele resolve.

1.1.1 Processo manual

Antes do Github Actions, o deploy normalmente era assim:

O desenvolvedor faz o seguinte processo:

  1. Compila local
  2. Publica manualmente
  3. Sobre arquivo por FTP

Esse processo gera problemas como inconsistência, erro humano, falta de histórico e deploys imprevisíveis

1.1.2 Github Actions

Podemos dizer que o GitHub Actions é um robô configurável que roda dentro do GitHub sempre que algo acontece no repositório.

Esse “algo” pode ser:

  • push
  • pull request
  • criação de tag
  • horário agendado

Esse robô pode compilar código, rodar testes, gerar build, fazer deploy, enviar notificações, etc. Isso tudo só acontece porque um workflow é configurado.

1.3 O que é um workflow e o que ele tem a ver com tudo isso?

Um workflow é um arquivo .yml que diz sugere: “Quando X acontecer, execute Y passos nessa ordem”, então, por exemplo:

SE alguém fizer push na branch main
ENTÃO:
  - compile
  - teste
  - publique
  - faça deploy
Enter fullscreen mode Exit fullscreen mode

E esse arquivo fica em:

.github/workflows/deploy.yml
Enter fullscreen mode Exit fullscreen mode

Esse arquivo é código, portanto, o Deploy passa a ser versionado, auditável e repetível.

2. Criando o SQL Server no Azure

Ao criar um banco de dados no Azure, você já vai ter backup automático, alta disponibilidade e sem precisar instalar nada.

Ao final do processo você vai ter o nome do servidor, nome do banco, usuário e senha. Essas informações nunca deve ir no código.

Quando você cria o Azure SQL Database, o Azure cria duas coisas:

2.1 Servidor Lógico (SQL Server)

Não é uma VM (Virtual Machine) e sim um endpoint gerenciado para autenticação e conexões. Esse servidor:

  • Pode ter vários bancos
  • Centraliza segurança
  • Controla firewall

No portal do Azure:

  • Azure SQL → Create
  • Você define:
    • Server name → meu-servidor.database.windows.net
    • Admin login
    • Senha

2.2 Banco de dados

Dentro do servidor:

  • Você cria o banco nomeDoBanco
  • Define
    • Camada (Basic / General Purpose / Business Critical)
    • DTUs / vCores

2.3 Firewall do SQL Server

Por padrão ninguém consegue acessar o banco.

Você precisa configurar: Networking → Firewall rules

Opções:

  • ✔️ Allow Azure services
  • ✔️ Adicionar IP da sua máquina (para migrations locais)

⚠️ Sem isso:

  • App não conecta
  • Migration falha
  • Erro de timeout

👉 Em produção real:

  • Ideal é Private Endpoint
  • Mas para início: firewall simples resolve

3. Connection String, o elo entre a aplicação e o banco

Essa é uma das partes mais importante de todo deploy. Sem essa conexão, nada conecta com a base de dados.

Sem ela:

  • A aplicação sobe ✔️
  • O banco existe ✔️
  • Mas nada se comunica ❌

Ou seja: API no ar, mas toda requisição que depende de dados falha.

3.1 O que você já criou no Azure SQL Database

Ao criar sua base de dados no Azure (SQL Server), você definiu:

  • Nome do servidor
  • Nome da base de dados
  • Admin Login
  • Senha
  • Tipo de autenticação (SQL Authentication)

Essas informações são a base da sua connection string.

3.2 O que é, na prática, uma Connection String?

É um texto que informa à aplicação:

  • Onde está o banco
  • Qual banco acessar
  • Como autenticar
  • Como se comportar durante a conexão

Exemplo genérico:

Server=...
Database=...
User Id=...
Password=...
Enter fullscreen mode Exit fullscreen mode

3.3 De onde vem o valor da Connection String?

No Azure SQL Database:

SQLDatabase
 → Settings
     → Connection strings
Enter fullscreen mode Exit fullscreen mode

Normalmente você verá algo como:

Server=tcp:meuservidor.database.windows.net,1433;
Initial Catalog=MinhaBase;
PersistSecurityInfo=False;
User ID=adminuser;
Password=********;
MultipleActiveResultSets=False;
Encrypt=True;
TrustServerCertificate=False;
Connection Timeout=30;
Enter fullscreen mode Exit fullscreen mode

Copie exatamente essa string e cole no campo Value.

3.4 Agora vamos ligar App → Banco

Essa configuração é feita diretamente no Azure App Service, sem precisar alterar código.

3.4.1 Caminho no Azure Portal 

App Service
 → Settings
 → Configuration
 → Connection strings
Enter fullscreen mode Exit fullscreen mode

Essa área funciona como um cofre de segredos da aplicação.

✅ Mais seguro

✅ Separado do código

✅ Ideal para ambientes (Dev / Homologação / Produção)

3.4.2 Nome da Connection String (Muito Importante)

Se você usa Entity Framework Core, o nome mais comum (e recomendado) é:

DefaultConnection
Enter fullscreen mode Exit fullscreen mode

Esse nome precisa bater exatamente com o que está no seu Program.cs ou appsettings.json.

Exemplo comum no código:

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("DefaultConnection")));
Enter fullscreen mode Exit fullscreen mode

Se o nome for diferente no Azure:

❌ A aplicação sobe

❌ Mas não encontra o banco

❌ Erro clássico: The ConnectionString property has not been initialized

4. Migrações

Agora vem a parte mais importante do deploy com banco. Vamos separar em três trilhas bem práticas:

  1. Migration Manual Local → Azure SQL
  2. Migration via GithubActions → Azure SQL (Pipeline)
  3. Migration por script SQL (práticas usadas por empresas)

4.1. Migration Manual (local → Azure SQL)

Pré-requisitos:

  • Projeto com EF Core
  • Migrations já criadas

Isso não mexe no banco ainda, apenas gera os arquivos C#.

4.2. Liberar o acesso ao banco no Azure

Por padrão, o Azure SQL bloqueia tudo e precisamos autorizar nossa máquina local, sem isso nosso sistema dará o erro: Login failed / Timeout expired

O que isso faz:

  • Autoriza sua máquina local
  • Permite que o dotnet ef conecte no banco remoto

No Portal Azure:

  1. Azure SQL Server
  2. Networking
  3. Firewall rules
  4. Add your client IPv4 address
  5. Save

4.3. Garantir que sua aplicação aponta para o Azure

Garante que seu arquivo appsettings.Development.json está apontando para o SQL Server no azure.

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=tcp:meuservidor.database.windows.net;..."
  }
}
Enter fullscreen mode Exit fullscreen mode

4.4. Executar a migration 

dotnet ef database update
Enter fullscreen mode Exit fullscreen mode

O que acontece por trás:

  1. EF abre conexão com o Azure SQL
  2. Verifica se existe a tabela: 
__EFMigrationsHistory
Enter fullscreen mode Exit fullscreen mode
  • Se não existir → cria
  • Se existir → lê quais migrations já rodaram
  • Compara:
    • Migrations no código
    • Migrations no banco
  • Executa somente as pendentes
  • Registra a versão aplicada

Top comments (0)