Git e Gitflow – um fluxo de branches bem planejado para projetos de banco de dados e ETL

Sobre o que se trata e para quem

O controle de versão com Git já é padrão hoje – a verdadeira arte não está na ferramenta, mas no fluxo de trabalho, ou seja, no acordo sobre quais branches existem, como se chamam, de onde vêm e para onde fluem. Um bom fluxo é a infraestrutura invisível que mantém uma equipe produtiva: ele evita que desenvolvedores se bloqueiem mutuamente, que trabalho inacabado chegue por engano à produção ou que uma correção urgente se perca depois. Um fluxo ruim ou inexistente, ao contrário, leva ao „inferno de merge“, a releases que ninguém consegue reconstruir e a estados de produção cujo conteúdo exato é incerto.

Este artigo dirige-se a equipes que versionam projetos de banco de dados SQL Server (SSDT), pacotes de integração (SSIS) e relatórios (SSRS) em conjunto e os entregam por vários ambientes escalonados. Ele descreve um fluxo completo e comprovado na prática baseado no Bitbucket – do primeiro branch de uma feature até o release de produção e o hotfix urgente. Os mecanismos descritos não se limitam ao stack de dados da Microsoft: a mesma topologia de branches funciona igualmente bem para código de aplicação, APIs ou infraestrutura como código, porque resolve um problema genérico – separar integração de entrega quando o trabalho ocorre em paralelo.

O fio condutor é: três branches de longa duração descrevem estados de ambiente, branches de curta duração encapsulam pacotes de trabalho individuais, e branches de release decidem deliberadamente qual trabalho concluído é de fato entregue. Quem internaliza esse princípio consegue derivar o restante do fluxo a partir dele.

Historicamente, a topologia de branches usada aqui remonta ao modelo Gitflow popularizado por Vincent Driessen, que a Atlassian retomou e preparou para equipes em seus tutoriais. O Gitflow clássico tem dois branches de longa duração – um de desenvolvimento e um de produção – além dos tipos de curta duração feature, release e hotfix. O fluxo descrito aqui estende esse padrão base com um terceiro estágio de longa duração (test) e com uma composição de release consistentemente seletiva, porque projetos de banco de dados e ETL normalmente têm seu próprio ambiente de teste, formalmente aceito, entre desenvolvimento e produção. A extensão, portanto, não é uma complicação arbitrária, mas a adaptação de um modelo padrão comprovado a uma cadeia de entrega real de três estágios.

Um ponto sobre expectativas é importante aqui: um fluxo não é um fim em si mesmo nem um obstáculo burocrático, mas um contrato dentro da equipe. Ele só funciona se todos os envolvidos o conhecem, entendem e seguem – e se as regras mais importantes forem impostas tecnicamente por meio de proteção de branch e merge checks, em vez de depender apenas de disciplina. Esse caminho duplo de acordo claro e proteção técnica percorre todo o artigo como ideia central.

Modelo-alvo: um fluxo orientado a ambientes

Para uma equipe que mantém artefatos de banco de dados, ETL e relatórios em conjunto, um fluxo orientado a ambientes com os branches de longa duração dev, test e main é a base sustentável. Ele é complementado por branches de trabalho de curta duração e por branches de release de curta duração para entregas seletivas. O Bitbucket oferece branch restrictions, regras de pull request e estratégias de merge, de modo que todo o processo possa ser protegido tecnicamente.^1 2 3 4

