Bitbucket e o Ecossistema Atlassian Já leu

Há uma situação muito específica que justifica o uso do Bitbucket: a organização já tem o Jira como sistema central de rastreamento de trabalho, e a integração nativa entre repositório, pipeline e tickets é um requisito, não um diferencial. Nesse contexto, o Bitbucket não compete com o GitHub ou o GitLab pelo melhor repositório Git — ele compete sendo o repositório Git que melhor conversa com o restante do ecossistema Atlassian.

O Jira, o Confluence e o Bitbucket são os três produtos centrais do ecossistema Atlassian. A integração entre eles é profunda: um commit com a mensagem [PROJ-123] Fix null pointer exception in checkout automaticamente referencia e atualiza o ticket Jira PROJ-123. Um branch criado diretamente do Jira cria o branch no Bitbucket com o nome correto. O Confluence documenta os projetos e os links para repositórios e pull requests aparecem automaticamente nos espaços relevantes.

Para quem trabalha em uma organização onde o Jira é a fonte de verdade para o trabalho, ignorar essa integração é perder produtividade real.

Bitbucket Pipelines: CI/CD Nativo

O Bitbucket Pipelines é o sistema de CI/CD integrado ao Bitbucket Cloud — equivalente ao GitHub Actions e ao GitLab CI/CD. O arquivo de configuração é o bitbucket-pipelines.yml na raiz do repositório.

A sintaxe é mais simples do que o GitHub Actions ou o GitLab CI/CD, o que é tanto um ponto positivo (curva de aprendizado menor) quanto uma limitação (menos flexibilidade em cenários complexos):

# bitbucket-pipelines.yml

image: node:20-alpine  # Imagem padrão para todos os steps

