DevOps4UA

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

Jenkins

Source: Dev.to | Jan 08, 2026 (UTC)

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ê:

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

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:

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:

No portal do Azure:

2.2 Banco de dados

Dentro do servidor:

2.3 Firewall do SQL Server

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

Você precisa configurar: Networking → Firewall rules

Opções:

⚠️ Sem isso:

👉 Em produção real:

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:

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:

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:

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:

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:

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

For further actions, you may consider blocking this person and/or reporting abuse

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Читайте також