A ideia central é: dev é o branch de integração do desenvolvimento em andamento, test não é um depósito de todas as alterações, mas o branch de baseline do trem de release atualmente estabilizado, e main descreve o estado de produção. Como o desenvolvimento paralelo de features exige promoção seletiva, um „tudo de dev para test e tudo de test para main“ puramente linear não basta na prática. Para isso usam-se branches release/* de curta duração por release, criados a partir de test ou do estado mais recentemente aprovado e preenchidos apenas com as features de fato aprovadas.⁵

Para projetos de banco de dados isso é especialmente adequado, porque os SQL Database Projects representam um estado-alvo declarativo via DACPAC e podem ser construídos automaticamente, verificados previamente como Script ou DeployReport e então publicados com o SqlPackage. A Microsoft descreve o SqlPackage explicitamente como ferramenta para tarefas automatizadas de desenvolvimento e implantação de banco de dados em pipelines.^10 11 12

Por que um modelo tão diferenciado? Em projetos pequenos com um único desenvolvedor e um único ambiente-alvo, muitas vezes basta um único branch principal. Assim que várias pessoas trabalham em temas diferentes ao mesmo tempo, assim que existem ambientes de teste e produção separados e assim que nem todo desenvolvimento concluído deve ir ao ar imediatamente, surgem conflitos que um fluxo simples não consegue resolver. O modelo descrito aqui é a resposta exatamente a essa realidade: desenvolvimento paralelo, ambientes escalonados e uma entrega deliberada e controlada. Ele não é mais complexo do que o necessário, mas exatamente tão complexo quanto a tarefa exige.

Outra vantagem da abordagem orientada a ambientes está na auditabilidade. Em contextos regulados – dados financeiros, saúde ou dados pessoais – deve ser comprovável a qualquer momento qual estado está em qual ambiente e como chegou lá. Se cada branch de longa duração corresponder exatamente a um estado-alvo de ambiente e cada alteração tiver chegado até ele por um pull request documentado com revisão e build verde, essa pergunta pode ser respondida sem lacunas. O histórico de branches torna-se assim um registro à prova de auditoria do processo de entrega.

Três princípios fundamentais

A diretriz central é: cada branch de longa duração descreve um estado-alvo aprovado e não o estado de trabalho pessoal de um desenvolvedor. Por isso, as alterações são sempre desenvolvidas em branches de curta duração de feature, bugfix, hotfix ou release e só incorporadas aos branches-alvo de longa duração por pull request.^1 2 5

Separar integração de promoção

O segundo princípio é a separação de integração e promoção. dev é a superfície de integração para o desenvolvimento paralelo, test o estágio de aprovação controlado e main exclusivamente o estado de produção. Assim, dev pode conter várias features integradas, enquanto test e produção carregam apenas um conteúdo de release deliberadamente montado.⁵

Orientação a artefatos

O terceiro princípio é a orientação a artefatos. Para SSDT, SSIS e SSRS não deve haver alterações manuais diretamente nos ambientes-alvo; em vez disso, artefatos construídos e versionados são promovidos ao próximo estágio por um processo de branch e release claramente definido. Uma vez construído, o artefato DACPAC é usado sem alteração em vários ambientes; as diferenças de ambiente são controladas por publish profiles, variáveis ou parámetros de pipeline.^10 11 12

Rastreabilidade como quarto princípio

Intimamente ligado à orientação a artefatos há um quarto princípio que pesa especialmente em ambientes regulados: rastreabilidade sem lacunas. Cada alteração deve poder ser rastreada até um ticket, cada merge em um branch de longa duração até um pull request com revisão e build verde, e cada estado de produção até uma tag de versão. Essa ligação entre ID de ticket no nome do branch, histórico de pull request e tag torna todo o processo de entrega auditável: a qualquer momento é possível responder qual tarefa funcional está por trás de uma linha de código, quem a aprovou e em qual versão ela foi para produção. Por isso, nomes de branch com ID de ticket e mensagens de commit significativas não são formalidade, mas uma ferramenta central de governança.

Por que convenções de nomenclatura importam

Nomes de branch consistentes são mais que cosmética. Eles permitem, no Bitbucket, aplicar permissões e merge checks de forma direcionada a padrões como feature/*, release/* ou hotfix/*, e deixam claro à primeira vista de onde vem um branch e a onde ele pertence.⁴ Um branch como feature/ABC-123-relatorio-cliente revela tipo, ticket e conteúdo; um branch chamado „teste2_final_novo“ não revela nada e bloqueia qualquer automação. A convenção é, portanto, a base para que as regras organizacionais do fluxo possam ser impostas tecnicamente.

O modelo de branches em visão geral

Há três branches de longa duração e quatro tipos de branch de curta duração. Cada tipo tem uma origem clara, um destino claro e um propósito claro:

O acréscimo mais importante em relação a um modelo simples dev-test-main é o branch release/*. A orientação de branching da Microsoft descreve branches de release como meio de estabilizar um release de forma direcionada e portar correções de modo controlado entre o branch de release e o branch principal de desenvolvimento; para a seleção precisa de alterações individuais, recomenda-se o cherry-picking.^5 8

Esse acréscimo é obrigatório no cenário descrito, porque várias features são desenvolvidas em paralelo e não devem ir todas ao mesmo tempo para test ou produção. Sem release/*, todo merge completo de dev para test levaria automaticamente features ainda não aprovadas.⁵

# Branches de longa duracao (protegidos, sem push direto)
dev      # estado de integracao do desenvolvimento em andamento
test     # baseline estavel / candidato a release
main     # estado de producao

# Branches de trabalho de curta duracao (sempre com ID de ticket)
feature/ABC-123-relatorio-cliente   # nova feature, derivada de dev
bugfix/ABC-456-join-errado          # defeito no estado de desenvolvimento
hotfix/ABC-789-erro-prod            # defeito de producao, derivado de main
release/2026.05                     # conteiner de release seletivo a partir de test

O ciclo de vida de uma feature individual

Uma nova feature é sempre derivada de dev. O desenvolvedor cria um branch como feature/ABC-123-nova-carga-etl com base no estado atual de dev e trabalha ali de forma isolada. Um branch é uma linha própria de desenvolvimento no repositório. Derivar de dev significa, em termos funcionais: a feature começa a partir do estado atual de integração, mas ainda não está contida em nenhum estágio de aprovação superior. Isso evita que desenvolvedores se orientem por engano em estados de test ou produção desatualizados.⁵

Uma feature normal sempre começa a partir de dev, reúne vários commits tematicamente limpos e é integrada de volta a dev por pull request. Só depois segue o caminho seletivo para um release.

Trabalhando no branch de feature

Durante o desenvolvimento surgem commits pequenos e tematicamente limpos. O branch de feature é sincronizado regularmente com dev – por merge ou por rebase – para que conflitos apareçam cedo e não apenas pouco antes da integração.^2 5 6 7 No branch de feature só se alteram artefatos que pertencem funcionalmente a esse ticket. Para SSDT isso significa: apenas os projetos de BD afetados e o mínimo possível de reformatação ou reestruturação em larga escala; para SSIS e SSRS vale ainda que a edição paralela dos mesmos pacotes ou relatórios deve ser evitada organizacionalmente, porque arquivos gerados pelo designer e pesados em XML são especialmente propensos a conflitos.

# 1) Obter o estado atual de dev e derivar a feature
git checkout dev
git pull --ff-only origin dev
git checkout -b feature/ABC-123-nova-carga-etl

# 2) Commits pequenos e tematicamente limpos
git add src/Database/Sales/*.sql
git commit -m "ABC-123: tabela fato FactSalesDaily incl. indice"

# 3) Sincronizar com dev regularmente (ver conflitos cedo)
git fetch origin
git rebase origin/dev        # achatar historico local ainda nao compartilhado
# Alternativa para um branch ja compartilhado:
# git merge origin/dev       # manter o historico de integracao

# 4) Publicar o branch e abrir um pull request para dev
git push -u origin feature/ABC-123-nova-carga-etl

Critérios de entrada antes do pull request

• Build local das soluções afetadas bem-sucedido.
• Projetos de banco de dados constroem artefatos DACPAC.^10 12
• Validação preliminar de deploy ou Script/DeployReport possível.^10 11
• Projetos SSIS constroem artefatos versionáveis.
• O branch está atualizado em relação a dev; conflitos foram resolvidos no branch de feature, não no branch-alvo.
• A alteração tem escopo funcional limpo e é explicável no pull request.

Pull request, merge para dev e teste do desenvolvedor

O pull request é o processo formal de revisão e aprovação. Ele reúne a descrição funcional, a revisão, o status do build e, quando aplicável, verificações automatizadas antes da integração no branch-alvo.^1 2 3 O Bitbucket permite configurar branch restrictions e merge checks de modo que nenhum push direto e nenhum merge sem revisão em branches protegidos seja possível.^{1 2 3 4 13} Após o merge em dev, a implantação no ambiente dev ocorre de forma automática ou semiautomática – publicando DACPACs e, quando aplicável, artefatos SSIS/SSRS. Para bancos de dados, pelo menos um Script ou DeployReport deve ser produzido antes para tornar visível o impacto na comparação alvo/real.^10 11 12

Usar merge, rebase e cherry-pick corretamente

Três operações Git formam as ferramentas com que todo o fluxo funciona. Elas diferem fundamentalmente em seu efeito sobre o histórico.

Merge

Merge traz o estado atual de um branch para outro. A vantagem é que o histórico de integração permanece visível e nenhum histórico de commit é reescrito; a desvantagem é um histórico potencialmente ramificado e menos linear.^2 6 7

Rebase

Rebase reaplica os próprios commits de um branch de feature sobre o estado mais recente de dev. A vantagem é um histórico linear e limpo; a desvantagem é que o histórico do branch é reescrito. Por isso a Atlassian descreve o rebase como técnica a ser usada de forma direcionada e com cuidado – em especial não em branches já amplamente compartilhados.^6 7

Cherry-pick

Cherry-pick é a adoção direcionada de commits individuais em outro branch. Ao contrário do merge, não se junta o branch inteiro, apenas a alteração selecionada. A Atlassian observa ao mesmo tempo que o cherry-pick é útil, mas não um substituto geral para merge ou rebase, porque cria novos commits com novo histórico e pode produzir um histórico confuso se usado em excesso.^8 9

Fast-forward, no-ff e squash

No merge há ainda três variantes praticamente importantes que determinam como fica o histórico do branch-alvo. Um merge fast-forward apenas move o ponteiro do branch para frente quando não existem commits divergentes – nenhum commit de merge próprio é criado, o histórico permanece linear, mas a informação „aqui uma feature foi integrada“ se perde. Um merge no-ff (--no-ff) força sempre um commit de merge e torna assim cada integração visível como bloco delimitado – este é o caminho recomendado para os branches de longa duração e para merges de release, porque os releases podem então ser identificados e revertidos de forma limpa quando necessário. Um merge squash condensa todos os commits de um branch de feature em um único commit; isso mantém o histórico do branch-alvo compacto, mas dificulta o cherry-pick posterior de alterações parciais. O Bitbucket permite definir as estratégias de merge permitidas por repositório e por branch-alvo.^1 2

# MERGE: trazer dev para o branch de feature (historico permanece visivel)
git checkout feature/ABC-123
git merge origin/dev

# REBASE: reaplicar os proprios commits sobre o novo estado de dev (historico linear)
git checkout feature/ABC-123
git rebase origin/dev
# Atencao: nunca faca rebase de um branch ja amplamente compartilhado!

# CHERRY-PICK: levar exatamente um commit aprovado para release/*
git checkout release/2026.05
git cherry-pick 9f3a1c2        # somente este commit, nao o branch inteiro

Para que o cherry-pick funcione de forma limpa, cada feature deve ter um histórico de commit disciplinado. Commits mistos que contêm simultaneamente várias features, refactorings e hotfixes destroem a capacidade de seleção.

Release seletivo com várias features paralelas

é exatamente aqui que está o ponto decisivo: dev é superfície de integração, mas não um contêiner de release direto. Quando várias features existem em paralelo e apenas parte delas deve ir para test ou produção, o conteúdo do release precisa ser montado separadamente.⁵

As features A, B e C estão em paralelo em dev. Para um release, cria-se um branch release/* a partir de test, no qual apenas a feature A é incluída. Só A chega a test e main; B e C permanecem em dev.

O mecanismo básico é sempre o mesmo: existe um estado estável de test como baseline. Para um novo release, cria-se a partir de test um branch release/<versao>. Nesse branch de release são incluídas apenas as features que devem de fato ser aprovadas. Em seguida o branch de release é mesclado em test e implantado no ambiente de teste; após aceitação bem-sucedida, o mesmo branch de release é mesclado em main e implantado em produção.^2 5

# 1) Criar o branch de release a partir do estado estavel de test
git checkout test
git pull --ff-only origin test
git checkout -b release/2026.05

# 2) Incluir APENAS a feature A -- via cherry-pick dos commits aprovados ...
git cherry-pick 9f3a1c2 a17b8e4
# ... ou via merge de um branch de port limpo e isolado que contem so A:
# git merge --no-ff feature/ABC-123-portA

# 3) Promover o release para test para aceitacao
git checkout test
git merge --no-ff release/2026.05
git push origin test

# 4) Apos a aceitacao: o mesmo branch de release para main + tag de producao
git checkout main
git merge --no-ff release/2026.05
git tag -a v2026.05 -m "Release 2026.05: feature A"
git push origin main --tags

Roteiro detalhado com três features paralelas

Suponha que existam três features: a feature A está pronta e deve ir em breve para produção; a feature B está prevista para test, mas ainda não está pronta para produção; a feature C ainda está em desenvolvimento e deve permanecer por ora apenas em dev.

• Fase 1 – início a partir de dev: feature/A, feature/B e feature/C são criadas a partir de dev. Os três desenvolvedores trabalham em paralelo, cada branch é sincronizado regularmente com dev.⁵
• Fase 2 – integração em dev: os três são mesclados em dev por pull request assim que estiverem maduros para o teste do desenvolvedor – sem por isso se tornarem automaticamente parte de um release.^1 2
• Fase 3 – branch de release para test: a partir do estado atual de test cria-se release/2026.05. Entra apenas a feature A – via cherry-pick dos commits de A ou via merge de um branch de port limpo.^5 8
• Fase 4 – release para produção: uma vez aceita A em test, o mesmo branch de release é mesclado em main. main e produção contêm agora A, enquanto B e C permanecem exclusivamente em dev.^2 5
• Fase 5 – o próximo release: mais tarde surge release/2026.06 a partir de test (que agora já contém A). A feature B é incluída nesse branch; a feature C permanece apenas em dev até ser aprovada.⁵

Esse procedimento resolve exatamente o conflito de „uma feature ainda em dev, uma em test, outra em produção“: os branches de longa duração representam as baselines de ambiente, enquanto os branches release/* encapsulam as promoções seletivas.

Pré-requisito: disciplina de commit limpa

A promoção seletiva depende totalmente da qualidade do histórico de commits. Para que a feature A possa ser extraída de dev de forma limpa, seus commits precisam ser atribuíveis sem ambiguidade a essa feature. Assim que um único commit contém simultaneamente partes de A, um refactoring e uma correção lateral, ele não pode mais ser adotado isoladamente sem arrastar alterações indesejadas. Na prática isso significa: um commit por alteração lógica, mensagens de commit expressivas com ID de ticket e evitar de forma consistente „commits de coletas“ no fim do dia. Onde o histórico já estiver sujo, ajuda um passo prévio de limpeza: a feature é primeiro consolidada em um branch de port novo que contém apenas A, depois mesclado como um todo via --no-ff no branch de release. Assim o conteúdo do release permanece exato e rastreável.

O que acontece com features não liberadas?

Uma preocupação frequente é: „Se apenas a feature A for liberada – B e C se perdem?“ Não. B e C permanecem inalteradas em dev e continuam evoluindo ali. Apenas esperam seu próprio trem de release. Assim que forem aprovadas, serão promovidas de forma igualmente seletiva por um branch release/* posterior. O ponto decisivo é que a decisão „o que será entregue“ é tomada deliberadamente e em um momento definido – e não implicitamente porque por acaso tudo estava integrado em dev quando alguém fez merge para test.

O branch de release em detalhe

O branch de release é o coração da entrega controlada. Ele é criado a partir do estado estável de test, recebe apenas conteúdo aprovado, é aceito em test e só então promovido para main – acompanhado de uma tag de versão.

release/* é criado a partir de test ou do estado aprovado de dev, complementado com correções direcionadas na fase de estabilização, aceito em test e, por fim, entregue a main com uma tag de versão.

Enquanto um branch de release está aberto, apenas correções estabilizadoras podem entrar – nenhuma nova feature. Cada correção criada aqui precisa depois ser portada de volta para dev, para que a linha de desenvolvimento não reintroduza o defeito. Esse retorno controlado de uma correção já validada chama-se back-port e é feito tecnicamente, muitas vezes, por cherry-pick.^5 8

Bugfixes e hotfixes – conforme o local do defeito

Onde um defeito é corrigido depende de onde ele ocorre. Três casos devem ser distinguidos.

Um defeito de produção é corrigido via hotfix/* a partir de main, entregue com uma tag de versão (p. ex. v1.1.1) e, em seguida, obrigatoriamente portado de volta para test e dev, para que a correção não se perca.

Bugfix em dev

Um defeito que ocorre apenas no estado de desenvolvimento ou integração é corrigido via bugfix/* a partir de dev – por exemplo bugfix/ABC-456-join-errado – desenvolvido contra dev e mesclado de volta para dev por pull request.⁵ A correção segue depois normalmente com releases futuros.

Bugfix em test

Um defeito descoberto apenas em test geralmente afeta um candidato a release específico. Por isso a correção não é criada como desenvolvimento normal em dev, mas sobre o estado de release afetado – em release/* ou, se ainda não houver branch de release dedicado, em test.⁵ Em seguida, a correção validada é portada para dev de forma controlada, pois se ficasse apenas em test, dev traria depois o mesmo defeito de volta. Portanto, o back-port para dev é obrigatório.

Hotfix em produção

Um defeito de produção é sempre corrigido com base em main. Para isso, cria-se um branch hotfix/* a partir de main, implementa-se a correção, faz-se merge de volta para main por pull request e implanta-se em produção imediatamente ou de forma acelerada.^2 5 Depois, o hotfix precisa ser portado para trás: para o branch release/* atualmente aberto ou para test, e em seguida para dev. O cherry-pick costuma ser o caminho mais limpo aqui, porque apenas exatamente o hotfix deve ser transferido – um merge geral de main para dev poderia arrastar diferenças específicas de release indesejadas.^5 8

# 1) Branch de hotfix direto de main
git checkout main
git pull --ff-only origin main
git checkout -b hotfix/ABC-789-erro-prod

# 2) Implementar a correcao, PR para main, tag de producao
git commit -am "ABC-789: tratamento de NULL corrigido em dbo.usp_LoadFacts"
git checkout main
git merge --no-ff hotfix/ABC-789-erro-prod
git tag -a v2026.05.1 -m "Hotfix ABC-789"
git push origin main --tags

# 3) BACK-PORT (obrigatorio): portar exatamente esta correcao para test e dev
git checkout test  && git cherry-pick <hotfix-sha> && git push origin test
git checkout dev   && git cherry-pick <hotfix-sha> && git push origin dev

Regras para merges entre dev, test e main

• Regra 1 – sem merge direto e contínuo de dev para test. Um merge completo e geral dev → test levaria cada feature já integrada, mas ainda não aprovada, e tornaria impossível exatamente a separação desejada de A, B e C. Em vez disso: dev é superfície de integração, release/* é superfície de seleção.⁵
• Regra 2 – atualizar test apenas a partir de estados de release. test é atualizado apenas pelo merge de um branch release/* aprovado. Assim permanece rastreável a qualquer momento qual candidato a release está em test e quais features ele contém.^2 5
• Regra 3 – main apenas a partir de estados de release aceitos em test ou hotfixes. main recebe apenas um branch release/* aceito com sucesso em test ou um branch hotfix/* de produção. Assim main permanece a fonte da verdade de produção e não é contaminado com desenvolvimento em andamento.^2 5

Padrões de pull request e merge no Bitbucket

O Bitbucket deve ser configurado de modo que branch restrictions e merge checks estejam ativos para dev, test e main. A Atlassian documenta para isso restrições de push/merge específicas por branch, revisores padrão e configurações de merge.^{1 2 3 4 13} Branch permissions controlam direitos de escrita e merge para branches específicos ou padrões de branch; merge checks permitem ainda exigir condições como builds bem-sucedidos ou revisões obrigatórias antes de um merge.^3 4 13

• Sem push direto em dev, test, main – PR obrigatório para todos os merges.
• Pelo menos um revisor funcional e um técnico para alterações relevantes de BD/ETL/relatório.
• Build de CI bem-sucedido como pré-requisito de merge.
• Fechar o branch de origem automaticamente após o merge.
• Merge para test apenas por responsáveis de release, merge para main apenas por gerentes de release/grupo de admin – mais restritivo que para dev.⁴
• Checklist documentado para implantação, rollback, smoke test e impacto no banco de dados.

Uma arquitetura-alvo pronta para CI/CD para SSDT, SSIS e SSRS

Uma arquitetura-alvo compatível com CI/CD pode ser construída diretamente sobre esse fluxo. Para bancos de dados, o caminho padrão é: construir os projetos .sqlproj, gerar o DACPAC, DeployReport ou Script, implantação de teste e depois publicar com o SqlPackage.^10 11 12 Os branches representam estados de ambiente claros, vários desenvolvedores trabalham em paralelo e, ainda assim, os releases são entregues de forma direcionada e reproduzível.

# 1) Construir o projeto de banco de dados -> DACPAC
dotnet build .\\src\\Database\\Sales\\Sales.sqlproj -c Release

# 2) Previa das alteracoes ANTES do deploy (DeployReport, sem acesso de escrita)
SqlPackage /Action:DeployReport `
  /SourceFile:".\\bin\\Release\\Sales.dacpac" `
  /TargetConnectionString:"Server=sql-test;Database=Sales;Integrated Security=true" `
  /OutputPath:".\\artifacts\\Sales.DeployReport.xml"

# 3) Gerar um script de upgrade idempotente (revisao no pull request)
SqlPackage /Action:Script `
  /SourceFile:".\\bin\\Release\\Sales.dacpac" `
  /TargetConnectionString:"Server=sql-test;Database=Sales;Integrated Security=true" `
  /OutputPath:".\\artifacts\\Sales.Upgrade.sql"

# 4) Somente apos aprovacao: publicar no ambiente-alvo
SqlPackage /Action:Publish `
  /SourceFile:".\\bin\\Release\\Sales.dacpac" `
  /TargetConnectionString:"Server=sql-test;Database=Sales;Integrated Security=true" `
  /p:BlockOnPossibleDataLoss=true

Build e implantação são claramente separados: uma vez construídos, os artefatos DACPAC são usados sem alteração em vários ambientes, enquanto as diferenças de ambiente são controladas por publish profiles, variáveis ou parâmetros de pipeline.

SSIS e SSRS na pipeline

Para SSIS o caminho é análogo: o projeto é construído em um arquivo ISPAC versionável e implantado pelo modelo de implantação de projeto no Integration Services Catalog (SSISDB) do ambiente-alvo. Valores dependentes de ambiente – cadeias de conexão, caminhos, limiares – não são codificados de forma fixa no pacote, mas definidos por ambientes e parámetros do SSIS no momento do deploy. Assim, o mesmo ISPAC construído permanece idêntico em dev, test e produção, enquanto apenas a configuração varia – exatamente o mesmo princípio do DACPAC.

Para SSRS, definições de relatório (.rdl) e fontes de dados compartilhadas são totalmente versionadas e publicadas no ambiente-alvo pela interface do Reporting Services ou por um script de implantação. O decisivo aqui é a disciplina de nunca editar diretamente no portal de relatórios: cada alteração manual no sistema-alvo, caso contrário, se afasta do estado versionado e se perde na próxima implantação ou sobrescreve sem intenção outra correção.

Gatilhos de pipeline ao longo dos branches

A tabela acima se traduz diretamente em gatilhos de pipeline: cada pull request contra dev executa um build e verificação puros, sem implantação; cada merge em dev é seguido por uma implantação automática no ambiente dev; um push em release/* gera um build de release incluindo um DeployReport para revisão; o merge em test dispara a implantação de teste, o merge em main a implantação de produção com um smoke test subsequente e tag de versão. Como cada branch de longa duração corresponde a exatamente um ambiente, o mapeamento de „qual merge dispara qual implantação“ é inequívoco e não exige lógica adicional.

Ponta a ponta: o fluxo completo de uma vez

A visão geral a seguir combina todos os blocos em uma imagem contínua: uma feature passa por várias iterações em dev, é estabilizada seletivamente por um branch de release, aceita em test, entregue a main – e um defeito de produção que aparece em paralelo é corrigido por um hotfix e portado de volta.

O ciclo de vida completo: dev integra o desenvolvimento em andamento, release/* seleciona o conteúdo do release, test aceita, main é produção (v1.0 → v1.1). Um hotfix de main (v1.1.1) é obrigatoriamente portado de volta para dev.

Esse entrelaçamento é o verdadeiro valor: os branches representam estados-alvo de ambiente em vez de estados intermediários arbitrários, a promoção seletiva desacopla integração de entrega, e cada correção encontra o caminho de volta à linha de desenvolvimento. Para projetos de banco de dados e ETL, surge assim um processo de entrega reproduzível, verificável e auditável.

Evitar conflitos no stack SSDT/SSIS/SSRS

Os conflitos de merge não podem ser eliminados por completo nesse stack, mas podem ser reduzidos significativamente. As alavancas mais importantes são branches pequenos, pull requests pequenos, integração cedo em dev e responsabilidades claras para artefatos SSIS e SSRS propensos a conflitos.

• Convenções obrigatórias de arquivos e pastas para objetos de BD, pacotes SSIS e relatórios SSRS.
• Manter os pull requests pequenos, idealmente sob um único tema funcional.
• Integrar cedo em dev em vez de acumular por semanas em branches de feature.
• „One developer owns one artifact“ para arquivos SSIS/SSRS propensos a conflitos durante uma story.
• Agrupar refactorings de objetos de banco de dados no tempo, não em paralelo com muitas features.
• Nenhum commit misto entre várias features – para que cherry-pick e back-port permaneçam limpos.^8 9

Particularidades dos três tipos de artefato

SSDT é bem adequado porque os Database Projects descrevem o estado-alvo de forma declarativa e podem ser construídos como DACPAC; o SqlPackage oferece Publish, Script e relatórios.^10 11 12 SSIS produz artefatos de build versionáveis; como arquivos gerados pelo designer são propensos a conflitos, a propriedade por pacote deve ser inequívoca durante um ticket. SSRS deve ser tratado totalmente sob controle de versão e orientado a release – relatórios e shared data sources não devem ser mantidos manualmente em ambientes-alvo, senão os estados de branch e ambiente divergem.

Um caso especial prático merece atenção: refactorings de banco de dados como renomear uma coluna ou dividir uma tabela são especialmente propensos a conflitos e a possível perda de dados. O SSDT oferece para isso refactoring logs, que registram tais renomeações como operação deliberada em vez de interpretá-las como „coluna excluída, nova coluna criada“. Quem versiona esses logs e executa o SqlPackage com BlockOnPossibleDataLoss evita que um refactoring aparentemente inofensivo descarte dados silenciosamente em produção. Tais alterações estruturais devem ser agrupadas no tempo e não executadas em paralelo com muitas features pequenas, para que a promoção seletiva permaneça gerenciável.

Uma instrução concreta para a equipe

• Cada feature normal começa a partir de dev e faz merge primeiro para dev.
• dev serve apenas à integração, não à promoção direta para test.
• Para cada release planejado, cria-se um branch release/* a partir de test.
• No branch de release entram apenas features aprovadas – via cherry-pick ou merge direcionado de branches isolados.
• release/* vai para test após verificação bem-sucedida; o mesmo branch vai para main após a aceitação.
• Bugs em dev são corrigidos em dev, bugs em test sobre o estado release/* afetado, bugs em produção como hotfix/* a partir de main.
• Cada correção de test ou produção é portada de volta para dev de forma controlada.
• Pull requests, branch permissions e merge checks devem ser configurados como obrigatórios para os branches de longa duração.^1 3 4 13

Como trabalhamos juntos

Um modelo de branching só mostra seu valor quando toda a equipe o entende, o apoia e o aplica de forma consistente no dia a dia. Eu trago a experiência com o fluxo de trabalho, a automação e a configuração do Bitbucket; a equipe de projeto traz o conhecimento sobre a base de código existente, os ciclos de release e as condições organizacionais. Dessa combinação nasce um processo tecnicamente limpo e realmente vivido na operação – em vez de um documento que ninguém mais consulta depois de duas semanas.

Início típico de projeto

Em geral começo com um levantamento da situação atual: como estão os branches hoje, como se faz merge atualmente, quais ambientes (dev, test, main) existem e como são abastecidos? Verifico a configuração existente no Bitbucket ou Azure DevOps, os merge checks, as branch permissions e os pipelines de build presentes. O resultado é um diagnóstico claro com melhorias concretas e priorizadas – do back-port ausente à main desprotegida. Esse primeiro passo costuma levar de um a três dias e cria a base comum antes de mudanças maiores no fluxo.

Implementação iterativa

A introdução ocorre passo a passo e sem big-bang. Primeiro protegemos os branches de longa duração e tornamos as regras de merge obrigatórias; em seguida vêm os processos de feature, bugfix e hotfix, bem como o release seletivo via release/*. Cada etapa é alinhada com a equipe, documentada e testada em um release real antes da próxima etapa. Assim a operação permanece sempre capaz de agir.

• Levantamento de branches, merges, ambientes e pipelines
• Proteção gradual dos branches de longa duração (dev, test, main)
• Merge checks, branch permissions e regras de pull request obrigatórios
• Validação em um release real em vez de uma introdução puramente teórica
• Transferência de conhecimento, cheat-sheets e sessões hands-on curtas para a equipe

Para mim é importante que o fluxo se ajuste à organização, e não o contrário. Uma equipe pequena com um release por trimestre precisa de regras diferentes das de uma equipe com entregas semanais. Adapto o modelo à frequência real de releases, ao número de iniciativas paralelas e aos requisitos regulatórios.

Serviços típicos em torno de Git e Gitflow

Conforme a situação inicial e o objetivo do projeto, assumo tarefas diferentes – da introdução pontual de um modelo de branching até o acompanhamento permanente dos processos de pull request e CI/CD de um cenário com SQL, SSIS e SSRS.

• Desenho de um modelo de branching com dev, test e main, alinhado à frequência de releases
• Introdução de branches de feature, bugfix, hotfix e release com regras claras
• Promoção seletiva de features individuais via release/* por merge ou cherry-pick
• Definição e implementação do back-port controlado de correções para dev
• Configuração do Bitbucket: branch permissions, merge checks, revisores obrigatórios
• Padrões de pull request, convenções de commit e diretrizes de revisão
• Estratégia de merge, rebase e cherry-pick incluindo treinamento da equipe
• Prevenção de conflitos por integrações pequenas e frequentes e responsabilidades claras
• CI/CD para projetos de banco SSDT: build para DACPAC, DeployReport e publish com SqlPackage
• Pipelines de build e deployment para pacotes SSIS e relatórios SSRS
• Testes automatizados e quality gates como pré-requisito de merge
• Documentação, runbooks e transferência de conhecimento para equipes de desenvolvimento e operação

Muitos problemas no gerenciamento de versões não são isolados: conflitos de merge frequentes costumam ser sintoma de branches de feature longos demais, features entregues por engano um sintoma da falta de promoção seletiva e erros recorrentes em produção um sintoma de back-ports ausentes. Por isso analiso o fluxo sempre em conjunto com a esteira de CI/CD e a realidade de deployment.

Seja como projeto pontual de introdução, como revisão de um fluxo existente ou como acompanhamento contínuo – o escopo segue a sua necessidade. Também um mandato bem delimitado, como „proteger a main e montar CI/CD para SSDT“, é um ponto de partida sensato.

Projetos de referência selecionados

Termos explicados de forma breve

Os termos a seguir aparecem em todo o fluxo e são definidos aqui de forma compacta para que todos os envolvidos entendam a mesma coisa:

• Branch de longa duração: um branch que existe permanentemente (dev, test, main), representa um estado-alvo de ambiente e nunca é excluído.
• Branch de curta duração: um branch de trabalho (feature/*, bugfix/*, hotfix/*, release/*) criado para um fim específico e fechado novamente após o merge.
• Integração: juntar vários estados de desenvolvimento em dev para que incompatibilidades apareçam cedo – sem com isso conceder uma aprovação.
• Promoção: a passagem deliberada de um estado verificado para o ambiente imediatamente superior (dev → test → main), controlada por branches release/*.
• Promoção seletiva: a seleção direcionada de features individuais para um release, em vez de entregar „tudo o que está atualmente em dev“ em massa.
• Back-port: o retorno controlado de uma correção já validada de test, release/* ou main para dev, para que o defeito não reapareça.
• DACPAC: o artefato construído e declarativo de um projeto de banco de dados SSDT que descreve o estado-alvo do banco e é publicado com o SqlPackage.^10 11
• DeployReport: uma análise prévia do SqlPackage que mostra, sem acesso de escrita, quais alterações uma implantação dispararia.^10 11
• Merge check / branch permission: condições configuráveis no Bitbucket (build verde, mínimo de revisores, proibição de push) que permitem um merge em branches protegidos apenas após serem cumpridas.^3 4

Perguntas frequentes

Por que não simplesmente fazer merge de dev para test e de test para main?

Porque então cada estado de feature ainda não aprovado seria entregue automaticamente. Assim que várias features rodam em paralelo e apenas algumas devem ser liberadas, a promoção seletiva via release/* é indispensável.⁵

Quando cherry-pick e quando merge de um branch?

Se um branch de feature está limpo e isolado, um merge em release/* é fácil de rastrear. Se a feature já está junto com outras em dev, você seleciona exatamente os commits aprovados via cherry-pick.^8 9

Um hotfix realmente precisa voltar para dev?

Sim. Se a correção ficasse apenas em main ou test, a linha de desenvolvimento traria o defeito de volta no próximo release. O back-port – geralmente por cherry-pick – é portanto obrigatório.^5 8

O modelo serve para projetos de banco de dados SSDT puros?

Especialmente bem. Os SQL Database Projects descrevem o estado-alvo de forma declarativa e são construídos como DACPAC; o SqlPackage produz DeployReport, Script e Publish – ideal para a promoção controlada entre dev, test e main.^10 11 12

Fontes

As fontes a seguir foram usadas para recomendações de branching, regras do Bitbucket, definições de termos e a referência de SQL/CI/CD:

1. ¹ Atlassian Support – Pull request and merge settings – https://support.atlassian.com/bitbucket-cloud/docs/pull-request-and-merge-settings/
2. ² Atlassian Support – Merge a pull request – https://support.atlassian.com/bitbucket-cloud/docs/merge-a-pull-request/
3. ³ Atlassian Support – Suggest or require checks before a merge – https://support.atlassian.com/bitbucket-cloud/docs/suggest-or-require-checks-before-a-merge/
4. ⁴ Atlassian Support – Use branch permissions – https://support.atlassian.com/bitbucket-cloud/docs/use-branch-permissions/
5. ⁵ Microsoft Learn – Git branching guidance – https://learn.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops
6. ⁶ Atlassian – Merging vs. Rebasing – https://www.atlassian.com/git/tutorials/merging-vs-rebasing
7. ⁷ Atlassian Community – Alternatives to Git merge: Rebase and Cherry-pick – https://community.atlassian.com/forums/Bitbucket-articles/Alternatives-to-Git-merge-Git-s-Rebase-and-Cherry-pick/ba-p/2482241
8. ⁸ Microsoft Learn – Copy changes to a branch with cherry-pick – https://learn.microsoft.com/en-us/azure/devops/repos/git/cherry-pick?view=azure-devops
9. ⁹ Atlassian – Git Cherry Pick Tutorial – https://www.atlassian.com/git/tutorials/cherry-pick
10. ¹⁰ Microsoft Learn – SqlPackage in Development Pipelines – https://learn.microsoft.com/en-us/sql/tools/sqlpackage/sqlpackage-pipelines?view=sql-server-ver17
11. ¹¹ Microsoft Learn – SqlPackage – https://learn.microsoft.com/en-us/sql/tools/sqlpackage/sqlpackage?view=sql-server-ver17
12. ¹² Microsoft Learn – SQL projects automation – https://learn.microsoft.com/de-de/sql/tools/sql-database-projects/sql-projects-automation?view=sql-server-ver17
13. ¹³ Bitbucket – Features / Merge checks – https://bitbucket.org/product/en/features