definitions:
  # Serviços auxiliares (equivalente ao services: do GitLab)
  services:
    postgres:
      image: postgres:16-alpine
      environment:
        POSTGRES_DB: testdb
        POSTGRES_USER: testuser
        POSTGRES_PASSWORD: testpass
    redis:
      image: redis:7-alpine

  # Steps reutilizáveis (equivalente aos templates do GitLab)
  steps:
    - step: &instalar-dependencias
        name: Instalar dependências
        caches:
          - node  # Cache nativo do Bitbucket para node_modules
        script:
          - npm ci

    - step: &testes
        name: Testes unitários
        caches:
          - node
        services:
          - postgres
          - redis
        script:
          - npm ci
          - npm test -- --coverage
        artifacts:
          - coverage/**

pipelines:
  # Pipeline para pull requests
  pull-requests:
    '**':  # Qualquer branch com PR aberto
      - step: *instalar-dependencias
      - step: *testes
      - step:
          name: Lint e verificações de qualidade
          caches:
            - node
          script:
            - npm ci
            - npm run lint
            - npm run type-check

  # Pipeline para branches específicas
  branches:
    main:
      - step: *instalar-dependencias
      - step: *testes
      - step:
          name: Build da imagem Docker
          services:
            - docker
          script:
            # Bitbucket tem variáveis automáticas similares ao GitLab
            # $BITBUCKET_COMMIT, $BITBUCKET_BRANCH, $BITBUCKET_REPO_SLUG
            - IMAGE_TAG=$BITBUCKET_DOCKER_REGISTRY/$BITBUCKET_REPO_SLUG:$BITBUCKET_COMMIT
            - docker build -t $IMAGE_TAG .
            - echo $DOCKER_PASSWORD | docker login --username $DOCKER_USERNAME --password-stdin
            - docker push $IMAGE_TAG
      - step:
          name: Deploy em Staging
          deployment: staging  # Liga ao Deployment Environment do Bitbucket
          script:
            - pipe: atlassian/aws-eks-kubectl-run:2.2.0
              variables:
                AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
                AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
                AWS_DEFAULT_REGION: 'sa-east-1'
                CLUSTER_NAME: 'meu-cluster-eks'
                KUBECTL_COMMAND: >-
                  set image deployment/minha-app
                  app=$BITBUCKET_DOCKER_REGISTRY/$BITBUCKET_REPO_SLUG:$BITBUCKET_COMMIT
                  -n staging
      - step:
          name: Deploy em Produção
          deployment: production
          trigger: manual  # Equivalente ao when: manual do GitLab
          script:
            - pipe: atlassian/aws-eks-kubectl-run:2.2.0
              variables:
                AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
                AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
                AWS_DEFAULT_REGION: 'sa-east-1'
                CLUSTER_NAME: 'meu-cluster-eks'
                KUBECTL_COMMAND: >-
                  set image deployment/minha-app
                  app=$BITBUCKET_DOCKER_REGISTRY/$BITBUCKET_REPO_SLUG:$BITBUCKET_COMMIT
                  -n producao

  # Pipelines agendados (cron)
  custom:
    testes-nocturnos:
      - variables:
          - name: AMBIENTE
            default: staging
      - step:
          name: Testes de integração completos
          caches:
            - node
          script:
            - npm ci
            - npm run test:integration -- --env=$AMBIENTE

Pipes: Ações Prontas do Bitbucket

Uma característica diferenciada do Bitbucket Pipelines são os Pipes — blocos de funcionalidade empacotados que simplificam integrações com serviços externos. É o equivalente das Actions do GitHub Marketplace, mas com foco no ecossistema Atlassian e parceiros cloud.

A Atlassian mantém pipes oficiais para AWS (deploy no ECS, EKS, S3, Lambda), Azure, GCP, Kubernetes e ferramentas de qualidade como Snyk e Sonarqube. Usar um pipe é mais simples do que escrever os comandos equivalentes:

# Usando o pipe da AWS para deploy no S3 (site estático)
- step:
    name: Deploy no S3
    script:
      - npm run build
      - pipe: atlassian/aws-s3-deploy:1.1.0
        variables:
          AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
          AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
          AWS_DEFAULT_REGION: 'sa-east-1'
          S3_BUCKET: 'minha-app-frontend'
          LOCAL_PATH: 'dist'
          DELETE_FLAG: 'true'  # Remover arquivos deletados do bucket
          CACHE_CONTROL: 'max-age=31536000'

# Pipe para invalidar CloudFront após o deploy
- step:
    name: Invalidar cache do CloudFront
    script:
      - pipe: atlassian/aws-cloudfront-invalidate:0.6.0
        variables:
          AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
          AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
          AWS_DEFAULT_REGION: 'sa-east-1'
          DISTRIBUTION_ID: $CLOUDFRONT_DISTRIBUTION_ID

A Integração Jira-Bitbucket na Prática

A integração Jira-Bitbucket é automática quando os dois produtos pertencem à mesma organização no Atlassian Cloud. Não há configuração manual de webhooks ou tokens — a Atlassian gerencia a conexão internamente.

O que acontece na prática: quando um desenvolvedor cria um branch com o nome contendo o código do ticket Jira (por exemplo, feature/PROJ-456-autenticacao-oauth), o Jira automaticamente aparece no ticket PROJ-456 mostrando que há um branch ativo. Quando um commit é feito com PROJ-456 na mensagem, o Jira registra o commit no ticket. Quando o pull request é aberto, o ticket mostra o PR. Quando o PR é mergeado e o pipeline faz o deploy, o Jira pode ser configurado para transicionar automaticamente o ticket para "Em Produção".

Essa rastreabilidade bidirecional — do ticket ao código, do código ao deploy — sem configuração adicional é o principal argumento para o Bitbucket em organizações Jira-cêntricas.

Branch Permissions e Code Insights

O Bitbucket Cloud suporta Branch Permissions equivalentes às Branch Protection Rules do GitHub: exigir pull requests, número mínimo de aprovadores, impedir push direto na main, e exigir que o pipeline passe antes do merge.

O Code Insights é um recurso que permite que ferramentas externas de análise publiquem resultados diretamente no pull request — cobertura de testes, findings de segurança, análise estática. Sonarqube, Snyk e outras ferramentas têm integração nativa com o Code Insights do Bitbucket.

Bitbucket Data Center: Self-Hosted Enterprise

Assim como o GitLab tem a opção self-hosted, o Bitbucket tem o Bitbucket Data Center — a versão instalável em infraestrutura própria, com suporte a alta disponibilidade e clustering. É a escolha para organizações que precisam do ecossistema Atlassian mas não podem usar o cloud por razões regulatórias.

O Bitbucket Data Center pode ser instalado em servidores Linux próprios ou no Kubernetes via Helm Chart oficial da Atlassian. A configuração requer PostgreSQL externo, sistema de arquivos compartilhado (NFS ou equivalente para repositórios Git), Elasticsearch para busca e, opcionalmente, o Bamboo (CI/CD self-hosted da Atlassian) como alternativa ao Bitbucket Pipelines em ambientes on-premises.

Quando Não Usar o Bitbucket

O Bitbucket faz sentido em um contexto bem definido: organização que já usa Jira como ferramenta central e valoriza a integração nativa. Fora desse contexto, tanto o GitHub quanto o GitLab oferecem mais funcionalidades, comunidade maior e ecossistema de integrações mais rico.

O Bitbucket Pipelines, em particular, é menos poderoso do que o GitHub Actions (em termos de ecossistema de actions) e do que o GitLab CI/CD (em termos de funcionalidades enterprise como SAST integrado e templates avançados). Para times que não usam o Jira, a escolha entre GitHub e GitLab raramente passa pelo Bitbucket.

Referências para Aprofundamento

— Bitbucket Pipelines — Documentação Oficial: https://support.atlassian.com/bitbucket-cloud/docs/get-started-with-bitbucket-pipelines/ — Pipes do Bitbucket: https://bitbucket.org/product/features/pipelines/integrations — Integração Jira e Bitbucket: https://support.atlassian.com/jira-software-cloud/docs/use-jira-and-bitbucket-together/ — Bitbucket Data Center — Instalação: https://confluence.atlassian.com/bitbucketserver/install-bitbucket-data-center-776640391.html