Guia de Deploy .NET: do commit ao container em produção

1. Comece pelo básico: ambientes e configuração

Antes de pensar em pipeline, containers ou orquestradores, organize sua aplicação para trabalhar bem com ambientes diferentes (Dev, Homologação, Produção) e configurações externas. O modelo de configuração do ASP.NET Core já foi pensado para isso, com suporte a appsettings.json, arquivos por ambiente e variáveis de ambiente.

Boas práticas mínimas:

• Use ASPNETCORE_ENVIRONMENT ou DOTNET_ENVIRONMENT para separar Development, Staging e Production.
• Mantenha segredos (connection strings, API keys) em variáveis de ambiente ou gerenciadores de secrets — nunca em repositório.
• Tenha pelo menos appsettings.json + appsettings.Production.json e deixe o ambiente de produção o mais explícito possível.
• Padronize logs estruturados (JSON) e níveis de log por ambiente.

Um Program.cs típico já cuida de carregar arquivos de configuração e variáveis de ambiente. Garanta que você não esteja sobrescrevendo isso manualmente, e sim aproveitando o pipeline padrão do host genérico do .NET.

// Program.cs (.NET 8+ minimal hosting)
var builder = WebApplication.CreateBuilder(args);

builder.Configuration
    .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
    .AddJsonFile($"appsettings.{builder.Environment.EnvironmentName}.json",
                 optional: true, reloadOnChange: true)
    .AddEnvironmentVariables();

// serviços...

var app = builder.Build();
// middlewares...
app.Run();

Com isso pronto, você separa claramente o que é código e o que é configuração, o que torna qualquer tipo de deploy (IIS, container, Kubernets, FoundryShip) muito mais simples.

3. Empacotando sua aplicação .NET em containers

A forma mais comum hoje de hospedar aplicações .NET em produção é via containers. A própria Microsoft mantém imagens oficiais de runtime e SDK para .NET, que você pode usar como base para seu Dockerfile.

# Dockerfile multi-stage para ASP.NET Core (.NET 8)
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet restore
RUN dotnet publish src/MinhaApi.csproj -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
COPY --from=build /app/publish .
ENV ASPNETCORE_URLS=http://+:8080
EXPOSE 8080
ENTRYPOINT ["dotnet", "MinhaApi.dll"]

Na FoundryShip Cloud, essa imagem será enviada para um registro privado e depois executada em pods dentro de clusters Kubernetes. O mesmo Dockerfile também funciona em outros provedores — a vantagem é justamente essa portabilidade.

Checklist rápido para containers .NET:

• Use imagens runtime na fase final (mais leves).
• Defina ASPNETCORE_ENVIRONMENT e outras variáveis via ambiente, não no Dockerfile.
• Exponha apenas a porta necessária (ex.: 8080) e deixe TLS/HTTPS para o ingress / proxy.

5. Saúde, observabilidade e rollback seguro

Deploy sem observabilidade é apenas esperança. Em produção, você precisa de health checks, logs estruturados e métricas básicas para saber se o deploy foi bem-sucedido.

• Exponha um endpoint de health check (ex.: /health) para que o orquestrador saiba quando seu container está pronto.
• Use logs estruturados em JSON; isso facilita correlacionar eventos no tempo e por usuário.
• Mantenha versões de imagem imutáveis (tags com número de versão ou hash) para conseguir rollback rápido se algo quebrar.
• Separe o que é falha de infraestrutura (pod, nó, rede) do que é erro de aplicação (exceções, timeouts). Isso reduz muito a fricção no suporte.

Na FoundryShip, esses mesmos conceitos se aplicam: os clusters Kubernetes monitoram a saúde dos containers, e o time consegue ajudar a interpretar métricas e logs se algo fugir do esperado.