![\"Cover](\"/assets/img/google-play-verificacao-organizacoes-capa.png\" "\\"Google")
\n\n## What you'll see here\n\n- What changes when the account type is \"Organization\"\n- Preparation checklist (what to gather before you start)\n- Step 1: organization details (D-U-N-S, payments, contacts, and public profile)\n- Step 2: document upload (company + authorized representative)\n- Step 3 (if applicable): merchant payment method verification\n- Common errors and how to fix them without stress\n- Final checklist to confirm everything is OK\n\n## Before anything: why do this now (and not on launch day)\n\nThe verification flow usually appears as a notice on the Play Console home page, with a deadline. In general, you can start verification **up to 60 days before** the deadline shown in the console.\n\nHere are 3 points that are worth their weight in gold:\n\n1. **Only the account owner can start/complete verification.**\nIf the person who created the account is no longer at the company or no longer has access, you need to solve that first.\n2. **Start as early as possible.**\nThe process may involve checks and document review that take time.\n3. **Missing the deadline can lead to account restrictions.**\nIn practice, that turns into urgency, quick fixes, and rework.\n\n![\"Verification](\"/assets/img/google-play-verificacao-01-inicio.png\" "\\"Verification")
\n\n## Preparation checklist (gather this before you click \"Verify\")\n\nBefore starting the flow, gather:\n\n- Legal name and address of the company (exactly as shown in official records).\n- The organization's **D-U-N-S** number (when applicable).\n- A \"private\" email and phone number for Google to contact the company (validated via OTP).\n- A \"public\" developer email and phone number (shown on the Google Play profile and also validated via OTP).\n\nTwo practical recommendations:\n\n- **Use institutional, team-accessible contact details**, not a temporary personal phone.\n- Make sure whoever will receive OTP (SMS/call) and emails is available during the process.\n\nIf you don't have all of this on hand yet, Play Console may allow you to request **an extension** of the deadline (when that option is available on the notice).\n\n![\"Option](\"/assets/img/google-play-verificacao-10-pedir-extensao.png\" "\\"If")
\n\n## Step 1: start verification and fill in organization details\n\n### 1) Confirm the account type: \"Organization\" vs \"Personal\"\n\nFor formally incorporated companies, the correct type is **Organization**.\n\nWhy does this matter?\n\n- The account type defines which verification steps will be required.\n- After you complete verification, **changing the account type is not easy**.\n- The type doesn't change the account's general features, but it can affect requirements to publish certain categories.\n\n![\"Account](\"/assets/img/google-play-verificacao-02-tipo-conta.png\" "\\"Select")
\n\n### 2) Link a Google payments profile\n\nPlay Console asks you to link (or create) a **Google payments profile** to confirm organization information.\n\nWhat really matters here:\n\n- The profile stores data that can be used across Google products (including organization details).\n- For verification, it is used to collect and validate information such as **legal name, address, and D-U-N-S**.\n- These details must be **accurate and up to date**.\n\nImportant tip: if the company already monetizes apps, there may be a payments profile used for revenue. In the verification flow, the selected profile can be used **only to confirm organization details**, and it doesn't necessarily need to be the same one used for monetization.\n\n![\"Linking](\"/assets/img/google-play-verificacao-03-perfil-pagamentos.png\" "\\"Play")
\n\n### 3) Enter the D-U-N-S number (and make sure everything matches)\n\nAfter the payments profile, you provide the **D-U-N-S** (a 9-digit identifier for organizations).\n\nCritical points:\n\n- You have **limited attempts** to enter the D-U-N-S correctly.\n- If the company doesn't have a D-U-N-S yet, it can take time to obtain (in some cases, **30 days or more**). Plan ahead.\n- D-U-N-S returns associated business information that you'll need to confirm.\n- For some government entities, there may be a verification flow without D-U-N-S (Play Console will show when that option is available).\n\n![\"D-U-N-S](\"/assets/img/google-play-verificacao-04-numero-duns.png\" "\\"Have")
\n\n### 4) Golden rule: legal name and address must match\n\nAfter entering the D-U-N-S, Play Console shows the business information it found. You must review and confirm it.\n\nThe rule that causes the most errors is simple:\n\n**The legal name and address from D-U-N-S must be the same as in the payments profile.**\n\nIf there is any inconsistency, the flow can get stuck and you enter a correction loop. When Play Console detects discrepancies, it may give a deadline (for example, **28 days**) to fix them before the account and apps face restrictions.\n\n![\"Confirmation](\"/assets/img/google-play-verificacao-04b-confirmar-duns.png\" "\\"After")
\n\n### 5) Provide additional organization details (internal information)\n\nPlay Console asks for a few extra company details (for example, structure/size).\nGoogle uses this to better understand and verify the organization, and it **does not appear publicly** to users in the store.\n\n### 6) Set up the account's private contacts (so Google can reach the company)\n\nYou will enter a \"private\" email and phone number (not public) and they will be verified with a one-time password (OTP).\n\nBest practices:\n\n- Have access to the email and phone at the moment of verification.\n- If SMS fails, try **a phone call**, and vice versa.\n- Avoid numbers that depend on IVR/phone systems that block automated calls.\n\n![\"Private](\"/assets/img/google-play-verificacao-05-contato.png\" "\\"Email")
\n\n### 7) Set up the public contacts for the developer profile\n\n**Organization** accounts must provide:\n\n- A public developer email\n- A public developer phone number\n\nThese details are visible on the public Google Play developer profile and are also verified via OTP.\n\nAt the end, Play Console shows a screen to review the public profile. Review carefully, because this is what end users will see.\n\n![\"Public](\"/assets/img/google-play-verificacao-06-perfil-publico.png\" "\\"Review")
\n\n## Step 2: upload documents to verify the organization and identity\n\nAfter submitting organization details, you reach the document step. Play Console will let you know when the upload becomes available.\n\nHere is the most important warning for this step:\n\n**Submitting unaccepted documents (or poor-quality images) is the #1 cause of verification failures.**\nAltered, manipulated, or falsified documentation can lead to immediate removal of the account and apps.\n\n### 1) Upload organization registration documents\n\nYou will upload official documents that register the company (common examples: articles of incorporation, registration certificate, equivalent tax registration).\n\nWhat to watch for:\n\n- Documents must be issued by a trusted authority (government/notary/registration body or equivalent).\n- In many companies, these are held by legal/finance.\n- Play Console shows which documents are accepted depending on country/region.\n\n![\"List](\"/assets/img/google-play-verificacao-07-documentos.png\" "\\"Play")
\n\n![\"Example](\"/assets/img/google-play-verificacao-07a-verificar-organizacao.png\" "\\"Example")
\n\n### 2) Verify the identity of an authorized representative\n\nIn addition to company documents, someone must confirm their identity using a valid ID document.\n\nWho can do it?\n\n- The Play Console account owner, or\n- **Any authorized representative of the organization** (as long as they can prove it).\n\nPoints of attention:\n\n- Accepted document types vary by country/region.\n- Do not edit the image of the document.\n- Make sure the photo/scan is sharp, well lit, and shows all information clearly.\n\n![\"Identity](\"/assets/img/google-play-verificacao-07b-verificar-identidade.png\" "\\"After")
\n\n### 3) Type the name and address exactly as they appear on the document\n\nThe form asks you to type the name and address as they appear on the submitted ID.\nHere, typos (even small ones) can lead to rejection.\n\nWhy does Google ask for a personal ID document?\n\nThe idea is to reduce fraud and abuse on the platform. The official guidance is that the document is stored securely and is not shared with users.\n\n## Step 3: merchant payment method verification (if you generate revenue)\n\nThis step applies to accounts that generate revenue through Google Play (for example, through billing/monetization).\n\nPlay Console may ask you to verify the **merchant payment method**, typically by confirming a bank account using methods such as:\n\na) Deposit test (confirming a small deposit) \nb) Uploading an official bank statement\n\nWhile Google reviews it, the console may show a pending verification notice.\n\nIf merchant payment method verification fails, the owner usually receives an email notice and Play Console shows what happened and how to fix it.\n\n![\"Merchant](\"/assets/img/google-play-verificacao-08-pagamento-comerciante.png\" "\\"If")
\n\n## \"It errored\": common problems and how to fix them\n\n### 1) \"I can't find the account owner\"\n\nOnly the owner can complete verification. If the person is not available or lost access:\n\n- Try to recover access immediately (before any other step).\n- If you need time, request an extension in Play Console (when available).\n- If the owner's email no longer exists, the path usually involves support and proof.\n\n### 1a) \"My organization is a government entity and doesn't have D-U-N-S\"\n\nIn some cases, government organizations can complete verification **without** providing a D-U-N-S (when that option is already enabled in the flow).\n\nIf Play Console does not offer that alternative and you truly don't have a D-U-N-S:\n\n- Make sure the account is correctly set up as an Organization.\n- Prepare a government institutional email domain and/or an institutional website, as this may be required to enable the flow.\n- As an organization document, you may need to submit proof on official letterhead (when applicable).\n\n### 2) Problems receiving OTP (SMS/call)\n\nThe flow usually allows OTP via SMS or phone call.\n\nQuick checklist:\n\n- Try switching between SMS and call.\n- Check carrier blocks/IVR/anti-spam.\n- Make sure the phone number is correct and has signal.\n\n### 3) \"My document was rejected\"\n\nCommon causes:\n\n- Expired document.\n- Dark/blurry photo.\n- Part of the document covered/cropped.\n- Document not in the accepted list for your country/region.\n\nThe fix is usually simple: resend with a better image and an accepted document, without edits.\n\nImportant notes:\n\n- The account owner receives an email detailing the specific reason for rejection. Read it carefully before resubmitting.\n- You may have **limited attempts** to upload identity documents. If you hit the limit, you usually need to request a new attempt through support.\n\n### 4) Organization name doesn't match D-U-N-S\n\nIf the submitted document shows a name different from the one registered in D-U-N-S, verification can fail.\n\nTo avoid that:\n\n- Use documents that show the name exactly as it appears in D-U-N-S.\n- Avoid submitting documents for a parent company/holding/subsidiary if the D-U-N-S is registered under another name.\n\n### 5) Authorized representative's name typed differently from the document\n\nThe form needs to match the document exactly.\n\n- Check accents, abbreviations, and name order.\n- Copy it exactly as shown on the document.\n\n### 6) Verification failed: check details and, if needed, appeal\n\nWhen verification fails, Play Console shows the reason on the home page and the owner receives emails with details.\nIn general, there is a \"More details\" button and an appeal option, where you explain the case and attach additional information.\n\n![\"Failure](\"/assets/img/google-play-verificacao-09-falha-detalhes.png\" "\\"When")
\n\n## Final checklist: how to know the account is ready to publish\n\nBefore you consider it \"ready to publish\", confirm:\n\n1. The account type is correct (Organization).\n2. Payments profile is linked and has the correct **legal name + address**.\n3. D-U-N-S entered and confirmed (when applicable), with no discrepancies.\n4. Private contact (email + phone) verified via OTP.\n5. Public profile (email + phone) verified and reviewed.\n6. Organization documents accepted and representative identity verified.\n7. If the account monetizes: merchant payment method verified (when requested).\n8. The \"Account details\" page shows the organization as verified (and verification banners no longer appear).\n\nIf you will work with a partner (agency/consultancy/external team) to publish apps, finish this checklist first. It prevents publishing from turning into a race against the clock on launch day.\n"},"88589802-00ef-502a-9262-f7e6b45813af":{"id":"88589802-00ef-502a-9262-f7e6b45813af","title":"DNS Pointing (A Record): how to create an HTTPS URL for your API and publish your app safely","content":"\n> \"If you only have a server IP, you're still missing the most important part for production apps: a stable and secure HTTPS URL.\"\n\nWhen a development team delivers an API or an admin/web portal, companies often receive only a **server IP address**. That may work for quick tests, but it becomes a problem when it is time to publish and maintain an app in stores.\n\nIn practice, modern iOS/Android apps and web apps should connect to the backend through **HTTPS** (secure transport). To do HTTPS properly, you need a **domain or subdomain**, not only an IP.\n\nIn this article, you'll learn how to configure **DNS A record pointing** (the most common setup when you receive an IPv4) and how to organize this process without unnecessary friction.\n\n![Cover image: DNS A record pointing](/assets/img/dns-apontamento-capa.png \"DNS A record pointing: from IP to an HTTPS URL.\")\n\n## What you'll learn\n\n- Why using an IP directly in a production app API is risky\n- What DNS is and what an **A record** does\n- How to choose the right **subdomain** without buying a second domain\n- A standard step-by-step that works for any provider\n- Provider-specific notes: Registro.br, GoDaddy, Cloudflare, AWS, Google, Microsoft, and others\n- What DNS propagation means (in plain language)\n- Using your existing domain vs. buying a separate one\n- A final checklist to avoid mistakes\n\n## Why not use only the server IP\n\nThese are the most common reasons this becomes a blocker at publishing time:\n\n![Direct IP vs domain](/assets/img/dns-apontamento-01-ip-vs-dominio.png \"Simple comparison: direct IP vs domain/subdomain.\")\n\n1. Proper HTTPS setup becomes hard (or impractical). \nTLS certificates are issued for hostnames (URLs), not for most direct IP use cases.\n\n2. IP changes can break your app. \nIf infrastructure changes (new server, migration, load balancer), the IP can change and force emergency updates.\n\n3. Domains give you structure and stability. \nExample:\n- `api.yourdomain.com` -> API\n- `admin.yourdomain.com` -> admin portal\n- `www.yourdomain.com` -> company site\n- `staging-api.yourdomain.com` -> staging\n\n4. Security and best practices. \nFor production, the expected baseline is **HTTPS with a valid certificate**.\n\n![Why HTTPS matters](/assets/img/dns-apontamento-04-por-que-https.png \"Modern apps and platforms expect HTTPS by default.\")\n\n## Quick concept: DNS and A record\n\nDNS is the internet's address book: it maps human-friendly names (like `api.yourdomain.com`) to real network addresses.\n\nAn **A record** maps a hostname to an **IPv4** address (for example `203.0.113.10`).\n\nIf your infrastructure is IPv6-first, the equivalent record type is usually **AAAA**.\n\n## Pre-checklist before starting\n\nBefore touching DNS, confirm:\n\n1. Which domain you'll use (for example `yourdomain.com`).\n2. Which subdomain you'll create (for example `api`).\n3. The correct IPv4 from your technical team.\n4. Where DNS is actually managed (registrar and DNS host can be different).\n5. You're adding a new record, not accidentally changing email/site records.\n6. You understand that DNS does not configure ports or certificates by itself.\n\nImportant note:\n- A records only map **name -> IP**.\n- Production app endpoints should normally be `https://api.yourdomain.com` (HTTPS default on port 443).\n\n## Standard step-by-step (works in any provider)\n\n1. Open your DNS management panel.\n2. Click to add a new DNS record.\n3. Select record type **A**.\n4. Fill the fields:\n- Host/Name: `api`\n- Value/Points to: `YOUR_SERVER_IP`\n- TTL: `300` (5 min) or `3600` (1h)\n5. Save.\n6. Wait for DNS propagation.\n7. Configure HTTPS on the server or reverse proxy.\n\n![A record example](/assets/img/dns-apontamento-02-registro-a-exemplo.png \"Example of filling an A record.\")\n\n## If your team gave you a hostname instead of an IP\n\nSometimes your provider endpoint looks like this:\n\n- `my-load-balancer.something.cloud`\n- `my-distribution.something.cdn`\n\nIn this case, the correct setup may be:\n\n- `CNAME` for subdomains, or\n- provider-specific alias records (for example Route 53 alias).\n\nIf you only got a hostname, confirm with the technical team before creating an A record.\n\n## DNS propagation (without jargon)\n\nAfter saving DNS, changes are not visible everywhere at the exact same second.\n\nThat delay is called **propagation**, and it can range from minutes to several hours depending on TTL, caches, and ISP resolvers.\n\n![DNS propagation](/assets/img/dns-apontamento-03-propagacao.png \"DNS propagation takes time and can vary by region/provider.\")\n\n## What if the IP changes later?\n\nIf your API subdomain is already in place, you usually only need to update the record value to the new IP.\n\nThe app can keep using the same URL (`api.yourdomain.com`) while infrastructure changes behind the scenes.\n\nThis is one of the biggest advantages of a domain-first setup.\n\n## Provider notes\n\n## 1) Registro.br (when DNS is hosted there)\n\n- Go to DNS zone management.\n- Add a new **A** entry.\n- Set host (`api`), value (IPv4), and TTL.\n- Save and validate propagation.\n\n## 2) GoDaddy\n\n- Open DNS records for the domain.\n- Add type **A**.\n- Host: `api`, points to: IPv4.\n- Save and wait.\n\n## 3) Cloudflare\n\n- Open DNS tab.\n- Add **A** record.\n- Host: `api`, value: IPv4.\n- Decide proxy mode (orange cloud) with your technical team.\n\n## 4) Amazon AWS (Route 53)\n\n- Open hosted zone.\n- Create record.\n- Type: **A**, name: `api`, value: IPv4.\n- Save.\n\n## 5) Google Cloud DNS\n\n- Open Cloud DNS zone.\n- Add record set.\n- Type: **A**, name: `api`, data: IPv4.\n\n## 6) Microsoft Azure DNS\n\n- Open DNS zone.\n- Add record set.\n- Type: **A**, name: `api`, IP address: IPv4.\n\n## 7) Namecheap (extra)\n\n- Advanced DNS.\n- Add host record type **A**.\n- Host `api`, value IPv4, save.\n\n## 8) Hostinger (extra)\n\n- DNS zone editor.\n- Add type **A**.\n- Host `api`, value IPv4, TTL.\n\n## Other providers\n\nThe names in the UI change, but the logic is the same:\n- choose **A**,\n- set host,\n- set IPv4,\n- save and wait propagation.\n\n## Use your existing domain or buy a separate one?\n\nBoth options can work. In most projects, using your existing domain with subdomains is simpler.\n\n### Advantages of using your existing domain\n\n- Fewer things to renew\n- Stronger brand consistency\n- Less operational overhead\n\n### Disadvantages (and how to avoid them)\n\n- Accidental edits in DNS zone can affect other services \nUse change control and clear ownership.\n\n### When a separate domain makes sense\n\n- Strict governance/isolation requirements\n- Different brand/product needing independent ownership\n\n## What to request from your technical team\n\nAsk for:\n\n- Production server IPv4 (or explicit guidance to use CNAME/alias)\n- Subdomain to create (usually `api`)\n- A healthcheck endpoint (for example `/health`)\n- Confirmation that HTTPS certificate will be installed after DNS setup\n\n## Final checklist (copy and paste)\n\n- [ ] Subdomain chosen (`api.yourdomain.com`)\n- [ ] A record created with the correct IPv4\n- [ ] Existing DNS records were not altered by mistake\n- [ ] Propagation time considered\n- [ ] HTTPS certificate installed and valid\n- [ ] Endpoint tested over HTTPS\n\nWhen this is in place, your app has a stable and secure URL to communicate with backend services and move safely toward publication.\n"},"43710619-1564-52ef-bda6-faea5d76e6cd":{"id":"43710619-1564-52ef-bda6-faea5d76e6cd","title":"Como acelerar seu CI: cache, concorrencia e boas praticas no GitLab Runner","content":"\n## Antes de \"comprar maquina\": descubra onde esta o gargalo\n\nTres coisas deixam CI lento (e quase ninguem mede):\n\n1. **Fila**: job esperando runner disponivel. \n2. **Download**: dependencias e imagens baixando toda hora. \n3. **CPU/IO**: build e testes realmente consumindo recurso.\n\nA ordem importa porque, se o problema e fila, so otimizar build nao resolve.\n\n## 1. Concorrencia: `concurrent` e `limit` (o que muda na pratica)\n\nNo GitLab Runner, o arquivo `config.toml` controla quantos jobs um runner consegue processar ao mesmo tempo.\n\nExemplo de configuracao:\n\n```toml\nconcurrent = 4\n\n[[runners]]\n name = \"runner-dedicado\"\n limit = 2\n```\n\n- `concurrent` (global) limita quantos jobs **no total** podem rodar ao mesmo tempo naquele host.\n- `limit` (por runner) limita quantos jobs **aquele runner especifico** aceita em paralelo.\n\nAjuste com consciencia:\n- se voce aumenta concorrencia sem aumentar CPU/RAM, voce \"so divide a dor\"\n- para front-end, normalmente e melhor 2-4 jobs bem estaveis do que 8 jobs brigando por memoria\n\n## 2. Cache e artifacts: aceleracao barata (e altamente subestimada)\n\n### Cache (dependencias e build intermediario)\nUse cache para:\n- `node_modules` (quando fizer sentido)\n- pasta do `pnpm store` / `.yarn/cache`\n- cache de bundler (ex.: `.vite`, `.next/cache`)\n\nIdeia simples: *baixar uma vez, reutilizar varias*.\n\n### Artifacts (saidas do job)\nArtifacts sao bons para:\n- build de front (resultado do `dist/`)\n- relatorios (coverage, testes)\n- pacotes a serem implantados\n\nCuidado: artifacts grandes deixam o pipeline lento de outro jeito (upload/download).\n\n## 3. Tags de runner: separando o que \"precisa\" do que \"pode\"\n\nSeparar runners por tags resolve dois problemas:\n- jobs criticos nao ficam presos atras de jobs longos\n- voce evita rodar job \"caro\" em maquina \"barata\"\n\nSugestao pratica:\n- `runner:fast` lint/typecheck/unit\n- `runner:e2e` Cypress/Playwright\n- `runner:macos` iOS/macOS\n- `runner:windows` Windows-only\n\n## 4. Docker executor: performance + isolamento (com um alerta)\n\nO Docker executor e uma otima escolha porque cada job roda em container e o ambiente fica reproduzivel.\n\nO alerta e seguranca: dependendo da configuracao (ex.: containers privilegiados), voce pode abrir riscos desnecessarios. Trate \"isolamento\" como requisito, especialmente se o runner for compartilhar projetos.\n\n## 5. Checklist rapido de \"ganhos faceis\" (30-60 min)\n\n- habilitar cache (dependencias + bundler)\n- reduzir downloads (pin de imagens base, registry perto do runner)\n- dividir pipeline em jobs menores e paralelizaveis\n- limitar concorrencia para manter estabilidade\n- colocar runner em SSD e rede cabeada\n- separar tags (E2E nao deveria competir com lint)\n\n---\n\n## Referencias uteis\n- Advanced configuration (`concurrent`, `limit`): https://docs.gitlab.com/runner/configuration/advanced-configuration.html \n- Docker executor: https://docs.gitlab.com/runner/executors/docker.html \n"},"91648377-70ef-57ed-9ef6-ae5ec5cc1d70":{"id":"91648377-70ef-57ed-9ef6-ae5ec5cc1d70","title":"Ambientes (Homologacao vs Producao): por que separar e como isso impacta o app","content":"\n> **Homologacao existe para voce conseguir errar com seguranca - sem \"quebrar\" a vida de quem esta usando o app de verdade.**\n\nSe voce ja ouviu frases como \"sobe ai que eu testo\", \"vamos testar direto no ar\" ou \"tanto faz o ambiente\", este artigo e para voce.\n\nQuando um app (e sua API) nao tem ambientes separados, quase sempre acontece uma destas duas coisas:\n\n- O time fica com medo de atualizar (\"vai que quebra para todo mundo\") e o produto para de evoluir; ou\n- O time atualiza rapido, mas com risco alto, e quem paga a conta e o usuario final (instabilidade, dados inconsistentes, suporte sobrecarregado).\n\nSeparar **Homologacao (Staging)** e **Producao** e uma das praticas mais simples para reduzir risco e acelerar a evolucao do app no medio e longo prazo.\n\n![Equipe validando codigo em multiplas telas antes da publicacao](/assets/img/ambientes-homologacao-vs-producao.jpg \"Ambientes (Homologacao vs Producao): por que separar e como isso impacta o app.\")\n\n## O que voce vai ver aqui\n\n- O que e \"Homologacao/Staging\" e o que e \"Producao\" (sem tecnices)\n- Exemplos simples do que da errado quando mistura tudo\n- Quais dados **devem** e **nao devem** ir para homologacao\n- Como isso afeta URLs (api., admin., app.) e organizacao de dominios\n- Como isso impacta lojas e testes (Play Console / TestFlight)\n- Um checklist pratico para voce organizar isso no seu projeto\n\n---\n\n## 1) O que e cada ambiente sem tecnices\n\nPense em ambientes como \"lugares diferentes\" onde o mesmo sistema pode rodar, com propositos diferentes.\n\n| Ambiente | Para que serve | Quem usa | Regra de ouro |\n|---|---|---|---|\n| **Desenvolvimento (DEV)** | Construir e testar rapido | time tecnico | pode \"quebrar\" sem grandes consequencias |\n| **Homologacao / Staging (HML)** | Validar como se fosse producao (UAT), com processo e checklist | time + cliente | deve ser parecido com producao, mas com **dados controlados** |\n| **Producao (PROD)** | Operacao real do negocio | usuarios finais | estabilidade e dados reais em primeiro lugar |\n\nHomologacao (ou *staging*) e, na pratica, o \"ensaio geral\" antes de colocar a mudanca para usuarios reais.\n\n![Fluxo recomendado de ambientes](/assets/img/ambientes-hml-prod-01-fluxo.svg \"Fluxo recomendado: DEV Homologacao (UAT) Producao.\")\n\n---\n\n## 2) Por que separar Homologacao e Producao\n\nSeparar ambientes parece \"burocracia\", mas na pratica e o que evita retrabalho e crise.\n\nOs principais ganhos:\n\n1. **Voce testa sem baguncar dados reais** \n Teste de cadastro, pedido, pagamento, regras tudo isso gera dados. Em producao, esses dados viram \"verdade\" (relatorios, financeiro, suporte).\n\n2. **Voce reduz risco de instabilidade para usuarios** \n Uma mudanca de API ou banco pode quebrar o app para todos se nao houver uma etapa de validacao antes.\n\n3. **Voce mantem privacidade e conformidade** \n Homologacao nao costuma ter o mesmo nivel de protecao e controles de acesso de producao. Por isso, dados reais exigem cuidado.\n\n4. **Voce ganha previsibilidade no deploy** \n A mudanca segue um caminho: sobe em homologacao valida publica em producao.\n\n5. **Voce facilita suporte e diagnostico** \n Quando existe homologacao, da para reproduzir problemas com seguranca e testar correcoes sem \"mexer\" no que esta ao vivo.\n\n---\n\n## 3) Exemplos simples do que da errado quando mistura tudo\n\nEsta lista e baseada em problemas comuns que travam projeto (e geram discussao desnecessaria).\n\n![Problemas comuns quando mistura ambientes](/assets/img/ambientes-hml-prod-02-problemas.svg \"Quando homologacao e producao viram a mesma coisa, os problemas aparecem rapido.\")\n\n### Exemplo 1: \"So um testezinho\" vira bagunca no financeiro\nO cliente pede para \"testar uma compra\", o time cria pedidos, estorna, cria de novo \nResultado: relatorios errados, conciliacao confusa e discussoes do tipo \"faltou repasse\".\n\n### Exemplo 2: O app \"avisou\" o usuario errado\nVoce testa uma notificacao push, um e-mail ou um SMS. \nSem separacao, o disparo pode ir para usuarios reais.\n\n### Exemplo 3: Um ajuste no banco quebra o app em horario comercial\nUma migracao de banco ou alteracao de regra entra direto em producao. \nO app comeca a dar erro para todo mundo, e o time entra em modo \"apagar incendio\".\n\n### Exemplo 4: Metricas viram lixo\nSe voce testa em producao, seus analytics misturam \"uso real\" com \"testes\". \nDepois, ninguem confia nos numeros.\n\n### Exemplo 5: Dados pessoais em ambiente fragil\nCopiar dados de producao para \"qualquer servidor\" de teste e uma fonte comum de incidente. \nMesmo que seja \"so para testar\", e um risco de exposicao que da para evitar com processo.\n\n---\n\n## 4) Quais dados devem e nao devem ir para homologacao\n\nO objetivo da homologacao e parecer producao no comportamento - nao necessariamente nos dados.\n\nA regra pratica e:\n\n- **Homologacao precisa de dados suficientes para validar os fluxos.**\n- **Producao e o unico lugar para dados reais do negocio.**\n\n### Tabela pratica para leigos\n\n| Tipo de dado | Pode ir para homologacao? | Recomendacao simples |\n|---|---:|---|\n| **Dados pessoais reais** (CPF, endereco, e-mail de cliente real) | Evite | Use dados ficticios ou anonimizados. Se precisar de \"realismo\", use mascaramento/anonimizacao com processo. |\n| **Dados financeiros sensiveis** (cartao, dados bancarios) | Nao | Use ambientes sandbox dos provedores (pagamento, antifraude, etc.). |\n| **Pedidos/contratos reais** | Nao | Use \"massa de teste\" (pedidos ficticios). |\n| **Usuarios de teste** (contas internas) | Sim | Crie perfis proprios para testes e UAT. |\n| **Catalogo/parametrizacoes** (produtos, categorias, tabelas) | Sim | Pode copiar de producao com cuidado, desde que nao exponha dados pessoais. |\n| **Chaves de servicos** (Pix, e-mail, push, mapas) | (se forem de teste) | Tenha chaves separadas: *sandbox/teste* para homologacao e *producao* para producao. |\n\n### Um jeito simples de organizar dados de homologacao\n\nSe voce quer um modelo rapido (que funciona):\n\n1. **Massa de teste padrao**: cadastros ficticios, produtos ficticios, pedidos ficticios. \n2. **\"Quase real\" sem expor**: catalogos e configuracoes copiadas, mas sem dados pessoais. \n3. **Casos extremos**: poucos dados anonimizados (quando realmente necessario), com acesso restrito.\n\n---\n\n## 5) Como isso afeta URLs de API, admin e app\n\nA separacao de ambientes aparece claramente nas URLs.\n\nO padrao mais comum e ter **subdominios diferentes** para cada ambiente.\n\n![Exemplo de URLs por ambiente](/assets/img/ambientes-hml-prod-03-urls.svg \"Separar por subdominios facilita testes e reduz risco.\")\n\n### Exemplo de organizacao recomendada\n\nProducao:\n- `https://api.seudominio.com` (API do app)\n- `https://admin.seudominio.com` (portal administrativo)\n- `https://www.seudominio.com` (site)\n\nHomologacao:\n- `https://hml-api.seudominio.com` (API homologacao)\n- `https://hml-admin.seudominio.com` (portal homologacao)\n\nPor que isso e bom?\n\n- Fica evidente quando alguem esta em homologacao (menos erro humano).\n- Voce consegue configurar HTTPS certo para cada ambiente.\n- Voce reduz o risco do app apontar para o lugar errado.\n\nSe voce ainda esta no estagio de \"temos so um IP\", vale ler tambem o post: \n[Apontamento de DNS (Registro A): como criar uma URL HTTPS para sua API](/apontamento-dns-registro-a-https)\n\n---\n\n## 6) Como isso impacta o app no Android e no iOS\n\nPara o usuario, \"o app e um so\". Para o time, existem pelo menos dois aplicativos no dia a dia:\n\n- **App de homologacao**: para testes internos e validacao com o cliente (UAT).\n- **App de producao**: o app publicado, usado por usuarios reais.\n\n### Como evitar confusao com uma regra simples\n\nNo app de homologacao:\n\n- Nome diferente (ex.: \"MeuApp (HML)\")\n- Icone diferente (para ninguem confundir)\n- Aponta para `hml-api...`\n- Usa chaves de servicos de teste (sandbox)\n\nNo app de producao:\n\n- Nome oficial\n- Icone oficial\n- Aponta para `api...`\n- Usa chaves de producao\n\n### E as lojas e testes nas lojas\n\nVoce nao precisa \"publicar para todo mundo\" para testar.\n\n- No **Android**, voce pode distribuir versoes de teste usando trilhas de teste (por exemplo, teste interno/fechado/aberto) antes da versao de producao.\n- No **iOS**, o fluxo comum de testes e pelo **TestFlight**, antes de enviar para revisao/publicacao.\n\nA parte importante aqui e: **o build de teste deve apontar para homologacao**, e o build de producao deve apontar para producao. Isso evita que um beta acesse dados reais por engano.\n\n---\n\n## 7) Como isso impacta o portal administrativo web\n\nO portal/admin normalmente e onde nascem os problemas quando nao ha separacao.\n\nSem ambiente de homologacao:\n\n- o time testa direto no portal \"real\"\n- dados mudam\n- permissoes mudam\n- regras mudam\n- e depois ninguem sabe \"o que foi teste e o que foi operacao\"\n\nCom separacao, fica muito mais simples:\n\n- `hml-admin...` para UAT e validacao\n- `admin...` para operacao\n\nDica pratica: em homologacao, use um **banner visivel** do tipo \"VOCE ESTA EM HOMOLOGACAO\" para evitar erro humano.\n\n---\n\n## 8) Um processo recomendado simples para nao virar caos\n\nSe voce quer um fluxo \"padrao\" que funciona na maioria dos projetos:\n\n1. **Desenvolver e testar internamente** (DEV) \n2. **Subir para homologacao** (HML) \n3. **Validar com checklist por tela/fluxo** (UAT) \n4. **Dar \"OK para publicar\"** (criterio claro) \n5. **Publicar em producao** (PROD) \n6. **Monitorar e corrigir rapido** (hotfix se necessario)\n\nSe voce quer um modelo de validacao para o item 3 e 4, este post ajuda: \n[Como aprovar rapidamente telas e fluxos (sem virar troca infinita de feedback)](/como-aprovar-rapidamente-telas-e-fluxos)\n\n---\n\n## 9) Checklist rapido do que precisa existir para separar ambientes\n\nUse este checklist como alinhamento com seu time (ou com o fornecedor).\n\n![Checklist de separacao de ambientes](/assets/img/ambientes-hml-prod-04-checklist.svg \"Checklist rapido para separar homologacao e producao.\")\n\n### Infra / URLs\n- [ ] Existe URL de producao (api/admin) com HTTPS\n- [ ] Existe URL de homologacao (hml-api/hml-admin) com HTTPS\n- [ ] O DNS/subdominios estao apontados corretamente\n\n### Dados\n- [ ] Homologacao nao usa dados pessoais reais sem processo\n- [ ] Existe massa de teste e contas de teste\n- [ ] Chaves e integracoes sao de sandbox em homologacao\n\n### App e lojas\n- [ ] Existe build de homologacao (nome/icone diferente)\n- [ ] Existe build de producao (oficial)\n- [ ] O time sabe como distribuir para teste (Play Console/TestFlight)\n\n### Processo\n- [ ] Existe um checklist de \"OK para publicar\"\n- [ ] Existe janela e rotina de deploy (quem publica, quando, como reverte)\n- [ ] Existe monitoramento minimo para producao (erros, disponibilidade)\n\n---\n\n## Perguntas comuns com respostas rapidas\n\n### Precisa duplicar tudo\nNao necessariamente. Voce pode reaproveitar a infraestrutura, mas precisa separar **o que e critico**: URLs, banco/dados, chaves e processo.\n\n### Posso usar o mesmo banco para homologacao e producao\nNa pratica, isso tende a recriar o problema (mistura de dados). O ideal e banco separado. Se nao der, no minimo separar por base/tabelas/conta e com acesso extremamente controlado.\n\n### Homologacao pode ter senha fraca por ser teste\nNao. Homologacao costuma ser o alvo mais facil. A regra e: **mais seguro do que parece necessario**, principalmente se tiver qualquer dado real.\n\n### O que e melhor entre homologacao no mesmo servidor ou em outro\nDepende do projeto. Para leigos, pense assim: o importante e **nao misturar** e nao \"derrubar\" producao quando mexer em homologacao.\n\n---\n\n## Conclusao\n\nSeparar ambientes e uma dessas decisoes que parecem \"detalhe tecnico\", mas que definem a qualidade do projeto.\n\nCom homologacao e producao bem organizados, voce ganha:\n\n- mais previsibilidade,\n- menos susto em deploy,\n- menos retrabalho,\n- mais confianca para evoluir o app depois do lancamento.\n\nSe voce quiser ajuda para estruturar isso (ambientes, DNS/HTTPS, rotina de deploy e operacao pos-lancamento), a X-Apps pode apoiar com governanca e operacao continua do software.\n\n[Conheca a Operacao DevOps da X-Apps](https://www.x-apps.com.br/servicos/operacao-devops)\n"},"775ddc5e-b107-5e12-8a01-580ba85bd0de":{"id":"775ddc5e-b107-5e12-8a01-580ba85bd0de","title":"Verificacao da conta de desenvolvedor no Google Play Console para organizacoes","content":"\n> \"Criar a conta e so o comeco. Para publicar com seguranca, a verificacao precisa estar concluida.\"\n\nSe a sua empresa criou uma conta no Google Play Console e parou por ai, e bem provavel que voce encontre travas no momento de publicar ou atualizar um aplicativo.\n\nO Google exige que desenvolvedores concluam um processo de verificacao. Para organizacoes, esse processo e mais completo porque envolve confirmacao dos dados da empresa e envio de documentos oficiais. Se voce deixar para a ultima hora, pode acabar com pendencias que atrasam a publicacao, ou, no pior cenario, com restricoes na conta.\n\nEste conteudo foi organizado com base em um guia oficial do proprio Google Play direcionado a **contas de Organizacao** (edicao de outubro/2024) e estruturado em formato de checklist para facilitar a execucao.\n\nNeste post, eu organizei o processo em um passo a passo simples, com checklist e correcoes comuns. O objetivo e voce conseguir olhar para a conta e responder: **\"esta 100% verificada e pronta para publicar?\"**\n\n**Acesso rapido oficial:** Abrir Google Play Console.\n\n\n\n## O que voce vai ver aqui\n\n- O que muda quando a conta e \"Organizacao\"\n- Checklist do que separar antes de iniciar\n- Etapa 1: dados da organizacao (D-U-N-S, pagamentos, contatos e perfil publico)\n- Etapa 2: envio de documentos (empresa + representante autorizado)\n- Etapa 3 (se aplicavel): verificacao da forma de pagamento de comerciante\n- Principais erros e como corrigir sem estresse\n- Checklist final para saber se esta tudo ok\n\n## Antes de tudo: por que fazer isso agora (e nao no dia da publicacao)\n\nO fluxo de verificacao costuma aparecer como um aviso na pagina inicial do Play Console, com um prazo. Em geral, da para iniciar a verificacao **ate 60 dias antes** da data limite informada no proprio console.\n\nE aqui estao 3 pontos que valem ouro:\n\n1. **So o proprietario da conta pode iniciar/concluir a verificacao.**\nSe a pessoa que criou a conta nao esta mais na empresa, ou nao tem mais acesso, voce precisa resolver isso antes de tudo.\n2. **Comece o quanto antes.**\nO processo pode envolver validacoes e analise de documentos que levam tempo.\n3. **Perder o prazo pode causar restricoes na conta.**\nNa pratica, isso vira urgencia, correcoes rapidas e retrabalho.\n\n\n\n## Checklist de preparacao (separe isso antes de clicar em \"Verificar\")\n\nAntes de iniciar o fluxo, reuna:\n\n- Razao social e endereco da empresa (exatamente como constam nos registros oficiais).\n- Numero **D-U-N-S** da organizacao (quando aplicavel).\n- Um e-mail e telefone \"privados\" para o Google falar com a empresa (serao validados por OTP).\n- Um e-mail e telefone \"publicos\" do desenvolvedor (aparecem no perfil do Google Play e tambem sao validados por OTP).\n\nDuas recomendacoes praticas:\n\n- **Use dados institucionais e acessiveis pelo time**, nao um celular pessoal \"temporario\".\n- Garanta que quem vai receber OTP (SMS/ligacao) e e-mails esteja disponivel durante o processo.\n\nSe voce ainda nao tem tudo isso em maos, o Play Console permite solicitar **uma extensao** do prazo (quando disponivel no aviso).\n\n\n\n## Etapa 1: iniciar a verificacao e preencher os dados da organizacao\n\n### 1) Confirme o tipo de conta: \"Organizacao\" x \"Pessoal\"\n\nPara empresas formalmente constituidas, o tipo correto e **Organizacao**.\n\nPor que isso importa?\n\n- O tipo de conta define quais verificacoes serao exigidas.\n- Depois de concluir as verificacoes, **nao da para mudar o tipo de conta** com facilidade.\n- O tipo nao muda os recursos gerais da conta, mas pode impactar requisitos para publicar certas categorias.\n\n\n\n### 2) Vincule um Perfil para pagamentos do Google\n\nO Play Console pede que voce vincule (ou crie) um **perfil para pagamentos do Google** para confirmar informacoes da organizacao.\n\nO que realmente importa aqui e:\n\n- O perfil armazena dados que podem ser usados em produtos do Google (incluindo dados da organizacao).\n- Para verificacao, ele e usado para coletar e validar informacoes como **razao social, endereco e D-U-N-S**.\n- Esses dados precisam estar **precisos e atualizados**.\n\nDica importante: se a empresa ja monetiza apps, pode existir um perfil para pagamentos usado para receitas. No fluxo de verificacao, o perfil selecionado pode ser usado **apenas para confirmar dados da organizacao**, sem necessariamente ser o mesmo da monetizacao.\n\n\n\n### 3) Informe o numero D-U-N-S (e confira se tudo bate)\n\nDepois do perfil de pagamentos, voce informa o **D-U-N-S** (um identificador de 9 digitos para organizacoes).\n\nPontos criticos:\n\n- Voce tem **tentativas limitadas** para digitar o D-U-N-S corretamente.\n- Se a empresa ainda nao tem D-U-N-S, isso pode levar tempo para conseguir (em alguns casos, **30 dias ou mais**). Planeje com antecedencia.\n- O D-U-N-S traz dados comerciais associados, e voce precisara confirmar.\n- Para alguns orgaos governamentais, pode existir um fluxo de verificacao sem D-U-N-S (o Play Console informa quando essa opcao esta disponivel).\n\n\n\n### 4) Regra de ouro: razao social e endereco precisam coincidir\n\nApos informar o D-U-N-S, o Play Console mostra as informacoes comerciais encontradas. Voce deve revisar e confirmar.\n\nA regra que mais causa erro e simples:\n\n**A razao social e o endereco do D-U-N-S precisam ser iguais aos do Perfil para pagamentos.**\n\nSe houver inconsistencia, o fluxo pode travar e voce entra em um ciclo de correcoes. Quando o Play Console detecta divergencias, pode haver um prazo (por exemplo, **28 dias**) para corrigir antes que a conta e os apps sofram restricoes.\n\n\n\n### 5) Conte mais sobre a organizacao (informacoes internas)\n\nO Play Console pede alguns dados adicionais sobre a empresa (por exemplo, estrutura/tamanho).\nEssas informacoes sao usadas pelo Google para entender e verificar melhor a organizacao e **nao aparecem publicamente** para usuarios na loja.\n\n### 6) Configure os contatos privados da conta (para o Google falar com a empresa)\n\nVoce informara um e-mail e um telefone de contato \"privados\" (nao publicos), que serao verificados com uma senha unica (OTP).\n\nBoas praticas:\n\n- Tenha acesso ao e-mail e ao telefone no momento da verificacao.\n- Se o SMS falhar, tente **ligacao**, e vice-versa.\n- Evite usar numeros que dependem de URA/telefonia com bloqueios para chamadas automaticas.\n\n\n\n### 7) Configure os contatos publicos do perfil de desenvolvedor\n\nContas de **Organizacao** precisam informar:\n\n- Um e-mail publico do desenvolvedor\n- Um telefone publico do desenvolvedor\n\nEsses dados ficam visiveis no perfil publico no Google Play e tambem passam por verificacao via OTP.\n\nNo fim, o Play Console mostra uma tela para revisar o perfil publico. Revise com cuidado, porque e isso que o usuario final vera.\n\n\n\n## Etapa 2: enviar documentos para verificar a organizacao e a identidade\n\nDepois de enviar os dados da organizacao, chega a etapa de documentos. O Play Console avisa quando o upload estiver disponivel.\n\nAqui vai o alerta mais importante desta etapa:\n\n**Enviar documentos nao aceitos (ou imagens ruins) e a causa n 1 de falhas na verificacao.**\nE documentacao alterada, manipulada ou falsificada pode levar a remocao imediata da conta e dos apps.\n\n### 1) Envie documentos de registro da organizacao\n\nVoce vai enviar documentos oficiais de registro da empresa (exemplos comuns: atos constitutivos, certificado de registro, inscricao fiscal equivalente).\n\nO que observar:\n\n- Os documentos precisam ser emitidos por uma autoridade confiavel (governo/cartorio/orgao de registro ou equivalente).\n- Em muitas empresas, isso fica com o juridico/financeiro.\n- O Play Console mostra quais documentos sao aceitos conforme pais e regiao.\n\n\n\n\n\n### 2) Confirme a identidade de um representante autorizado\n\nAlem dos documentos da empresa, alguem precisa confirmar a propria identidade com um documento valido.\n\nQuem pode fazer?\n\n- O proprietario da conta do Play Console, ou\n- **Qualquer representante autorizado da organizacao** (desde que consiga comprovar).\n\nPontos de atencao:\n\n- O tipo de documento aceito varia por pais/regiao.\n- Nao edite a imagem do documento.\n- Garanta que a foto/scan esteja nitida, bem iluminada e com todas as informacoes visiveis.\n\n\n\n### 3) Digite o nome e endereco exatamente como estao no documento\n\nO formulario pede que voce digite nome e endereco conforme aparecem no documento de identificacao enviado.\nAqui, erros de digitacao (mesmo pequenos) podem causar reprovacao.\n\nPor que o Google pede um documento de identificacao pessoal?\n\nA ideia e reduzir fraudes e abuso na plataforma. A orientacao oficial e que o documento e armazenado com seguranca e nao e compartilhado com usuarios.\n\n## Etapa 3: verificacao da forma de pagamento de comerciante (se voce gera receita)\n\nEsta etapa vale para contas que geram receita com o Google Play (por exemplo, usando faturamento/monetizacao).\n\nO Play Console pode pedir verificacao da **forma de pagamento de comerciante**, geralmente confirmando conta bancaria por metodos como:\n\na) Teste de deposito (confirmar um pequeno deposito)\nb) Envio de extrato bancario oficial\n\nEnquanto o Google analisa, o console pode mostrar um aviso de verificacao pendente.\n\nSe a verificacao da forma de pagamento falhar, normalmente o proprietario recebe um aviso por e-mail e o Play Console mostra o que aconteceu e como corrigir.\n\n\n\n## \"Deu erro\": problemas comuns e como resolver\n\n### 1) \"Nao encontro o proprietario da conta\"\n\nSomente o proprietario pode concluir a verificacao. Se a pessoa nao esta disponivel ou perdeu acesso:\n\n- Tente recuperar o acesso imediatamente (antes de qualquer outra etapa).\n- Se precisar de tempo, solicite extensao no Play Console (quando disponivel).\n- Se o e-mail do proprietario nao existe mais, o caminho tende a envolver suporte e comprovacao.\n\n### 1a) \"Minha organizacao e um orgao governamental e nao tem D-U-N-S\"\n\nEm alguns casos, organizacoes governamentais podem concluir a verificacao **sem** informar um D-U-N-S (quando a opcao ja estiver habilitada no fluxo).\n\nSe o Play Console nao oferecer essa alternativa e voce realmente nao tiver D-U-N-S:\n\n- Verifique se a conta esta cadastrada corretamente como Organizacao.\n- Prepare um dominio de e-mail institucional do governo e/ou um site institucional, pois isso pode ser solicitado para habilitar o fluxo.\n- Como documento de organizacao, pode ser necessario enviar comprovacao em papel timbrado do orgao (quando aplicavel).\n\n### 2) Problemas para receber OTP (SMS/ligacao)\n\nO fluxo costuma permitir OTP por SMS ou ligacao.\n\nChecklist rapido:\n\n- Tente alternar entre SMS e ligacao.\n- Verifique bloqueios de operadora/URA/antispam.\n- Garanta que o telefone informado esteja correto e com sinal.\n\n### 3) \"Meu documento foi rejeitado\"\n\nCausas comuns:\n\n- Documento expirado.\n- Foto escura/desfocada.\n- Parte do documento coberta/cortada.\n- Documento fora da lista aceita para seu pais/regiao.\n\nA correcao normalmente e simples: reenviar com imagem melhor e documento aceito, sem edicao.\n\nObservacoes importantes:\n\n- O proprietario da conta recebe um e-mail detalhando o motivo especifico da rejeicao. Leia com calma antes de reenviar.\n- Voce pode ter **tentativas limitadas** para upload de documentos de identidade. Se atingir o limite, o caminho costuma ser solicitar nova tentativa via suporte.\n\n### 4) Nome da organizacao nao bate com o D-U-N-S\n\nSe o documento enviado traz um nome diferente do cadastrado no D-U-N-S, a verificacao pode falhar.\n\nPara evitar isso:\n\n- Use documentos que mostrem o nome exatamente como esta no D-U-N-S.\n- Evite enviar documento de controladora/holding/subsidiaria se o D-U-N-S esta em outro nome.\n\n### 5) Nome do representante autorizado digitado diferente do documento\n\nO formulario precisa bater com o documento.\n\n- Confira acentos, abreviacoes e ordem dos nomes.\n- Copie exatamente como esta no documento.\n\n### 6) Falha na verificacao: veja os detalhes e, se necessario, conteste\n\nQuando a verificacao falha, o Play Console mostra o motivo na pagina inicial e o proprietario recebe e-mails com detalhes.\nEm geral existe um botao de \"Mais detalhes\" e a opcao de contestacao, onde voce explica o caso e anexa informacoes adicionais.\n\n\n\n## Checklist final: como saber se a conta esta pronta para publicar\n\nAntes de considerar \"ok para publicar\", confirme:\n\n1. O tipo de conta esta correto (Organizacao).\n2. Perfil para pagamentos vinculado e com **razao social + endereco corretos**.\n3. D-U-N-S inserido e confirmado (quando aplicavel) e sem divergencias.\n4. Contato privado (e-mail + telefone) verificado via OTP.\n5. Perfil publico (e-mail + telefone) verificado e revisado.\n6. Documentos da organizacao aceitos e identidade do representante confirmada.\n7. Se a conta monetiza: forma de pagamento de comerciante verificada (quando solicitado).\n8. A pagina \"Detalhes da conta\" mostra a organizacao como verificada (e os banners de verificacao nao aparecem mais).\n\nSe voce for trabalhar com um parceiro (agencia/consultoria/time externo) para publicar apps, finalize este checklist primeiro. Isso evita que a publicacao vire uma corrida contra o relogio no dia do lancamento.\n"},"a2b8ce23-9bd5-5a9e-9a4d-239a70d0ae5d":{"id":"a2b8ce23-9bd5-5a9e-9a4d-239a70d0ae5d","title":"Assinatura eletronica vs assinatura digital no Brasil (2026): validade juridica, ICP-Brasil e como implementar com trilha de auditoria","content":"\n> **\"Assinar online\" nao e colar um rabisco em um PDF. E construir evidencia: autoria, integridade, data e contexto - de um jeito verificavel.**\n\nA duvida aparece o tempo todo em empresas, fintechs, marketplaces, SaaS e ate em escritorios: \n\"**Assinatura eletronica vale?**\", \"**precisa de certificado ICP-Brasil?**\", \"**qual a diferenca de assinatura eletronica e assinatura digital?**\".\n\nA resposta curta e: **vale sim**, mas \"vale\" nao significa \"sem risco\". A diferenca entre um contrato que se sustenta e um contrato que cai em disputa costuma ser uma so: **forca probatoria (e rastreabilidade) do processo de assinatura**.\n\n> **Aviso importante**: este conteudo e tecnico e informativo. Nao constitui aconselhamento juridico. Para casos concretos, valide com advogado(a) responsavel e com o compliance da sua organizacao.\n\n![Equipe revisando documento e aprovando informacoes em mesa de trabalho](/assets/img/assinatura-eletronica-vs-assinatura-digital-icp-brasil.jpg \"Assinatura eletronica vs assinatura digital (Brasil) - guia 2026\")\n\n## O que voce vai aprender\n\n- Diferenca pratica entre **assinatura eletronica**, **assinatura digital** e **assinatura digitalizada** (imagem escaneada).\n- O que a legislacao brasileira diz (MP 2.200-2/2001, Lei 14.063/2020, Codigo Civil e CPC) - sem \"juridiques\".\n- Como escolher entre assinatura **simples**, **avancada** e **qualificada (ICP-Brasil)** usando uma matriz de risco.\n- Quais evidencias compoem uma **trilha de auditoria** forte (e por que isso importa em disputa).\n- Como implementar em produto: arquitetura, versionamento do documento, pacotes de evidencia e retencao.\n- Armadilhas comuns (e como nao transformar assinatura em \"ponto fraco\" do seu juridico).\n\n---\n\n## 1. Primeiro: o que as pessoas confundem (e por que da problema)\n\nTres termos sao usados como se fossem a mesma coisa:\n\n### Assinatura digitalizada (imagem)\nE literalmente uma **imagem** (ex.: scan da assinatura) inserida no documento. \nEla pode ate ajudar \"visualmente\", mas **nao garante integridade** (o PDF pode ser alterado depois) e **nao prova autoria** por si so.\n\nEm disputa, normalmente vira uma discussao sobre:\n- \"Quem inseriu essa imagem?\"\n- \"O documento foi alterado depois?\"\n- \"De onde veio esse arquivo?\"\n\n### Assinatura eletronica (conceito amplo)\nE qualquer forma eletronica de **manifestar vontade e identificar alguem**, com niveis diferentes de confianca. \nPode ir de um \"aceite com login\" ate mecanismos robustos com biometria, certificados, logs e hash.\n\n### Assinatura digital (no sentido criptografico)\nE uma **assinatura criptografica**, gerada com **chave privada** e verificada com **chave publica**, normalmente amarrada a um certificado digital (ICP-Brasil ou nao). \nAqui existe uma propriedade tecnica forte: se o documento for alterado, a assinatura \"quebra\".\n\nA parte importante: **a lei e o juiz nao \"compram tecnologia\"; eles compram prova.** \nA tecnologia e o que sustenta a prova quando alguem questiona.\n\n---\n\n## 2. Base legal no Brasil (o minimo que voce precisa saber)\n\nSem prometer \"receita de bolo\", da para organizar a base juridica em quatro blocos:\n\n### 2.1 MP 2.200-2/2001: ICP-Brasil e presuncao legal\n\nA Medida Provisoria n 2.200-2/2001 institui a ICP-Brasil e traz o ponto mais citado em discussoes de assinatura digital:\n\n- **Documentos eletronicos assinados com processo de certificacao ICP-Brasil tem presuncao de veracidade em relacao aos signatarios** (art. 10, 1).\n- A MP tambem diz que isso **nao impede outros meios de comprovacao de autoria e integridade**, inclusive certificados fora da ICP-Brasil, **desde que aceitos pelas partes ou pela pessoa a quem o documento for oposto** (art. 10, 2).\n\nEm portugues claro: **ICP-Brasil \"te da um atalho probatorio\"**. \nFora dele, voce continua podendo assinar - mas precisa ser mais disciplinado na evidencia.\n\n### 2.2 Lei 14.063/2020: simples, avancada e qualificada\n\nA Lei n 14.063/2020 classifica assinaturas eletronicas em:\n\n- **Simples**\n- **Avancada**\n- **Qualificada** (a que usa certificado digital ICP-Brasil)\n\nEla foca principalmente interacoes com o poder publico e alguns atos especificos, mas acabou virando a \"linguagem comum\" do mercado para discutir niveis de assinatura.\n\n### 2.3 Codigo Civil (regra geral): forma livre, salvo excecoes\n\nEm regra, **a validade da declaracao de vontade nao depende de forma especial**, salvo quando a lei exigir. Isso e usado como base para contratos e aceites eletronicos em geral.\n\nO detalhe esta nas excecoes: para alguns atos (ex.: certos negocios com imoveis, exigencias legais especificas, regras setoriais), a forma pode ser mais rigida.\n\n### 2.4 CPC (processo civil): autenticidade e prova documental\n\nNo contencioso, o que interessa e: **voce consegue demonstrar autenticidade/autoria e integridade?** \nO CPC trata de autenticidade de documentos e admite meios de certificacao, inclusive eletronicos, alem de regras sobre documentos eletronicos produzidos e conservados conforme legislacao especifica.\n\n---\n\n## 3. Como escolher o tipo de assinatura: pare de discutir \"gosto\" e discuta risco\n\nA pergunta correta nao e \"qual e melhor?\", e sim:\n\n1. Qual o risco de disputa (fraude/repudio)?\n2. Qual o valor do negocio (financeiro e reputacional)?\n3. Qual o impacto se o contrato cair?\n4. Qual o atrito aceitavel no onboarding?\n\nAbaixo, um mapa pratico.\n\n![Matriz pratica risco juridico atrito](/assets/img/matriz-risco-assinatura.png \"Matriz pratica: risco juridico atrito (para escolher o nivel de assinatura)\")\n\n### 3.1 Classificacao resumida (para alinhar juridico + produto + engenharia)\n\n![Classificacao das assinaturas eletronicas](/assets/img/classificacao-assinaturas-eletronicas.png \"Classificacao das assinaturas eletronicas no Brasil (Lei 14.063/2020)\")\n\n### 3.2 Tabela de decisao por cenario (exemplos tipicos)\n\n| Cenario | Risco de disputa | Recomendacao comum | Evidencia minima esperada |\n|---|---:|---|---|\n| Termos de uso / aceite de politica | Baixo a medio | Simples ou avancada | Registro do aceite, versao do texto, IP/device, timestamp, conta autenticada |\n| Contrato B2B recorrente (SaaS) | Medio | Avancada (ou qualificada em casos sensiveis) | Identificacao robusta, logs, hash do documento, trilha auditavel, pacote de evidencias |\n| Contrato com alto valor / alta litigiosidade | Alto | Qualificada (ICP-Brasil) | Certificado ICP-Brasil, carimbo do tempo, validacao e retencao (LTV quando aplicavel) |\n| Interacao com governo (quando exigido) | Variavel | Conforme orgao/lei | Seguir exigencia do ente; qualificada quando obrigatoria |\n| Negocios com imoveis / hipoteses legais especificas | Alto | Qualificada (quando exigida) | Atender forma legal (e registrar evidencias do ato e do documento final) |\n\nA tabela acima e \"norte de produto\". O desenho final depende do seu setor, perfil de fraude e apetite de risco.\n\n---\n\n## 4. Trilha de auditoria: o que separa um contrato \"assinado\" de um contrato \"provavel\"\n\nQuando alguem contesta um contrato, normalmente nao e \"briga sobre criptografia\". \nE briga sobre quatro coisas:\n\n1. **Identidade**: quem assinou?\n2. **Vontade**: a pessoa realmente concordou?\n3. **Integridade**: o documento e exatamente o que foi assinado?\n4. **Data e contexto**: quando/onde/como ocorreu?\n\nUma trilha de auditoria boa transforma isso em evidencia objetiva.\n\n### 4.1 O que eu considero um \"pacote de evidencias\" completo\n\nSe voce precisa se preparar para disputa, pense em produzir e armazenar um pacote com:\n\n- Documento final (PDF) com identificador unico (ex.: `doc_id`).\n- Hash do documento (SHA-256, por exemplo) do arquivo final.\n- Metadados de versao (qual template + qual versao do texto/clausulas).\n- Eventos de assinatura (timeline):\n - convite enviado,\n - visualizacao do documento,\n - autenticacao do signatario,\n - aceite,\n - assinatura finalizada,\n - eventual rejeicao ou expiracao.\n- Evidencias tecnicas (conforme LGPD e minimizacao):\n - IP, user-agent, device fingerprint **com parcimonia**,\n - geolocalizacao **se houver base e necessidade**,\n - evidencia de fator de autenticacao (OTP enviado/validado, banco verificado etc.),\n - biometria (em geral, use provedores que tratem isso com seguranca e documentacao; evite \"salvar selfie\" sem governanca).\n- Quando aplicavel: **carimbo do tempo (timestamp)** e dados de validacao (cadeia do certificado, OCSP/CRL, etc.).\n\n> Se voce nao consegue explicar \"como\" prova cada um dos 4 pilares (identidade/vontade/integridade/data), voce tem risco.\n\n### 4.2 Como gerar e validar hash (exemplo simples)\n\nVoce nao precisa \"inventar\" seguranca: hash e um tijolo basico.\n\n```bash\n# Gera hash SHA-256 do PDF final (para provar integridade)\nshasum -a 256 contrato-final.pdf\n```\n\nBoa pratica: salve esse hash junto com o `doc_id` e a versao do documento, e registre em log imutavel (WORM) quando possivel.\n\n### 4.3 Carimbo do tempo (timestamp) e \"data certa\"\n\nO carimbo do tempo associa um **hash** a uma data/hora emitida por uma terceira parte confiavel (Autoridade Certificadora do Tempo). \nEle nao \"prova criacao do documento\", mas prova que **aquele hash existia** naquela data/hora.\n\nIsso e util para:\n- reforcar \"data certa\" em disputas,\n- suportar validacao de longo prazo quando certificados expiram.\n\n---\n\n## 5. Implementacao em produto: arquitetura e decisoes de engenharia que importam\n\nA pior arquitetura e tratar assinatura como \"upload/download de PDF\" sem estado, sem logs e sem versionamento.\n\nA melhor arquitetura trata assinatura como um **fluxo transacional**:\n\n- com idempotencia,\n- com estado,\n- com logs completos,\n- com evidencia exportavel.\n\n![Arquitetura recomendada para assinatura e trilha de auditoria](/assets/img/arquitetura-assinatura-trilha-auditoria.png \"Arquitetura: assinatura + pacote de evidencias + armazenamento + verificacao\")\n\n### 5.1 Construir vs integrar provedor: um criterio honesto\n\nEm 90% dos casos, integrar um provedor faz mais sentido do que construir tudo do zero, porque:\n\n- identidade e antifraude sao dificeis,\n- padroes de assinatura (PDF, certificados, LTV) sao cheios de detalhes,\n- operacao e auditoria sao trabalhosas.\n\nConsidere \"construir\" quando:\n- voce tem requisitos muito especificos (setoriais, soberania, offline, integracoes profundas),\n- ou quando assinatura e parte central do core do produto.\n\nO criterio pratico e: **se uma falha aqui vira risco juridico material, nao trate como feature periferica.**\n\n### 5.2 Checklist tecnico de robustez (para evitar disputa)\n\n- [ ] O documento tem **ID unico** e **versao** clara?\n- [ ] A assinatura e aplicada **sobre o arquivo final** (sem \"trocar PDF\" depois)?\n- [ ] Existe **hash do documento final** armazenado com logs?\n- [ ] A trilha registra **eventos e timestamps** com fuso correto?\n- [ ] Da para exportar um **pacote de evidencias** (PDF + JSON/CSV do log)?\n- [ ] Existe verificacao automatica de integridade (e alerta de divergencia)?\n- [ ] A retencao esta definida (prazo, base legal, minimizacao)?\n- [ ] Existe politica de acesso (RBAC), criptografia e auditoria?\n\n---\n\n## 6. LGPD e governanca: \"assinatura\" e dado pessoal (e, as vezes, dado sensivel)\n\nContratos e trilhas de auditoria frequentemente carregam:\n\n- nome, CPF, e-mail, telefone,\n- endereco,\n- dados de autenticacao,\n- as vezes biometria (sensivel).\n\nO basico do basico:\n\n- Minimize dados no pacote de evidencias (guarde o necessario para provar).\n- Defina base legal e retencao.\n- Controle acesso e registre auditoria (quem viu, quem baixou, quem exportou).\n- Se usar fornecedor, trate como relacao controlador/operador e ajuste contratos, DPA e seguranca.\n\n---\n\n## 7. Erros comuns que viram dor juridica (e sao evitaveis)\n\n1. **Documento sem versionamento** \n\"Assinou qual versao?\" e uma pergunta mortal em disputa.\n\n2. **Trocar o PDF depois da assinatura** \nMesmo com boa intencao (corrigir formatacao), isso destroi integridade.\n\n3. **Assinatura \"simples\" para caso de alto risco** \nA escolha errada nao e \"ilegal\", mas pode ser **insustentavel** quando contestada.\n\n4. **Provar identidade so com uma selfie isolada** \nBiometria e poderosa, mas precisa de contexto, governanca e trilha completa.\n\n5. **Logs sem timestamp confiavel e sem fuso** \nDisputa adora detalhes - e isso vira brecha.\n\n---\n\n## 8. Fechando: assinatura boa e a que aguenta a pior semana do contencioso\n\nSe voce quer reduzir atrito, acelerar fechamento e ainda dormir tranquilo, a pergunta final e:\n\n> \"Se amanha alguem negar o contrato, eu consigo provar o que - e em quanto tempo?\"\n\nSe a resposta for \"vai dar trabalho\", voce precisa melhorar o fluxo.\n\nSe voce quer ajuda para desenhar isso de ponta a ponta (produto + engenharia + governanca + juridico), veja a nossa pagina de servicos:\n\n- [Ver servicos](/servicos)\n\n---\n\n## Referencias (fontes oficiais e uteis)\n\n- MP 2.200-2/2001 (ICP-Brasil) - art. 10, 1 e 2: https://www.planalto.gov.br/ccivil_03/MPV/Antigas_2001/2200-2.htm \n- Lei 14.063/2020 (classificacao: simples/avancada/qualificada): https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2020/Lei/L14063.htm \n- ITI (perguntas frequentes - certificacao digital e validade juridica): https://www.gov.br/iti/pt-br/acesso-a-informacao/perguntas-frequentes/certificacao-digital \n- ITI (carimbo do tempo / timestamp): https://www.gov.br/iti/pt-br/acesso-a-informacao/perguntas-frequentes/carimbo-do-tempo \n- Governo Digital (visao geral de assinatura eletronica e GOV.BR): https://www.gov.br/governodigital/pt-br/identidade/assinatura-eletronica/saiba-mais-sobre-a-assinatura-eletronica \n- Lei 11.419/2006 (processo judicial eletronico e conceito de assinatura eletronica): https://www.planalto.gov.br/ccivil_03/_ato2004-2006/2006/lei/l11419.htm \n- CPC (Lei 13.105/2015) - prova documental e certificacao eletronica: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2015/Lei/L13105.htm \n- Codigo Civil (Lei 10.406/2002) - art. 107 (forma livre, salvo exigencia legal): https://www2.camara.leg.br/legin/fed/lei/2002/lei-10406-10-janeiro-2002-432893-normaatualizada-pl.html\n"},"733e6e03-9dd6-53d2-9b1a-fe3258dddce6":{"id":"733e6e03-9dd6-53d2-9b1a-fe3258dddce6","title":"How to approve screens and flows quickly (without infinite feedback loops)","content":"\n> \"Fast approval is not rushed approval. It means a clear standard for what is truly ready.\"\n\nIn almost every software project, there is a moment when your **approval** is needed so the team can move forward with confidence: final UI decisions, flow validation, and release readiness.\n\nThe problem begins when approval becomes an endless loop: scattered comments, conflicting requests, and late scope changes.\n\nThis post gives a practical framework for **business and client stakeholders** to approve screens and flows objectively, without bureaucracy and without losing quality.\n\n![Cover image: screen and flow approval](/assets/img/aprovacao-telas-fluxos-capa.png \"How to approve screens and flows quickly without endless feedback cycles.\")\n\n## What you'll find here\n\n- A simple approval process (short and controlled rounds)\n- A **per-screen checklist** template\n- A **per-flow checklist** for quick UAT\n- Good vs bad feedback examples\n- A method to centralize comments and avoid duplicate requests\n- A clear way to define and record **\"OK to publish\"**\n\n## Why approvals become \"infinite feedback\"\n\nMost cases happen for four reasons:\n\n1. **No clear criteria**: no one knows exactly what \"approved\" means.\n2. **Scattered feedback**: WhatsApp, email, calls, meetings, and random docs.\n3. **No final owner**: everyone comments, no one decides.\n4. **Scope changes during validation**: new ideas become mandatory at the last minute.\n\nThe solution is simple: one process, one source of truth, clear checklists, and explicit close-out.\n\n## Practical method (5 steps)\n\n![Simple approval process](/assets/img/aprovacao-telas-fluxos-01-processo.png \"Prepare round, review screens, review flow (UAT), consolidate feedback, record OK to publish.\")\n\n### Step 1 - Prepare the review round (5 minutes that save days)\n\nBefore reviewing details, align these six points:\n\n1. What exactly is in scope for this round (batch scope).\n2. Which version/link is the source of truth.\n3. Who has the final approval decision.\n4. Feedback deadline.\n5. Rule for scope changes (fixes vs new ideas).\n6. Where all decisions and pending items will be recorded.\n\n### Step 2 - Validate each screen with a checklist\n\nThe checklist moves the conversation from personal preference to product quality.\n\n![Per-screen checklist](/assets/img/aprovacao-telas-fluxos-02-checklist-por-tela.png \"Quick checklist to validate each screen with objectivity.\")\n\n#### Per-screen checklist (copy and paste)\n\nBasics\n- [ ] What is the goal of this screen? (1 sentence)\n- [ ] Text is reviewed (headings, buttons, messages)\n- [ ] Layout is consistent with the rest of the app\n\nBehavior\n- [ ] Fields and validations make sense (required/optional, format, masks)\n- [ ] States are covered: loading, empty, error, success\n- [ ] Buttons and links navigate to the expected destination\n\nQuality\n- [ ] Error messages tell users what to do next\n- [ ] Sensitive data handling is clear (for example ID, email, password, amounts)\n- [ ] Minimum accessibility is respected (font size, contrast, focus, readability)\n\nFinalization\n- [ ] Screen approved (or pending items documented with priority)\n\n### Step 3 - Validate the complete flow (quick UAT)\n\nDo not approve isolated screens only. Validate the full user journey from entry point to expected result.\n\nUAT (User Acceptance Testing) is exactly that: business/user validation before production.\n\n#### Per-flow checklist (copy and paste)\n\n- [ ] Flow entry point is clear\n- [ ] Happy path works end to end\n- [ ] Common error paths are handled properly\n- [ ] Back navigation behaves correctly\n- [ ] Session/persistence behavior is acceptable\n- [ ] System messages are understandable\n- [ ] Final success condition is explicit\n\nTip: test at least once on a real phone to evaluate readability, interaction, and perceived speed.\n\n### Step 4 - Give actionable feedback (not abstract opinions)\n\nThe best format is:\n\n**Context + problem + expected behavior + evidence + priority**\n\n#### Examples (bad vs good)\n\n![Good vs bad feedback](/assets/img/aprovacao-telas-fluxos-03-feedback-bom-vs-ruim.png \"Examples of non-actionable feedback vs actionable feedback.\")\n\nBad feedback (not actionable)\n- \"This looks weird.\"\n- \"I don't like it.\"\n- \"Make it better.\"\n- \"Make it more modern.\"\n\nGood feedback (actionable)\n- \"Screen: Login. Problem: Enter button stays disabled with valid inputs. Expected: enable when email and password are valid. Evidence: screenshot. Priority: High (blocks access).\"\n- \"Flow: Checkout. Problem: cart is lost when returning from payment. Expected: preserve cart and show status. Evidence: steps to reproduce. Priority: High.\"\n- \"Screen: Signup. Suggestion: replace 'Confirm' with 'Create account' for clarity. Priority: Medium.\"\n\n#### Feedback template (copy and paste)\n\n- **Screen/Flow:**\n- **Context:**\n- **Problem:**\n- **Expected:**\n- **Evidence:**\n- **Priority:** High / Medium / Low\n\n### Step 5 - Centralize comments and close the round\n\nThis is what reduces rework the most: **one official place for feedback**.\n\nRules:\n\n1. Use one primary channel (for example Figma comments).\n2. Convert each comment into a clear pending item.\n3. Resolve items one by one with status updates.\n4. Close the round with an explicit \"OK to publish\" note.\n\n## How to define \"OK to publish\"\n\n\"OK to publish\" should be pass/fail and objective. It does not mean perfect; it means safe and ready for release.\n\n![OK to publish criteria](/assets/img/aprovacao-telas-fluxos-04-ok-para-publicar.png \"Objective publication readiness checklist.\")\n\n### A simple \"OK to publish\" standard\n\nConsider release-ready when:\n\n- Per-screen checklist is complete for all scoped screens\n- Core flows were tested (happy path + common errors)\n- Acceptance criteria were met\n- No critical/blocking bugs remain\n- Final copy/text is approved\n- Approval is recorded with approver name, date, and version\n\n### Approval message example (copy and paste)\n\n\"OK to publish - Version X (UAT completed). \nApproved by: Name Surname - Role - DD/MM/YYYY.\"\n\n## How to avoid \"infinite scope\" while still improving\n\nClassify feedback into three buckets:\n\n1. **Fixes** (bugs, broken flow, incorrect business rule) -> must be done before approval.\n2. **Nice-to-have improvements** (usability polish, visual refinements, microcopy) -> include if time allows.\n3. **New ideas/features** -> backlog; should not block release.\n\nThis protects delivery dates without ignoring product evolution.\n\n## 30-45 minute approval script\n\n1. 5 min - Reconfirm objective and round scope.\n2. 15-20 min - Review screens with checklist.\n3. 10-15 min - Validate one or two end-to-end flows.\n4. 5 min - Prioritize pending items (High/Medium/Low).\n5. 2 min - Decide \"OK to publish\" or keep round open with explicit pending items.\n\n## Final checklist\n\nBefore ending a round, confirm:\n\n- [ ] One clear final approver is defined\n- [ ] Feedback is centralized in one channel\n- [ ] Pending items include context and priority\n- [ ] Scope and version link are explicit\n- [ ] \"OK to publish\" is recorded (name + date)\n\nWhen you apply this method consistently, approvals stop being a bottleneck and become a predictable product governance step.\n"},"50891967-e7ad-53c0-9013-0a521cd81481":{"id":"50891967-e7ad-53c0-9013-0a521cd81481","title":"Apontamento de DNS (Registro A): como criar uma URL HTTPS para sua API e publicar seu app sem dor de cabeca","content":"\n> \"Se voce tem apenas o IP do servidor, falta a parte mais importante para um app em producao: uma URL estavel e segura (HTTPS).\"\n\nQuando um time de desenvolvimento entrega uma API ou um portal (admin/web), e comum o cliente receber apenas um **IP do servidor**. Isso funciona para testes rapidos, mas vira um problema no momento de publicar e manter um aplicativo nas lojas.\n\nNa pratica, apps iOS/Android e aplicacoes web modernas precisam conversar com a API via **HTTPS** (conexao segura). E para ter HTTPS \"do jeito certo\", voce precisa de um **dominio** (ou subdominio), nao so um IP.\n\nNeste artigo, voce vai aprender como fazer o apontamento de DNS **do tipo A** (o mais comum quando voce recebe um IPv4) e como organizar isso de forma simples - incluindo um passo a passo nos provedores de DNS mais usados.\n\n![Interface digital com globo, nuvem e cursor representando acesso seguro via internet](/assets/img/apontamento-dns-registro-a-https.jpg \"Apontamento de DNS (Registro A): do IP para uma URL com HTTPS.\")\n\n## O que voce vai ver aqui:\n\n* Por que **nao** usar IP direto na API do app\n* O que e DNS e o que e um **Registro A**\n* Como escolher o **subdominio** ideal (sem comprar outro dominio)\n* Passo a passo padrao (vale para qualquer provedor)\n* Passo a passo por provedor: Registro.br, GoDaddy, Cloudflare, AWS, Google, Microsoft e outros\n* O que e \"propagacao de DNS\" (sem complicacao)\n* Usar o dominio que voce ja tem vs. comprar outro: pros e contras\n* Checklist final (para voce nao esquecer nada)\n\n## Por que nao usar so o IP do servidor\n\nAbaixo estao os motivos mais comuns - e os que mais geram retrabalho quando o assunto e publicar app:\n\n![IP direto vs dominio](/assets/img/dns-apontamento-01-ip-vs-dominio.png \"Comparacao simples: IP direto vs dominio/subdominio.\")\n\n1. HTTPS fica dificil (ou inviavel) \"do jeito correto\" \nPara um app usar HTTPS, o servidor precisa apresentar um certificado valido para o endereco acessado (a URL). Certificados para IP sao incomuns e, na pratica, a maioria das solucoes modernas assume um nome (dominio/subdominio).\n\n2. IP muda com troca de ambiente e isso quebra o app \nTrocar de servidor, migrar de provedor, mudar de infraestrutura, subir um novo balanceador tudo isso pode mudar o IP. Se o app esta \"amarrado\" no IP, voce precisa publicar uma atualizacao so para trocar a URL.\n\n3. Um dominio te da estabilidade e organizacao \nCom dominio, voce cria uma estrutura limpa, por exemplo:\n\n* `api.seudominio.com` API do aplicativo \n* `admin.seudominio.com` portal administrativo \n* `www.seudominio.com` site institucional \n* `homolog-api.seudominio.com` ambiente de homologacao (se existir)\n\n4. Seguranca e boas praticas \nMesmo que tecnicamente de para \"forcar\" excecoes, o caminho recomendado e **HTTPS** com certificado valido.\n\n![Por que HTTPS](/assets/img/dns-apontamento-04-por-que-https.png \"Apps e plataformas modernas favorecem HTTPS como padrao.\")\n\n## Conceito rapido: o que e DNS e o que e um Registro A\n\nDNS e como uma \"agenda\" da internet: ele transforma um nome facil (ex.: `api.seudominio.com`) em um endereco de verdade (um IP).\n\nUm **Registro A** e o tipo de registro DNS que aponta um nome para um **IPv4** (o IP tradicional com quatro blocos, como `203.0.113.10`).\n\nSe o seu provedor falar em IPv6 (menos comum nesse cenario), o registro equivalente costuma ser o **AAAA**.\n\n## Checklist antes de comecar (para evitar erro)\n\nAntes de mexer em DNS, confirme:\n\n1. Qual e o dominio que voce vai usar \nEx.: `seudominio.com` (normalmente a empresa ja tem um).\n\n2. Qual subdominio voce quer criar \nEx.: `api` (vai virar `api.seudominio.com`).\n\n3. Voce recebeu um IP IPv4 correto do time tecnico \nEx.: `203.0.113.10` (o desenvolvedor normalmente te passa).\n\n4. Onde o DNS do seu dominio esta sendo gerenciado \nIsso e muito importante: as vezes o dominio foi comprado no Registro.br, mas o DNS esta no Cloudflare; ou foi comprado na GoDaddy, mas o DNS esta na AWS.\n\nDica: se voce nao sabe, pergunte internamente \"quem administra o DNS do dominio?\" ou peca ajuda para quem cuida do site/e-mail.\n\n5. Voce entende o impacto \nAdicionar um registro A para um **subdominio novo** (ex.: `api`) normalmente nao afeta o site nem o e-mail. \nO risco maior e quando alguem altera registros existentes (MX, TXT, @, www) sem querer.\n\n\n6. Porta e HTTPS (para apps em producao)\nUm detalhe que confunde bastante: **registro A nao configura porta**. Ele so liga nome IP.\n\nO que isso significa?\n\n* O endereco final do app deve ser algo como `https://api.seudominio.com` (porta 443, padrao do HTTPS).\n* Se o servidor estiver usando uma porta diferente, isso precisa ser configurado no servidor/balanceador - e normalmente nao e recomendado para apps em producao.\n\n\n## Passo a passo padrao (vale para qualquer provedor)\n\nA maioria dos paineis e diferente, mas os campos sao praticamente os mesmos.\n\n1. Entre no painel de DNS do seu dominio \nProcure por algo como: \"DNS\", \"Zona DNS\", \"Gerenciar DNS\" ou \"DNS Records\".\n\n2. Clique para adicionar um novo registro \nNormalmente aparece como \"Adicionar\", \"Novo registro\" ou \"Add record\".\n\n3. Selecione o tipo **A** \nTipo: **A** (IPv4)\n\n4. Preencha os campos \nUse o padrao abaixo:\n\n* Nome/Host: `api` \n* Aponta para/Valor: `SEU_IP_AQUI` \n* TTL: 300 (5 min) ou 3600 (1h)\n\n![Exemplo de Registro A](/assets/img/dns-apontamento-02-registro-a-exemplo.png \"Exemplo de preenchimento de um Registro A.\")\n\n5. Salve \nAlguns provedores pedem confirmacao.\n\n6. Aguarde a propagacao \nMesmo depois de salvar, pode levar um tempo para \"espalhar\" a atualizacao.\n\n7. Depois disso, configure o HTTPS no servidor (ou com seu time tecnico) \nDNS sozinho nao cria HTTPS. Ele so aponta o nome para o servidor. \nO HTTPS vem do certificado instalado/configurado no servidor (ou no balanceador/reverso).\n\n\n## Se o desenvolvedor nao te passou um IP (e sim um \"endereco\")\n\nAs vezes, o time tecnico nao te passa um IP e sim um endereco parecido com:\n\n* `meu-balanceador.alguma-coisa.cloud` \n* `minha-distribuicao.alguma-coisa.cdn`\n\nNesse caso, normalmente o apontamento correto NAO e um Registro A, e sim:\n\n* **CNAME** (aponta um nome para outro nome), ou \n* **ALIAS/ANAME** (alguns provedores oferecem \"A para nome\", parecido com CNAME, mas compativel com mais cenarios).\n\nSe voce recebeu um \"nome\" e nao um IP, peca ao time tecnico: \n\"E para apontar por CNAME/ALIAS? Qual e o valor exato?\"\n\n(Se voce tentar forcar um Registro A sem ter um IP fixo, a chance de dar problema depois e alta.)\n\n\n## Propagacao de DNS (sem ser tecnico)\n\n\"Propagacao\" e o tempo para a internet inteira enxergar a sua alteracao.\n\nO principal fator e o TTL (tempo que alguns servidores guardam a informacao em cache). Em geral, alteracoes de DNS podem aparecer em minutos, mas e normal levar algum tempo para estabilizar.\n\n![Propagacao de DNS](/assets/img/dns-apontamento-03-propagacao.png \"Entenda propagacao de DNS como cache (agenda antiga vs agenda atualizada).\")\n\nSe voce alterou apenas um registro A de um subdominio, a chance de impacto e baixa. \nSe voce trocou **servidores DNS** (nameservers), o tempo costuma ser maior.\n\n\n## E se o IP mudar no futuro?\n\nIsso acontece bastante quando a empresa troca de servidor, muda de provedor ou recria ambientes.\n\nComo reduzir dor de cabeca:\n\n* Peca um **IP fixo** (ou \"reservado\") para producao, quando possivel.\n* Use um subdominio especifico para cada ambiente (ex.: `homolog-api.seudominio.com`).\n* Se voce sabe que vai trocar o IP em uma data especifica, reduza o TTL com antecedencia (por exemplo, para 300) para a mudanca \"pegar\" mais rapido.\n* Documente internamente quem e responsavel por DNS e por renovacao do dominio.\n\nO ponto principal e simples: o app deve \"conhecer\" uma URL estavel, e a infraestrutura por tras pode mudar sem obrigar voce a publicar uma nova versao do app.\n\n\n## Passo a passo por provedor\n\nA seguir, um passo a passo \"traduzido\" para os paineis mais comuns. A ideia e que voce consiga fazer sozinho, ou orientar alguem do seu time.\n\n### 1) Registro.br (quando o DNS esta no Registro.br)\n\nUse este caminho quando o seu dominio esta com os servidores DNS do proprio Registro.br.\n\n1. Acesse sua conta e selecione o dominio.\n2. Role ate a secao de DNS e procure por \"Configurar zona DNS\".\n3. Clique em \"Nova entrada\" (ou opcao equivalente).\n4. Preencha:\n * Tipo: A\n * Nome: `api`\n * Valor: `SEU_IP_AQUI`\n * TTL: 300 ou 3600\n5. Salve.\n\nObservacao importante: se o seu dominio usa DNS de outro provedor (ex.: Cloudflare), voce nao vai encontrar a zona para editar no Registro.br - nesse caso, edite onde o DNS realmente esta.\n\n### 2) GoDaddy\n\n1. Entre na sua conta e abra o dominio.\n2. Va em \"DNS\" (ou \"Manage DNS\").\n3. Clique em adicionar um novo registro.\n4. Tipo: A\n5. Host: `api`\n6. Aponta para: `SEU_IP_AQUI`\n7. Salve.\n\n### 3) Cloudflare\n\n1. Entre no painel do Cloudflare e selecione o seu dominio (site).\n2. Va em \"DNS\" \"Records\".\n3. Clique em \"Add record\".\n4. Tipo: A\n5. Nome: `api`\n6. IPv4: `SEU_IP_AQUI`\n7. Salve.\n\nDica para leigos: se aparecer um botao de \"proxy\" (nuvem), e voce nao sabe o que e, use \"DNS only\" e deixe o time tecnico configurar o HTTPS no servidor. Se voce usar proxy, combine antes com o desenvolvedor porque muda o caminho do trafego.\n\n### 4) Amazon AWS (Route 53)\n\n1. Acesse o servico Route 53.\n2. Abra \"Hosted zones\" e selecione a zona do seu dominio.\n3. Clique em \"Create record\".\n4. Nome do registro: `api`\n5. Tipo: A\n6. Valor: `SEU_IP_AQUI`\n7. Salve.\n\nObservacao: se sua infraestrutura usa balanceador (ALB/ELB) ou CDN, pode ser que o correto seja Alias/CNAME. Se voce recebeu apenas \"um IP\", normalmente e porque o time tecnico te passou um IP fixo.\n\n### 5) Google (Google Cloud DNS)\n\n1. Acesse o console do Google Cloud e abra o Cloud DNS.\n2. Selecione a zona (managed zone) do dominio.\n3. Adicione um novo conjunto de registros (record set).\n4. Tipo: A\n5. Nome: `api` (ou `api.seudominio.com`, dependendo do campo)\n6. Valor: `SEU_IP_AQUI`\n7. Salve.\n\n### 6) Microsoft (Azure DNS)\n\n1. Acesse o portal do Azure e abra \"DNS zones\".\n2. Selecione a zona do seu dominio.\n3. Va em \"Record sets\" e clique em \"Add\".\n4. Nome: `api`\n5. Tipo: A\n6. IP: `SEU_IP_AQUI`\n7. Salve.\n\n### 7) Namecheap (extra)\n\n1. Domain List Manage.\n2. Aba \"Advanced DNS\".\n3. \"Host Records\" \"Add New Record\".\n4. Tipo: A\n5. Host: `api`\n6. Value: `SEU_IP_AQUI`\n7. Salve.\n\n### 8) Hostinger (extra)\n\n1. Acesse o painel (hPanel).\n2. Abra o dominio e procure por \"DNS Zone Editor\".\n3. Adicione um registro do tipo A.\n4. Nome: `api`\n5. Aponta para: `SEU_IP_AQUI`\n6. Salve.\n\n### Outros provedores comuns (a logica e a mesma)\n\nMesmo que voce use outro provedor (UOL, Locaweb, HostGator, etc.), procure por:\n\n- DNS / Zona DNS / DNS Records \n- Adicionar registro (A) \n- Nome/Host + IP/Valor + TTL\n\n## Usar o dominio que voce ja tem ou comprar outro?\n\nNa maioria dos casos, voce NAO precisa comprar um novo dominio. Um subdominio resolve.\n\nExemplo: se a empresa ja tem `seudominio.com`, voce cria:\n\n- `api.seudominio.com` \n- `admin.seudominio.com`\n\n### Vantagens de usar o dominio que voce ja possui\n\n* Custo zero adicional (sem nova assinatura/renovacao)\n* Menos coisa para administrar\n* Mantem padrao e credibilidade do dominio oficial da empresa\n\n### Desvantagens (e como evitar)\n\n* Se alguem fizer alteracoes erradas na zona DNS, pode afetar outras coisas (site/e-mail). \n Solucao: mexer apenas no subdominio novo e nao apagar registros existentes.\n\n* Dependencia de outro time/fornecedor (marketing/agencia) para liberar o acesso. \n Solucao: definir um responsavel por DNS e um processo simples de aprovacao.\n\n### Quando faz sentido comprar um dominio separado\n\n* Separar completamente ambientes/servicos (ex.: dominio so para apps)\n* Evitar qualquer risco no dominio principal\n* Ter um dominio tecnico que pode ser administrado pelo time de TI/DevOps\n\nSe optar por outro dominio, o cuidado n 1 e simples: **nao deixar vencer**. \nSe o dominio expirar, o app pode ficar sem comunicacao com o backend e voce pode perder controle desse endereco.\n\n## O que voce deve pedir do seu time tecnico (ou do desenvolvedor)\n\nPara voce apontar o DNS corretamente, normalmente voce precisa receber:\n\n- O IP do servidor (IPv4) que ficara \"fixo\" para producao, quando possivel \n- Qual subdominio usar (ex.: `api`) \n- Um endpoint de teste (ex.: `/health`), para validar depois \n- Confirmacao de que o HTTPS sera configurado assim que o DNS estiver apontado\n\n## Checklist final (copia e cola)\n\nAntes de avisar \"esta pronto\", confirme:\n\n- [ ] O subdominio escolhido (ex.: `api.seudominio.com`) esta correto \n- [ ] O Registro A foi criado com o IP certo \n- [ ] Voce nao alterou registros antigos (especialmente e-mail) sem intencao \n- [ ] Voce aguardou um tempo de propagacao \n- [ ] O time tecnico instalou/configurou certificado HTTPS para o subdominio \n- [ ] Voce testou a URL final em HTTPS\n\nSe voce fizer apenas isso, voce elimina 90% dos problemas comuns de \"API por IP\" e garante que seu app e seus portais tenham uma URL estavel e segura.\n"},"86073082-f14f-52fb-87ac-c9c19c42ae8e":{"id":"86073082-f14f-52fb-87ac-c9c19c42ae8e","title":"Cache no CI/CD: como desenhar keys e evitar cache invalido (GitHub e GitLab)","content":"\nCache e uma das maiores alavancas de performance em CI/CD. Tambem e uma das maiores fontes de bugs intermitentes.\n\nO objetivo deste post e pratico: ensinar a desenhar cache keys que aceleram o pipeline sem deixar voce com builds \"assombrados\".\n\nEste post faz parte da serie:\n\n- [Guia de CI/CD no Git para times pequenos: performance, cache e runners](/guia-cicd-times-pequenos-performance-cache-runners)\n\n## Mapa da serie CI/CD\n\n- [Guia de CI/CD no Git para times pequenos: performance, cache e runners](/guia-cicd-times-pequenos-performance-cache-runners)\n- [GitLab CI: tags de runner e roteamento de jobs](/gitlab-ci-tags-de-runner)\n- [Cache no CI/CD: como desenhar keys e evitar cache invalido (GitHub e GitLab)](/cache-ci-cd-keys-invalidation-github-gitlab)\n- [Docker layer caching no CI: BuildKit, buildx, cache-from e cache-to](/docker-layer-caching-ci-buildkit-buildx)\n- [Runner dedicado no CI/CD: quando vale a pena e como planejar em time pequeno](/runner-dedicado-ci-cd-time-pequeno)\n- [Runners macOS no CI: Intel vs Apple Silicon, custos e armadilhas](/runner-macos-ci-intel-apple-silicon)\n\n## Cache vs artifacts: comece separando o que e o que\n\nRegra de bolso:\n\n- Cache = reutilizar diretorios reconstruiveis (dependencias, downloads).\n- Artifacts = transportar resultado do build entre jobs (dist, binario, relatorio).\n\nQuando voce usa cache para transportar output de build, voce aumenta o risco de:\n\n- um job consumir um output \"antigo\"\n- resultados inconsistentes por branch/arquitetura\n\n## 1) Como desenhar cache keys (o que entra e o que nao entra)\n\nUm cache key bom costuma ter:\n\n- Sistema operacional\n- Arquitetura (ARM64/x64)\n- Hash do lockfile\n- Versao do runtime (quando necessario)\n\nUm cache key ruim costuma ter:\n\n- SHA do commit (invalida a cada commit)\n- timestamp\n- nome de branch sem normalizacao (explode numero de caches)\n\n### 1.1 Exemplo (GitHub Actions)\n\n```yaml\n- name: Cache npm\n uses: actions/cache@v4\n with:\n path: ~/.npm\n key: ${{ runner.os }}-${{ runner.arch }}-npm-${{ hashFiles('**/package-lock.json') }}\n restore-keys: |\n ${{ runner.os }}-${{ runner.arch }}-npm-\n```\n\nPor que isso funciona:\n\n- O hash do lockfile so muda quando dependencia muda.\n- O prefixo em `restore-keys` permite reaproveitar cache \"proximo\" quando o exato nao existe.\n- `runner.arch` evita misturar ARM64 e x64.\n\n### 1.2 Exemplo (GitLab CI/CD)\n\n```yaml\ncache:\n key: \"node-${CI_RUNNER_EXECUTABLE_ARCH}-${CI_COMMIT_REF_SLUG}-${CI_PROJECT_NAME}\"\n paths:\n - .npm/\n fallback_keys:\n - \"node-${CI_RUNNER_EXECUTABLE_ARCH}-main-${CI_PROJECT_NAME}\"\n - \"node-${CI_RUNNER_EXECUTABLE_ARCH}-default-${CI_PROJECT_NAME}\"\n```\n\nPor que isso funciona:\n\n- Separa por arquitetura.\n- Permite fallback da branch principal para branches novas.\n- Evita cache \"cross-project\" (quando voce tem multiplos projetos e runners compartilhados).\n\n## 2) Onde cachear (Node, Python, Java, Ruby)\n\nRegra geral: cacheie o \"cache do gerenciador\", nao necessariamente a pasta final.\n\n- Node (npm): `~/.npm`\n- Node (pnpm): `~/.pnpm-store`\n- Python (pip): `~/.cache/pip`\n- Java/Gradle: `~/.gradle/caches`\n- Ruby/bundler: `vendor/bundle` (com criterio)\n\nO que evitar como primeiro passo:\n\n- cachear `node_modules` indiscriminadamente (pode ser enorme e instavel)\n- cachear outputs de build (isso e artifact)\n\n## 3) Invalidacao: o que muda cache (e como evitar \"cache inutil\")\n\nTres causas classicas de cache \"sempre miss\":\n\n1. O key muda a cada commit (ex.: inclui SHA).\n2. O lockfile nao esta sendo incluido no hash (cache fica stale e pode quebrar).\n3. Voce esta cacheando um diretorio que muda por execucao.\n\nChecklist para corrigir:\n\n- [ ] lockfile faz parte do key (`hashFiles(...)` ou equivalente).\n- [ ] arquitetura faz parte do key.\n- [ ] os paths de cache realmente existem (nao inventar diretorio).\n- [ ] o cache e restaurado antes de instalar dependencias.\n\n## 4) Cache em pipelines com ARM64 e x64\n\nQuando voce tem ARM64 e x64:\n\n- caches de dependencias nativas nao podem ser compartilhados\n- caches precisam ser duplicados (um por arquitetura)\n\nRegra pratica:\n\n- nunca compartilhe cache entre arquiteturas sem colocar `arch` no key\n\n## Checklist final\n\n- [ ] Cache key inclui lockfile hash.\n- [ ] Cache key inclui OS + arquitetura.\n- [ ] restore/fallback keys existem (mas nao para output de build).\n- [ ] Cache e para dependencias (artifact e para outputs).\n- [ ] Metrica observavel: tempo economizado por job (antes/depois).\n\n## Referencias\n\n- [GitHub Docs: Caching dependencies and build outputs](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows)\n- [GitLab Docs: Caching in GitLab CI/CD](https://docs.gitlab.com/ci/caching/)\n"},"07aecdad-2525-5c62-bb25-294606a047bd":{"id":"07aecdad-2525-5c62-bb25-294606a047bd","title":"Recurring costs clients must plan for (so an app does not die after launch)","content":"\n> \"Launch is a milestone. Reliable operation is what keeps software alive.\"\n\nMany apps go down (or slowly degrade) after launch for reasons unrelated to code quality: **expired domain**, **expired certificate**, **cloud payment failure**, **SMS provider disruption**, or **maps quota issues**.\n\nThis guide helps non-technical stakeholders understand **which recurring costs exist**, **what breaks when they fail**, and **how to organize monthly approvals** to avoid production incidents.\n\n![Cover image: recurring app costs](/assets/img/custos-recorrentes-capa.png \"Recurring app costs: what to plan so your product stays healthy after launch.\")\n\n## What you'll find here\n\n- A practical map of recurring cost categories\n- A simple monthly checklist to prevent surprises\n- Typical cost centers: domain/DNS, HTTPS, cloud, SMS/email, maps, storage, monitoring\n- What happens when renewal/payment fails\n- How to define owners for monthly cost approval and operational follow-up\n- Why DevOps/operations capacity is essential after launch\n\n## \"The app died\" usually means a dependency failed\n\nMost products depend on multiple external services at once:\n\n- **Domain/subdomain** for API and admin portal\n- **HTTPS certificate** for secure communication\n- **Cloud/server infrastructure** and **database**\n- **Transactional email** provider\n- **SMS/OTP** provider\n- **Maps/geolocation** services\n- **Storage** and backups\n- **Monitoring, logs, and alerts**\n\n![Post-launch needs overview](/assets/img/devops-slide-04.png \"Common post-launch needs: improvements, fixes, integrations, monitoring, and ongoing operation.\")\n\n## Monthly checklist: the minimum baseline\n\nEven without a dedicated technical department, a monthly operational checklist dramatically reduces risk.\n\n![Recurring costs checklist](/assets/img/custos-recorrentes-01-checklist.png \"Monthly recurring cost checklist with warning signs and ownership.\")\n\nTip: every line item needs an explicit **owner** and a **deadline/threshold alert**.\n\n---\n\n## Most common recurring costs (and what happens if ignored)\n\nNot every project has every item, but most products have some version of each category below.\n\n### 1) Domain and DNS (API, portal, links)\n\nTypical cost:\n- Domain renewal (usually yearly)\n- Optional managed DNS plan\n\nRisk if neglected:\n- API/portal hostname stops resolving\n- Email domain can be affected\n- HTTPS issuance/renewal can fail\n\nBest practices:\n- Enable auto-renewal\n- Keep at least two company owners with access\n- Keep ownership in the company (not personal accounts)\n\n### 2) HTTPS certificate (TLS)\n\nTypical cost:\n- Certificate issuance/renewal (free or paid)\n- Operational effort to guarantee renewal flow\n\nRisk if neglected:\n- Secure API calls start failing\n- Browser security warnings on portals\n- Integrations may fail silently\n\nBest practices:\n- Prefer auto-renew setup\n- Alert before expiration (for example 30 days)\n- Never bypass TLS validation in production apps\n\n### 3) Cloud/server runtime (API, portal, jobs)\n\nTypical cost:\n- Compute resources (VMs/containers/serverless)\n- Network traffic\n- Supporting services (queue, cache, CDN, gateway, balancer)\n\nRisk if payment fails:\n- Suspension/limitation by provider\n- Slow, unstable, or unavailable app\n\nBest practices:\n- Budget alerts and hard thresholds\n- Clear production vs staging ownership\n- Safe credential management and documentation\n\n### 4) Database and backups\n\nTypical cost:\n- Managed DB or DB server\n- Backup storage and retention\n- Optional replication/high availability\n\nRisk if neglected:\n- Data-loss incidents become critical business loss\n- Recovery under pressure becomes unreliable\n\nBest practices:\n- Automated backups + retention policy\n- Periodic restore tests (at least quarterly)\n\n### 5) Storage and CDN (when applicable)\n\nTypical cost:\n- Object storage volume\n- Download/egress traffic\n- Retention lifecycle\n\nRisk if uncontrolled:\n- Cost grows silently with media usage\n- Later migration becomes expensive\n\nBest practices:\n- Upload limits and compression policy\n- Separate product storage from backup storage\n\n### 6) Transactional email\n\nTypical cost:\n- Sending volume\n- Sender authentication setup (SPF, DKIM, DMARC)\n\nRisk if misconfigured:\n- Password reset and onboarding emails go to spam\n- Support volume increases\n\nBest practices:\n- Configure SPF/DKIM/DMARC\n- Monitor deliverability and bounce rate\n- Keep support mailbox operational\n\n### 7) SMS / OTP\n\nTypical cost:\n- Per-message usage billing\n- In some regions, sender registration overhead\n\nRisk if budget/limit fails:\n- Users cannot receive login codes\n- Direct conversion and access impact\n\nBest practices:\n- Monthly limits and alerts\n- Use alternative channels when possible (email/push)\n- Enforce resend cooldown and abuse controls\n\n### 8) Maps and geolocation APIs\n\nTypical cost:\n- Maps/places/geocoding API usage\n- Billing account maintenance\n- API key protection\n\nRisk if billing/quota fails:\n- Maps stop loading\n- Address resolution fails\n- Core UX appears broken\n\nBest practices:\n- Restrict keys by app/domain\n- Set usage alerts and caps\n- Cache repeated lookups when possible\n\n### 9) Monitoring, logs, and alerts\n\nTypical cost:\n- Monitoring platform fees or infra\n- Engineering time for alert triage/incident response\n\nRisk without monitoring:\n- Outages discovered by customers first\n- Performance problems become subjective instead of measurable\n\nBest practices:\n- Baseline alerts: availability, 5xx, latency, DB health\n- Clear incident channel and owner\n\n### 10) Apple/Google publishing accounts\n\nTypical cost:\n- Apple Developer renewal\n- Ongoing compliance/ownership maintenance in Play Console\n\nRisk if access or compliance fails:\n- You lose ability to ship updates and fixes\n\nBest practices:\n- Company-owned credentials\n- 2FA with backup method and backup owner\n- Clear ownership transfer process\n\n---\n\n## The most important recurring cost: continuous operation and improvement\n\nSome recurring costs are not vendor invoices. They are delivery capacity to:\n\n- Fix defects\n- Update business rules\n- Improve performance\n- React to user feedback\n- Keep dependencies secure and current\n- Maintain compatibility with iOS/Android updates\n\nThis is the core of DevOps lifecycle discipline:\n\n![DevOps cycle](/assets/img/devops-slide-05.png \"Plan, Code, Build, Test, Release, Deploy, Operate, Monitor.\")\n\nAnd these are the most common post-launch requests teams face:\n\n![Common post-launch improvements](/assets/img/devops-slide-11.png \"Improvements, corrections, integrations, business-rule updates, and new features.\")\n\nIf you want dedicated support in this phase, X-Apps offers a focused **Operations and DevOps** service to keep software healthy and relevant over time: [Learn about Operations & DevOps service](https://www.x-apps.com.br/servicos/operacao-devops)\n\n![Count on X-Apps](/assets/img/devops-slide-16.png \"Protect and maximize return on your software investment.\")\n\n---\n\n## Who should approve monthly budget (without blocking delivery)\n\nTo avoid approval ping-pong, define three clear roles:\n\n1. **Product/business owner** \nSets priorities and approves roadmap changes.\n\n2. **Technical operations owner** \nTracks alerts, risk, and service health.\n\n3. **Finance approver** \nKeeps recurring services paid and enforces budget thresholds.\n\nA practical governance flow:\n\n- Technical team sends a short monthly report (usage, changes, risks)\n- Finance uses predefined approval thresholds\n- Critical incidents follow fast-track approval\n\n---\n\n## Using your existing domain vs buying a new one\n\nUsing your main company domain with subdomains is usually the best default.\n\nAdvantages:\n- Fewer renewals to manage\n- Better brand consistency (`api.yourdomain.com`)\n- Lower risk of forgotten side domains\n\nCautions:\n- DNS edits must be controlled and documented\n- Keep at least two administrative owners\n\nWhen a separate domain can make sense:\n- Strict governance isolation\n- Independent product/business unit strategy\n\nIf you buy a separate domain, enforce company ownership and auto-renewal from day one.\n\n---\n\n## Final internal approval checklist (copy and paste)\n\n- [ ] Domain auto-renew enabled, company ownership confirmed\n- [ ] API/admin subdomains clearly defined\n- [ ] HTTPS renewal automated and monitored\n- [ ] Cloud payment and cost alerts active\n- [ ] Database backup automated + restore tested\n- [ ] Storage limits/retention rules in place\n- [ ] SPF/DKIM/DMARC configured for transactional email\n- [ ] SMS limits and resend policy defined\n- [ ] Maps billing and key restrictions configured\n- [ ] Monitoring active with named owner\n- [ ] Monthly process for technical review and finance approval active\n\nWith this baseline, your product can grow sustainably instead of failing due to preventable operational gaps.\n"},"8c48e751-c497-5aaa-abe5-7de7deb604a3":{"id":"8c48e751-c497-5aaa-abe5-7de7deb604a3","title":"Custos recorrentes que o cliente precisa prever (para o app nao \"morrer\" depois do lancamento)","content":"\n> \"Lancar e um marco. Operar bem e o que mantem o software vivo.\"\n\nE comum um app sair do ar (ou \"morrer aos poucos\") depois do lancamento por motivos que nao tem nada a ver com o codigo em si: **dominio expirou**, **certificado venceu**, **conta da nuvem ficou sem pagamento**, **SMS parou de funcionar**, **mapa deixou de carregar**.\n\nEste artigo foi escrito para clientes e times nao tecnicos entenderem, de forma simples, **quais custos recorrentes existem**, **o que acontece se algum deles falhar** e **como organizar a aprovacao mensal** para evitar sustos.\n\n![Planejamento de metas e acompanhamento financeiro ao lado de um notebook](/assets/img/custos-recorrentes-app-dominio-https-sms-mapas-nuvem.jpg \"Custos recorrentes do app: o que prever para o app nao morrer depois do lancamento.\")\n\n## O que voce vai encontrar aqui\n\n- Um mapa rapido do que gera custo recorrente (e por que)\n- Checklist mensal (simples) para a empresa nao ser pega de surpresa\n- Custos tipicos: dominio/DNS, HTTPS, nuvem, SMS/e-mail, mapas, storage e monitoramento\n- O que acontece quando **nao renova** ou quando **o pagamento falha**\n- Como definir \"quem aprova\" e \"quem acompanha\" o orcamento mensal\n- Por que ter um time de operacao/DevOps evita que o app fique obsoleto\n\n## \"O app morreu\" quase sempre significa \"alguma dependencia parou\"\n\nO app normalmente depende de varios servicos ao mesmo tempo:\n\n- Um **dominio** (ex.: `api.suaempresa.com`) para a API e, muitas vezes, outro para o **portal administrativo** \n- Um **certificado HTTPS** para trafegar dados com seguranca \n- Um **servidor** (ou varios) e um **banco de dados** \n- Um servico de **e-mail transacional** (recuperacao de senha, notificacoes, onboarding) \n- Um servico de **SMS/OTP** (autenticacao, confirmacoes) \n- **Mapas/geolocalizacao** (quando o app usa enderecos, rotas, lojas proximas etc.) \n- **Storage** para arquivos (imagens, documentos) e **backups** \n- **Monitoramento e logs**, para detectar problemas antes do cliente reclamar \n\nA apresentacao abaixo resume bem o tipo de necessidade que aparece logo apos o lancamento:\n\n![Principais necessidades apos o lancamento](/assets/img/devops-slide-04.png \"Principais necessidades apos o lancamento: melhorias, correcoes, integracoes, monitoramento e manutencao de regras/conteudo.\")\n\n## Checklist mensal: o minimo para nao ter surpresa\n\nSe a sua empresa nao tem uma area tecnica dedicada, tudo bem: voce ainda consegue se proteger com um checklist basico (feito 1x por mes).\n\n![Checklist de custos recorrentes](/assets/img/custos-recorrentes-01-checklist.png \"Checklist de custos recorrentes: itens, o que checar e sinais de alerta.\")\n\nDica: o checklist funciona melhor quando cada item tem um **responsavel** (mesmo que nao seja tecnico) e um **alerta** de vencimento/limite.\n\n---\n\n## Custos recorrentes mais comuns (e o que acontece se nao cuidar)\n\nAbaixo estao os itens mais frequentes em projetos de apps e sistemas. Nem todo projeto tera todos eles, mas quase sempre voce tera \"uma versao\" de cada categoria.\n\n### 1) Dominio e DNS (API, portal, links do app)\n\nO dominio e o que transforma um IP em uma URL estavel.\n\nExemplos comuns:\n- `api.suaempresa.com` (API do app)\n- `admin.suaempresa.com` (portal administrativo)\n- `app.suaempresa.com` (site, landing page, web app)\n\nO que entra como custo recorrente:\n- **Renovacao do dominio** (geralmente anual)\n- As vezes: servico de **DNS gerenciado** (em provedores como Cloudflare, AWS, Google, Microsoft etc.)\n\nO que acontece se nao renovar:\n- A API/portal ficam **fora do ar** (porque o endereco deixa de existir)\n- Voce pode perder e-mails do dominio\n- Voce nao consegue emitir/renovar certificados HTTPS para esse endereco\n\nBoas praticas simples:\n- Ative **auto-renovacao** e mantenha **2 pessoas** com acesso (ex.: TI + financeiro)\n- Garanta que o dominio esteja em nome da empresa (nao de um ex-funcionario/terceiro)\n- Use **subdominios** (na maioria dos casos, nao precisa comprar um novo dominio)\n\n### 2) Certificado HTTPS (TLS)\n\nApps modernos trafegam dados sensiveis e, por padrao, esperam comunicacao segura. Na pratica, isso significa: **API em HTTPS**.\n\nO que entra como custo recorrente:\n- Certificado TLS/HTTPS (pode ser gratuito ou pago, depende da solucao)\n- Operacao de renovacao (mesmo quando e \"gratuito\", alguem precisa garantir que a renovacao aconteceu)\n\nO que acontece se o certificado vencer:\n- O app comeca a falhar em chamadas para a API (\"erro de conexao segura\")\n- Portais web passam a exibir aviso de seguranca no navegador\n- Integracoes podem parar silenciosamente\n\nBoas praticas simples:\n- Prefira certificados com **renovacao automatica** (ex.: por ferramenta/servico)\n- Configure alerta de expiracao (ex.: 30 dias antes)\n- Evite \"gambiarras\" como desativar validacao de HTTPS no app (isso vira risco de seguranca)\n\n### 3) Nuvem / servidor (API, portal e rotinas)\n\nEsse e o custo que mantem o sistema \"respirando\" (CPU, memoria, rede).\n\nO que entra como custo recorrente:\n- Servidores/containers/serverless\n- Trafego de rede (principalmente se ha upload/download de arquivos)\n- Servicos auxiliares (fila, cache, CDN, gateway, balanceador)\n\nO que acontece se o pagamento falhar:\n- O provedor pode **suspender** recursos (ou limitar)\n- O app fica lento, intermitente ou fora do ar\n\nBoas praticas simples:\n- Crie alertas de custo e defina um \"teto\" operacional (para evitar surpresa)\n- Separe ambientes (producao vs homologacao), com regras claras de quem mantem cada um\n- Mantenha credenciais e acesso em local seguro (e documentado)\n\n### 4) Banco de dados e backups\n\nBanco de dados costuma ser o coracao: se ele cai, o app \"fica cego\".\n\nO que entra como custo recorrente:\n- Banco gerenciado ou servidor de banco\n- Backups automaticos (storage) e retencao\n- Replicacao/alta disponibilidade (quando necessario)\n\nO que acontece se nao houver backup:\n- Um incidente vira prejuizo: pode ser impossivel recuperar dados\n- Qualquer restauracao vira \"tentativa e erro\" sob pressao\n\nBoas praticas simples:\n- Backup automatico + politica de retencao\n- Teste de restore (pelo menos 1x por trimestre) \n Backup que nunca foi testado e aposta.\n\n### 5) Storage (arquivos) e CDN (quando aplicavel)\n\nFotos, documentos, relatorios, notas fiscais tudo isso vai para algum lugar.\n\nO que entra como custo recorrente:\n- Armazenamento de objetos (arquivos)\n- Trafego e entrega (download)\n- Politicas de retencao (guardar por quanto tempo?)\n\nO que acontece se nao controlar:\n- O custo cresce \"sem voce perceber\" (especialmente com midia)\n- Fica caro para migrar depois porque ja esta acoplado ao produto\n\nBoas praticas simples:\n- Defina limites e regras: tamanho maximo de upload, compressao de imagens, retencao\n- Separe storage \"do app\" (producao) do storage \"de backup\"\n\n### 6) E-mail transacional (recuperacao de senha, avisos, onboarding)\n\nQuase todo app precisa disparar e-mails: confirmacao, troca de senha, recibos, avisos.\n\nO que entra como custo recorrente:\n- Servico de envio (por volume)\n- Configuracao de autenticacao de e-mail (SPF/DKIM/DMARC no DNS)\n\nO que acontece se nao configurar corretamente:\n- O e-mail \"ate sai\", mas cai em **spam**\n- Recuperacao de senha vira uma dor (e vira suporte)\n\nBoas praticas simples:\n- Configure SPF/DKIM/DMARC (o time tecnico normalmente orienta os registros DNS)\n- Monitore taxa de entrega e rejeicoes\n- Tenha um e-mail \"de suporte\" funcionando (mesmo que simples)\n\n### 7) SMS / OTP (autenticacao, confirmacoes)\n\nSMS e custo que pega muita empresa de surpresa porque e \"barato por unidade\" e \"caro em volume\".\n\nO que entra como custo recorrente:\n- Custo por envio (volume)\n- As vezes: custos de validacao/registro do remetente (depende do pais e do provedor)\n\nO que acontece se nao tiver saldo/limite:\n- Usuario nao recebe codigo e nao consegue entrar (impacto direto no negocio)\n\nBoas praticas simples:\n- Defina limite mensal e alertas\n- Evite SMS para tudo: use e-mail/push quando fizer sentido\n- Trate reenvio com regras (ex.: cooldown) para evitar abuso\n\n### 8) Mapas e geolocalizacao\n\nSe o app tem enderecos, lojas, rotas, entregas, raio de busca mapas e geocoding entram no jogo.\n\nO que entra como custo recorrente:\n- APIs de mapas/places/geocoding (normalmente cobram por uso e exigem billing)\n- Protecao de chaves (para evitar uso indevido)\n\nO que acontece se billing for desativado ou a cota estourar:\n- O mapa nao carrega\n- Endereco nao \"resolve\" (geocoding)\n- O app passa a parecer quebrado\n\nBoas praticas simples:\n- Restrinja chaves por dominio/app (evita uso indevido)\n- Monitore consumo e configure alertas\n- Use cache quando possivel (ex.: enderecos repetidos)\n\n### 9) Monitoramento, logs e alertas\n\nEsse item nao \"aparece para o usuario\" - mas evita incendio.\n\nO que entra como custo recorrente:\n- Ferramenta de logs/monitoramento (ou estrutura propria)\n- Tempo de alguem olhando alertas e agindo (principalmente em incidentes)\n\nO que acontece sem monitoramento:\n- Voces descobrem que esta fora do ar **quando o cliente reclama**\n- Bugs e lentidao viram \"sensacao\" em vez de dado\n\nBoas praticas simples:\n- Alertas do basico: disponibilidade, erro 5xx, tempo de resposta, banco de dados\n- Canal de incidentes e um responsavel por acionar o time tecnico\n\n### 10) Contas de publicacao (Apple/Google)\n\nMesmo depois do app publicado, as contas continuam sendo essenciais para publicar atualizacoes e manter tudo regular.\n\nO que entra como custo recorrente:\n- A conta Apple Developer e uma assinatura/renovacao (e precisa ficar ativa para publicar updates)\n- No Google Play, a inscricao e feita via console e a conta precisa ficar em conformidade e segura (2FA, dados da organizacao etc.)\n\nO que acontece se deixar \"expirar\" ou perder acesso:\n- Voce perde capacidade de publicar novas versoes (e isso trava melhorias e correcoes)\n\nBoas praticas simples:\n- Acesso sempre na empresa (nao em e-mail pessoal)\n- 2FA bem configurado com backup e \"pessoa reserva\"\n- Processo claro de troca de responsaveis (quando alguem sai da empresa)\n\n---\n\n## O custo mais importante: operacao e melhoria continua\n\nUma parte do custo recorrente nao e \"conta de servico\". E **capacidade de evoluir** o software:\n\n- Corrigir bugs\n- Ajustar regras de negocio\n- Melhorar performance\n- Reagir a feedback de usuarios\n- Atualizar dependencias e seguranca\n- Manter o app compativel com novas versoes de iOS/Android\n\nEsse ciclo e a base do DevOps (planejar, construir, testar, publicar, operar e monitorar):\n\n![Ciclo de DevOps e melhoria continua](/assets/img/devops-slide-05.png \"Ciclo de DevOps: Plan, Code, Build, Test, Release, Deploy, Operate, Monitor.\")\n\nE, na pratica, as melhorias mais comuns depois do lancamento costumam ser estas:\n\n![O que podemos fazer para o seu software e app](/assets/img/devops-slide-11.png \"Aprimoramentos e correcoes, integracoes, adaptacao nas regras e novas funcionalidades.\")\n\nSe voce quiser apoio nessa fase, a X-Apps tem um servico dedicado de **Operacao e DevOps**, focado em manter o software relevante e saudavel no medio e longo prazo: [Conheca o servico de Operacao DevOps](https://www.x-apps.com.br/servicos/operacao-devops)\n\n![Conte com a X-Apps](/assets/img/devops-slide-16.png \"Conte com a X-Apps para proteger e maximizar o retorno do seu investimento.\")\n\n---\n\n## Quem aprova orcamento mensal (e como evitar travar o time)\n\nPara nao virar \"ping-pong\" de aprovacao, defina 3 papeis (simples):\n\n1. **Responsavel pelo produto (negocio)** \n Define prioridades e aprova o que entra no roadmap.\n\n2. **Responsavel tecnico (operacao/DevOps)** \n Acompanha alertas, riscos, consumo e garante que tudo esta funcionando.\n\n3. **Aprovador financeiro (orcamento mensal)** \n Garante que as contas estao em dia e que existe um teto de custo para os servicos variaveis.\n\nUm fluxo que funciona bem:\n- O time tecnico manda um **relatorio mensal simples** (o que consumiu, o que mudou, riscos)\n- O financeiro tem um **teto de aprovacao** (ate X, aprova automatico; acima de X, precisa validar)\n- Incidentes criticos tem caminho rapido de aprovacao (para nao parar o negocio)\n\n---\n\n## Usar o dominio que voce ja tem vs comprar um novo\n\nUsar o dominio da empresa (com subdominios) e o caminho mais comum - e geralmente o melhor.\n\nVantagens de usar o dominio existente:\n- Nao cria mais uma renovacao para lembrar\n- Mantem marca e comunicacao alinhadas (`api.suaempresa.com`)\n- Menos risco de alguem esquecer \"aquele dominio do app\"\n\nCuidados ao usar o dominio existente:\n- Evitar mexer na zona DNS \"sem controle\" (use mudanca registrada e com responsavel)\n- Ter pelo menos duas pessoas com acesso administrativo\n\nQuando faz sentido comprar um dominio separado:\n- Voce quer isolar totalmente o app (ex.: empresa grande com governanca rigida)\n- Voce quer um dominio especifico para uma unidade/produto\n\nCuidados ao comprar outro dominio:\n- Coloque em nome da empresa e ative auto-renovacao\n- Se nao renovar, o impacto e grande: API e portal podem cair\n\n---\n\n## Checklist final para aprovar internamente (copie e cole)\n\n- [ ] Dominio com auto-renovacao, acesso na empresa e contato atualizado \n- [ ] Subdominios definidos (API e portal) \n- [ ] HTTPS com renovacao automatica e alerta de expiracao \n- [ ] Nuvem com pagamento ok e alertas de custo configurados \n- [ ] Banco com backup automatico + restore testado \n- [ ] Storage com limites/retencao definidos \n- [ ] E-mail transacional com SPF/DKIM/DMARC configurados \n- [ ] SMS com limite, alertas e politica de reenvio \n- [ ] Mapas com billing e protecao de chaves \n- [ ] Monitoramento ativo e responsavel nomeado \n- [ ] Processo mensal: quem acompanha e quem aprova \n\nSe voce quiser, podemos transformar esse checklist em um documento de \"pronto para operar\" do seu projeto e assumir a operacao continua junto com voces.\n"},"a39aa29b-89d8-5d87-9736-266d424ec0a9":{"id":"a39aa29b-89d8-5d87-9736-266d424ec0a9","title":"GitLab CI: tags de runner e roteamento de jobs (sem dor)","content":"\nTags de runner sao uma das formas mais simples (e mais subutilizadas) de acelerar pipelines no GitLab.\n\nElas resolvem um problema bem especifico: garantir que um job rode no runner certo, no momento certo, com o ambiente certo.\n\nEste post faz parte da serie:\n\n- [Guia de CI/CD no Git para times pequenos: performance, cache e runners](/guia-cicd-times-pequenos-performance-cache-runners)\n\n## Mapa da serie CI/CD\n\n- [Guia de CI/CD no Git para times pequenos: performance, cache e runners](/guia-cicd-times-pequenos-performance-cache-runners)\n- [GitLab CI: tags de runner e roteamento de jobs](/gitlab-ci-tags-de-runner)\n- [Cache no CI/CD: como desenhar keys e evitar cache invalido (GitHub e GitLab)](/cache-ci-cd-keys-invalidation-github-gitlab)\n- [Docker layer caching no CI: BuildKit, buildx, cache-from e cache-to](/docker-layer-caching-ci-buildkit-buildx)\n- [Runner dedicado no CI/CD: quando vale a pena e como planejar em time pequeno](/runner-dedicado-ci-cd-time-pequeno)\n- [Runners macOS no CI: Intel vs Apple Silicon, custos e armadilhas](/runner-macos-ci-intel-apple-silicon)\n\n## O problema: job preso, rodando no runner errado, ou fila infinita\n\nSintomas comuns:\n\n- Job fica em \"pending\" por muito tempo.\n- Job roda em um runner lento (e as vezes, em um runner rapido).\n- Build funciona em um runner e quebra em outro (arquitetura, dependencias nativas, Docker).\n\nA causa quase sempre e uma destas:\n\n- Nao existe tag no job (ou existe tag demais, mal desenhada).\n- Runner \"generico\" aceita tudo.\n- Existe mistura de arquiteturas (ARM64/x64) e o roteamento nao leva isso em conta.\n\n## Como tags funcionam no GitLab CI (na pratica)\n\nNo GitLab, um runner pode ter **zero ou mais tags**. Um job pode declarar tags no `.gitlab-ci.yml`.\n\nRegra fundamental:\n\n- Se o job declara tags, ele so pode rodar em um runner que tenha todas as tags do job.\n- Se o runner estiver configurado para aceitar somente jobs com tag, jobs sem tags podem ficar sem runner.\n\n## 1) Desenhe tags como \"classes de execucao\", nao como apelidos\n\nEvite tags que sao so nomes (\"runner-1\", \"imac-do-fulano\").\n\nPrefira tags que descrevem capacidade/ambiente:\n\n- `linux-x64`\n- `linux-arm64`\n- `macos`\n- `windows`\n- `docker`\n- `build-heavy`\n- `gpu` (se aplicavel)\n\nDica: o melhor conjunto de tags e o menor que ainda separa seus gargalos.\n\n## 2) Crie um \"runner padrao\" para jobs leves\n\nUma armadilha comum em times pequenos e ter um unico runner aceitando tudo.\n\nO resultado:\n\n- O job pesado (build Docker) trava a fila.\n- O job leve (lint) espera atras do job pesado.\n\nUma estrategia simples:\n\n- Runner A (padrao): jobs leves (lint/test rapido).\n- Runner B (pesado): builds e jobs longos.\n- Runner C (macOS): apenas jobs Apple.\n\n## 3) Use tags para separar arquitetura (ARM64 vs x64)\n\nSe voce tem Apple Silicon, Graviton, ou ARM64 em qualquer parte do pipeline, trate isso como uma dimensao explicita.\n\n- Cache de dependencias pode nao ser compativel.\n- Binarios pre-compilados mudam.\n- Docker images precisam existir para aquela arquitetura (ou entram em emulacao).\n\nExemplo de jobs separados:\n\n```yaml\nbuild_amd64:\n tags: [linux-x64, docker]\n script:\n - ./ci/build.sh\n\nbuild_arm64:\n tags: [linux-arm64, docker]\n script:\n - ./ci/build.sh\n```\n\nLeitura complementar:\n\n- [ARM64 vs x64 em CI/CD: como evitar builds quebrando e cache inutil](/guia-cicd-times-pequenos-performance-cache-runners)\n\n## 4) Checklist rapido de \"job stuck\" (antes de culpar o GitLab)\n\n1. O job tem tags? Quais?\n2. Existe runner online com essas tags?\n3. Esse runner aceita jobs com tag (e esta habilitado para esse projeto/grupo)?\n4. O runner esta ocupado com jobs longos (fila)?\n5. Existe conflito de arquitetura?\n\n## Checklist final\n\n- [ ] Tags descrevem ambiente/capacidade (nao pessoas).\n- [ ] Existe separacao entre jobs leves e jobs pesados.\n- [ ] Arquitetura (ARM/x64) e explicita em tags e em cache keys.\n- [ ] Runner \"generico\" nao esta aceitando tudo indiscriminadamente.\n- [ ] Documentacao rapida: \"quais tags existem e quando usar\".\n\n## Referencias\n\n- [GitLab Docs: Configuring runners (tags, jobs tagged/untagged)](https://docs.gitlab.com/ci/runners/configure_runners/)\n- [GitLab Docs: GitLab.com hosted runners on Linux (tags por tamanho/arquitetura)](https://docs.gitlab.com/ci/runners/hosted_runners/linux/)\n"},"996a1117-0842-5b00-9cee-4fc50ece70f7":{"id":"996a1117-0842-5b00-9cee-4fc50ece70f7","title":"Docker layer caching no CI: BuildKit, buildx, cache-from e cache-to","content":"\nQuando um pipeline \"demora\", muitas vezes o culpado e um `docker build` repetindo trabalho.\n\nO objetivo deste post e voce sair com um plano claro para:\n\n- deixar seu Dockerfile cache-friendly\n- reaproveitar layers entre pipelines (via registry ou runner dedicado)\n- evitar armadilhas em ARM64 e x64\n\nEste post faz parte da serie:\n\n- [Guia de CI/CD no Git para times pequenos: performance, cache e runners](/guia-cicd-times-pequenos-performance-cache-runners)\n\n## Mapa da serie CI/CD\n\n- [Guia de CI/CD no Git para times pequenos: performance, cache e runners](/guia-cicd-times-pequenos-performance-cache-runners)\n- [GitLab CI: tags de runner e roteamento de jobs](/gitlab-ci-tags-de-runner)\n- [Cache no CI/CD: como desenhar keys e evitar cache invalido (GitHub e GitLab)](/cache-ci-cd-keys-invalidation-github-gitlab)\n- [Docker layer caching no CI: BuildKit, buildx, cache-from e cache-to](/docker-layer-caching-ci-buildkit-buildx)\n- [Runner dedicado no CI/CD: quando vale a pena e como planejar em time pequeno](/runner-dedicado-ci-cd-time-pequeno)\n- [Runners macOS no CI: Intel vs Apple Silicon, custos e armadilhas](/runner-macos-ci-intel-apple-silicon)\n\n## O basico que resolve 80%: ajuste o Dockerfile\n\nO cache de layers funciona por instrucao do Dockerfile.\n\nSe voce copia o repositorio inteiro antes de instalar dependencias, qualquer mudanca invalida tudo.\n\nPadrao recomendado:\n\n1. Copiar manifestos/lockfiles.\n2. Instalar dependencias.\n3. Copiar o restante do codigo.\n4. Fazer build.\n\nExemplo (Node):\n\n```Dockerfile\nFROM node:20 AS build\nWORKDIR /app\n\nCOPY package*.json ./\nRUN npm ci\n\nCOPY . .\nRUN npm run build\n```\n\n## 1) O que e \"Docker layer caching\" no CI (na pratica)\n\nLayer caching e reaproveitar resultados de passos anteriores do Docker build.\n\nNo CI, voce so reaproveita layers de forma consistente quando:\n\n- o runner mantem cache local (runner dedicado)\n- ou voce usa um cache remoto (registry cache)\n\n## 2) Estrategia recomendada: cache no registry\n\nA ideia e simples:\n\n- `--cache-to` publica cache no registry\n- `--cache-from` puxa cache do registry na proxima execucao\n\nExemplo conceitual com BuildKit/buildx:\n\n```bash\ndocker buildx build --cache-from=type=registry,ref=registry.exemplo.com/app:buildcache --cache-to=type=registry,ref=registry.exemplo.com/app:buildcache,mode=max -t registry.exemplo.com/app:${GIT_SHA} .\n```\n\n## 3) Em runners dedicados: cache local funciona muito bem\n\nSe voce tem runner dedicado (e ele nao e efemero), o daemon Docker pode manter layers localmente.\n\nVantagens:\n\n- muito rapido\n- simples de operar\n\nRiscos:\n\n- runner compartilhado com muitos projetos \"enche disco\"\n- isolamento e seguranca precisam ser considerados (principalmente com Docker-in-Docker)\n\n## 4) ARM64 vs x64 em docker build\n\nSe voce constroi images para mais de uma arquitetura:\n\n- build em emulacao e mais lento\n- caches nao sao totalmente reaproveitaveis entre arch\n\nBoas praticas:\n\n- separar pipelines (ou matrix) por arquitetura\n- usar buildx multi-arch quando fizer sentido\n- evitar misturar caches de arch\n\n## Checklist final\n\n- [ ] Dockerfile copia manifestos antes do codigo.\n- [ ] Dependencias sao instaladas em layer estavel (cache reaproveita).\n- [ ] Existe estrategia de cache (registry ou local).\n- [ ] Arquitetura faz parte da estrategia (ARM/x64).\n- [ ] Build e observavel: tempo antes/depois e cache hit/miss.\n\n## Referencias\n\n- [GitLab Docs: Make Docker-in-Docker builds faster with Docker layer caching](https://docs.gitlab.com/ci/docker/using_docker_build/#make-docker-in-docker-builds-faster-with-docker-layer-caching)\n"},"7b33de96-10e7-501a-b015-221b0d91c57d":{"id":"7b33de96-10e7-501a-b015-221b0d91c57d","title":"Guia de CI/CD no Git para times pequenos: performance, cache e runners","content":"\nPipeline lento quase nunca e \"so falta de CPU\".\n\nNa pratica, times pequenos sofrem com tres dores recorrentes:\n\n- Jobs esperando em fila porque cairam no runner \"errado\" (ou no runner \"certo\", mas lotado).\n- Build repetindo trabalho porque cache nao existe, esta mal configurado, ou invalida a cada commit.\n- Builds Docker sempre \"do zero\" porque layer cache nao esta sendo reaproveitado.\n\nEste guia e um passo a passo para voce atacar essas dores sem depender de \"milagre\" e sem criar um CI/CD fragil.\n\n- Se voce usa GitLab CI/CD, GitHub Actions, ou ambos, este post cobre os conceitos e da exemplos dos dois.\n- Se voce tem builds em ARM64 (Graviton / Apple Silicon) e x64, aqui tem um bloco especifico para evitar armadilhas de arquitetura.\n\n\n\n## Mapa da serie CI/CD\n\n- [Guia de CI/CD no Git para times pequenos: performance, cache e runners](/guia-cicd-times-pequenos-performance-cache-runners)\n- [GitLab CI: tags de runner e roteamento de jobs](/gitlab-ci-tags-de-runner)\n- [Cache no CI/CD: como desenhar keys e evitar cache invalido (GitHub e GitLab)](/cache-ci-cd-keys-invalidation-github-gitlab)\n- [Docker layer caching no CI: BuildKit, buildx, cache-from e cache-to](/docker-layer-caching-ci-buildkit-buildx)\n- [Runner dedicado no CI/CD: quando vale a pena e como planejar em time pequeno](/runner-dedicado-ci-cd-time-pequeno)\n- [Runners macOS no CI: Intel vs Apple Silicon, custos e armadilhas](/runner-macos-ci-intel-apple-silicon)\n\n## 1) Diagnostico rapido: o gargalo e fila ou execucao?\n\nAntes de otimizar, voce precisa separar duas metricas.\n\n- Tempo de fila (queue time): tempo entre o job ser criado e efetivamente comecar.\n- Tempo de execucao (run time): tempo real que o job ficou rodando.\n\nIsso importa porque as correcoes sao diferentes:\n\n- Fila alta problema de capacidade/roteamento (runners).\n- Execucao alta problema de build (cache, Docker layers, dependencias, paralelismo).\n\n### 1.1 Como medir sem ferramentas extras\n\n1. Abra o log do job e anote:\n - horario de criacao\n - horario de inicio\n - horario de termino\n\n2. Calcule:\n - fila = inicio - criacao\n - execucao = termino - inicio\n\n3. Faca isso para 5 a 10 execucoes (nao so uma). Pipeline \"lento as vezes\" quase sempre e concorrencia + runner compartilhado + variacao de rede/hardware.\n\n### 1.2 Regra de bolso para times pequenos\n\n- Se a fila for > 30% do tempo total, pare de \"otimizar build\" e comece por runners.\n- Se a execucao for > 70% do tempo total, seu ROI maior tende a ser cache e Docker layer caching.\n\n## 2) Runners: como evitar job no runner \"errado\"\n\nO sintoma classico e: \"as vezes e rapido, as vezes fica 10 minutos esperando\".\n\nEm geral isso acontece quando:\n\n- Falta criterio para direcionar jobs (tags/labels).\n- Existe um runner \"generico\" aceitando tudo (inclusive jobs pesados).\n- O pipeline depende de maquinas de desenvolvimento (Wi-Fi, uso local, variacao de hardware).\n\n### 2.1 GitLab: tags de runner (e o que quase todo mundo erra)\n\nNo GitLab, tags de CI/CD servem para controlar quais jobs um runner pode executar (nao confundir com Git tags de commits). Um job so roda em um runner que tenha **todas** as tags definidas no job. Se o runner estiver configurado para rodar apenas jobs com tag, jobs sem tag podem ficar \"stuck\". \n\nLeitura complementar (satelite):\n\n- [GitLab CI: tags de runner e roteamento de jobs](/gitlab-ci-tags-de-runner)\n\nExemplo de job com tag dedicada:\n\n```yaml\nbuild_web:\n stage: build\n tags:\n - linux-x64\n - docker\n script:\n - npm ci\n - npm run build\n```\n\nBoas praticas para time pequeno:\n\n- Use poucas tags, com significado claro (ex.: `linux-x64`, `linux-arm64`, `macos`, `docker`).\n- Evite tags \"genericas\" que viram uma lixeira (ex.: `build`, `runner1`).\n- Defina um runner \"padrao\" apenas para jobs leves (lint/test rapido), e runners separados para builds pesados.\n\n### 2.2 GitHub Actions: runs-on, labels e runner groups\n\nNo GitHub Actions, voce direciona execucao com `runs-on`. Para runners self-hosted, voce pode usar **labels** e **runner groups** para segmentar quem roda o que.\n\nExemplo simples (hosted runner):\n\n```yaml\njobs:\n test:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - run: npm test\n```\n\nExemplo com runner self-hosted (labels):\n\n```yaml\njobs:\n build:\n runs-on: [self-hosted, linux, x64, build-heavy]\n steps:\n - uses: actions/checkout@v4\n - run: ./ci/build.sh\n```\n\nLeitura complementar (satelite):\n\n- [Runner dedicado no CI/CD: quando vale a pena e como planejar em time pequeno](/runner-dedicado-ci-cd-time-pequeno)\n\n## 3) Cache no CI/CD: dependencias rapidas e builds previsiveis\n\nCache nao e \"acelerador magico\". E um contrato.\n\n- Se o cache \"acerta\", voce economiza minutos.\n- Se o cache \"erra\", voce cria bugs dificeis (artefato antigo, dependencia incompativel, build contaminado).\n\nLeitura complementar (satelite):\n\n- [Cache no CI/CD: como desenhar keys e evitar cache invalido (GitHub e GitLab)](/cache-ci-cd-keys-invalidation-github-gitlab)\n\n### 3.1 Cache vs artifacts: nao misture\n\n- Cache: reuso de dependencias e diretorios que podem ser reconstruidos (ex.: cache do npm/pnpm, Gradle, pip).\n- Artifacts: saida do build que sera consumida por outro job (ex.: pasta `dist/`, binarios, relatorios).\n\nRegra pratica: se outro job precisa do arquivo \"como resultado\", use artifact. Se e so para acelerar repeticao, use cache.\n\n### 3.2 GitHub Actions: key e restore-keys (o basico que resolve 80%)\n\nUm bom cache key normalmente inclui:\n\n- SO e arquitetura\n- Hash do lockfile\n- Versao de runtime (quando necessario)\n\nExemplo para Node (cache de dependencias):\n\n```yaml\n- name: Cache npm\n uses: actions/cache@v4\n with:\n path: ~/.npm\n key: ${{ runner.os }}-${{ runner.arch }}-npm-${{ hashFiles('**/package-lock.json') }}\n restore-keys: |\n ${{ runner.os }}-${{ runner.arch }}-npm-\n```\n\nErros comuns:\n\n- Cachear diretorios \"grandes e instaveis\" (ex.: `node_modules`) sem criterio.\n- Esquecer arquitetura no key (quebra quando voce tem ARM e x64).\n- Incluir \"o commit\" no key (invalida toda vez e nao serve para nada).\n\n### 3.3 GitLab CI/CD: cache key e fallback_keys\n\nNo GitLab, voce pode usar `cache:key` e chaves de fallback para aproveitar cache mesmo em branches novas (quando faz sentido).\n\nExemplo:\n\n```yaml\ncache:\n key: \"node-${CI_RUNNER_EXECUTABLE_ARCH}-${CI_COMMIT_REF_SLUG}\"\n paths:\n - .npm/\n fallback_keys:\n - \"node-${CI_RUNNER_EXECUTABLE_ARCH}-main\"\n - \"node-${CI_RUNNER_EXECUTABLE_ARCH}-default\"\n```\n\nDicas:\n\n- Separe cache por arquitetura (`CI_RUNNER_EXECUTABLE_ARCH` ou variavel equivalente).\n- Use fallback para \"pegar o cache da main\" quando a branch e nova (bom para dependencias).\n- Evite fallback para outputs de build (isso e artifact, nao cache).\n\n## 4) Docker layer caching: quando o build \"come\" o pipeline\n\nSe seu pipeline faz `docker build` e demora muito, existem dois cenarios:\n\n1. Voce esta rebuildando camadas que poderiam ser reaproveitadas.\n2. Seu Dockerfile invalida cache cedo (ex.: copia o repo inteiro antes de instalar dependencias).\n\nLeitura complementar (satelite):\n\n- [Docker layer caching no CI: BuildKit, buildx, cache-from e cache-to](/docker-layer-caching-ci-buildkit-buildx)\n\n### 4.1 Primeiro: conserte o Dockerfile\n\nChecklist de ouro (multi-stage e cache friendly):\n\n- Copie primeiro apenas manifestos (ex.: `package.json`, `package-lock.json`).\n- Instale dependencias.\n- So depois copie o resto do codigo.\n- Separe build e runtime (multi-stage).\n\nExemplo (Node):\n\n```Dockerfile\nFROM node:20 AS build\nWORKDIR /app\n\nCOPY package*.json ./\nRUN npm ci\n\nCOPY . .\nRUN npm run build\n\nFROM nginx:alpine\nCOPY --from=build /app/dist /usr/share/nginx/html\n```\n\n### 4.2 Depois: use cache de layers no CI\n\nDuas estrategias comuns:\n\n- Registry cache (recomendado): o cache vai e volta via registry.\n- Cache local (bom para runner dedicado): o runner mantem camadas localmente.\n\nUm padrao simples e usar BuildKit/buildx com `--cache-from` e `--cache-to` apontando para o registry.\n\n## 5) ARM64 vs x64: por que isso quebra cache e (as vezes) o build\n\nArquitetura nao e detalhe.\n\nSe voce tem runners ARM64 e x64 rodando o mesmo pipeline, isso afeta:\n\n- Caches (dependencias nativas nao sao compativeis entre arquiteturas).\n- Docker images (precisam existir para a arquitetura ou usar emulacao, que e mais lenta).\n- Binarios pre-compilados (ex.: pacotes com addons nativos).\n\n\n\n### 5.1 Regras praticas para nao sofrer\n\n1. Inclua arquitetura no cache key.\n2. Tenha tags/labels explicitas por arquitetura.\n3. Se buildar Docker multi-arch, trate como pipeline separado (ou matrix com estrategia).\n\nExemplo (GitHub Actions com matrix de arch):\n\n```yaml\nstrategy:\n matrix:\n arch: [x64, arm64]\n\njobs:\n build:\n runs-on: ${{ matrix.arch == 'arm64' && 'ubuntu-22.04-arm' || 'ubuntu-22.04' }}\n steps:\n - uses: actions/checkout@v4\n - run: ./ci/build.sh\n```\n\nExemplo (GitLab com tags por arch):\n\n```yaml\nbuild_amd64:\n tags: [linux-x64, docker]\n script: [\"./ci/build.sh\"]\n\nbuild_arm64:\n tags: [linux-arm64, docker]\n script: [\"./ci/build.sh\"]\n```\n\n## 6) macOS runners: quando voce precisa e como evitar armadilhas\n\nmacOS runner normalmente entra por necessidade:\n\n- build iOS/macOS (Xcode)\n- codesign/notarization\n- testes especificos de macOS\n\nLeitura complementar (satelite):\n\n- [Runners macOS no CI: Intel vs Apple Silicon, custos e armadilhas](/runner-macos-ci-intel-apple-silicon)\n\n### 6.1 Dicas rapidas\n\n- Evite rodar jobs \"genericos\" no macOS: reserve para o que realmente precisa.\n- Prefira runner dedicado para macOS (custo alto por hora e fila doi).\n- Cacheie com cuidado (Xcode DerivedData pode ajudar, mas tambem pode contaminar se for compartilhado sem estrategia).\n\n## Checklist final: plano de 1 dia para acelerar seu CI/CD\n\n- [ ] Medir fila vs execucao em 5 a 10 execucoes.\n- [ ] Definir \"classes\" de jobs (leve, pesado, macOS, Docker build).\n- [ ] Criar tags/labels claras e remover runner \"lixeira\" que aceita tudo.\n- [ ] Separar cache por arquitetura (ARM64/x64) e por lockfile hash.\n- [ ] Ajustar Dockerfile para nao invalidar cache cedo.\n- [ ] Ativar Docker layer caching (registry cache ou cache local em runner dedicado).\n- [ ] Documentar: \"qual job roda em qual runner e por que\" (evita regressao).\n\n| Controle | \nPara que serve | \nOnde costuma morar no produto | \n
|---|---|---|
| \n \n \n ![\"\"](\"/assets/img/felca-controle-classificacao-etaria.png\") \n Classificacao etaria \n | \n Define a faixa etaria adequada do conteudo, recurso ou servico | \nCatalogo, onboarding, paginas de produto, termos, loja | \n
| \n \n \n ![\"\"](\"/assets/img/felca-controle-verificacao-idade.png\") \n Afericao ou verificacao de idade \n | \n Define se o usuario pode acessar determinado conteudo, recurso ou jornada | \nCadastro, login, desbloqueio de conteudo, compra, API de sinal de idade | \n
| \n \n \n ![\"\"](\"/assets/img/felca-controle-consentimento-responsavel.png\") \n Consentimento ou autorizacao do responsavel \n | \n Autoriza atos especificos de menor impacto progressivo ou exigidos por lei | \nDownload, criacao de conta, ativacao de recursos, compras | \n
| \n \n \n ![\"\"](\"/assets/img/felca-controle-supervisao-parental.png\") \n Supervisao parental \n | \n Da ao responsavel meios continuos de acompanhar, limitar e configurar o uso | \nPainel do responsavel, device controls, conta vinculada, controles in-app | \n
\n
\n\nPosso usar minha assinatura do ChatGPT ou Claude dentro do Cursor nativo?
\n\nNao. No Cursor nativo, voce usa plano do proprio Cursor ou uma API key separada. \nNo caso da OpenAI, o ChatGPT e a API sao plataformas de cobranca separadas. \nNo caso da Anthropic, os planos pagos do Claude e o Console/API tambem sao cobrados separadamente.\n\nA excecao pratica e outra: voce pode usar a **extensao oficial do Codex dentro do Cursor** e entrar com sua conta do ChatGPT.\n\n
\n\nO Codex faz evidencia em video como o Cursor?
\n\nNo fluxo publico documentado hoje, nao do mesmo jeito. \nO Cursor documenta PRs com videos, screenshots e logs via Cloud Agents. \nO Codex documenta review em GitHub via@codex review e fluxos de cloud task/review, mas nao com a mesma enfase em artefatos visuais prontos para revisao.\n\n
\n\n---\n\n## Checklist para decidir sem cair no marketing\n\n- [ ] Meu time precisa de **multi-model** ou um unico provedor basta?\n- [ ] O ganho vira do **editor e do fluxo de revisao**, ou so de acesso ao modelo?\n- [ ] Vamos usar **Cloud Agents**, **automacoes** e **MCP**, ou isso e so \"efeito demo\"?\n- [ ] Precisamos de **SSO, analytics, billing centralizado e controles de time**?\n- [ ] O gargalo e produtividade real ou apenas **custo por token**?\n- [ ] Ja temos uma politica clara de **quem pode usar Max Mode**, agentes paralelos e modelos premium?\n- [ ] Faz mais sentido comecar por **Codex**, **Claude Code** ou **Copilot** antes de subir para Cursor?\n\nSe eu for direto na OpenAI ou Anthropic, sempre economizo?
\n\nTambem nao. \nVoce quase sempre simplifica a conta de inferencia, mas perde a camada de produto do Cursor. \nAlem disso, nos planos individuais do Cursor, parte do uso ja vem incluida, o que em alguns perfis reduz ou compensa parte do diferencial.\nRua Rodrigo Vieira, 126
Jardim Vila Mariana. São Paulo, SP.
CEP: 04115-060
","footer.sections.letsTalk.phone":"11 5083-0122","footer.sections.letsTalk.title":"Vamos conversar?","footer.sections.siteMap":"Mapa do site","footer.privacyPolicy":"Termos de privacidade","footer.termsOfService":"Termos de serviço","footer.XAppsIsAnITProvider":"A X-Apps é um provedor de TI parceiro e aconselhada pelo","footer.yourITTeam":"O seu time de TI. Desenvolvimento de software sob demanda e alocação de profissionais.","footer.newsletter":"Receba nossos e-mails","footer.submitLabel":"Inscrever","footer.emailPlaceholder":"Qual seu melhor e-mail?","footer.socialMediaTitle":"Siga nossas redes sociais","footer.switchSites":"Available in English","home.develop.developFor":"Desenvolvemos para","home.develop.lookThisCase":"Veja o case","home.midia.midia":"Reportagens","home.testimony.title":"Depoimentos","home.whoWeDevelop.designAndSoftwareDeveloper":"Design e desenvolvimento de Software","home.whoWeDevelop.whoWeDevelop":"Nossos Clientes","header.hero.subtitle":"Somos um time de tecnologia pronto para acelerar sua empresa","header.hero.title":"Desenvolvemos ideias em software de alta qualidade.","header.buttons.hire":"Contrate","header.buttons.hireProject":"Contratar Projeto","header.buttons.hireSquad":"Montar Squad","header.buttons.hireSquad2":"Alocar profissionais","header.buttons.requestBudget":"Solicitar Orçamento","header.buttons.receiveEstimation":"Receber estimativa","header.changeLocale":"Available in English","language.en":"Inglês","language.pt-BR":"Português","midia.hero.subtitle":"Veja onde a X-Apps já esteve presente","midia.hero.title":"Na Mídia","midia.seeMore":"Veja mais","pagination.nextPage":"próxima página","pagination.pageIndicator":"{currentPage} de {total}","pagination.previousPage":"página anterior","portfolio.hero.subtitle":"Design e desenvolvimento de software","portfolio.hero.title":"Pra quem nós desenvolvemos","post.similarPosts":"Posts semelhantes","post.readingMinutes":"{timeToRead} {timeToRead, plural, =0 {minutos} =1 {minuto} other {minutos}} de leitura","services.customMade.customMadeOnDemand":"Sob Medida, Sob demanda","services.hero.subtitle":"Saiba como nossos processos funcionam e as vantagens competitivas que oferecemos para seu negócio.","services.hero.title":"Seu projeto sob demanda","services.howWeWork.dedicatedTeams":"Equipes Dedicadas","services.howWeWork.deliveryCycle":"Alta eficiência","services.howWeWork.deliveryWeekly":"Alto desempenho","services.howWeWork.fullTimeTeams":"Times com atuação dedicada ou compartilhada com as competências que sua empresa precisa.","services.howWeWork.howWeWork":"Como Trabalhamos","services.howWeWork.ourTechnologyTeam":"Nosso time de tecnologia é capaz de entregar com alta qualidade e rapidez porque utilizamos metodologias ágeis de desenvolvimento em nossos softwares.","services.howWeWork.weCarryOutWeeklyDeliveries":"Tecnologias avançadas para oferecer soluções de escaláveis e com qualidade.","services.howWeWork.withReportHoursUsed":"Processos com o melhor custo-benefício para desenvolvimento e manutenção de software.","services.methodology.cardOptions.agileDevelopment":"Desenvolvimento Ágil","services.methodology.cardOptions.cascadeDevelopment":"Desenvolvimento em Cascata","services.methodology.cardOptions.inContrastToCascadingDevelopment":"Em contrapartida ao desenvolvimento em cascata, o desenvolvimento ágil se baseia em ciclos curtos no qual acontece colaboração constante entre as partes. Ao final de cada ciclo uma nova funcionalidade é mostrada. Este modelo consegue alinhar melhor as expectativas de todos, pois a colaboração constante entre todos os participantes acarreta em um resultado satisfatório. A X-Apps utiliza o modelo ágil, sempre.","services.methodology.cardOptions.longCycleDevelopmentModel":"Modelo de desenvolvimento em ciclos longos, no qual uma etapa está condicionada ao fim da anterior. No caso do produto final não estar de acordo com o esperado, o processo é reiniciado desde sua etapa inicial. Este processo, ainda em uso em muitos projetos, gera demora, e muitas vezes um resultado que não gera o valor esperado por quem contrata o desenvolvimento.","services.methodology.methodology":"Metodologia","services.technology.checkOutSomeTechnologiesWeServe":"Confira algumas das tecnologias que atendemos.","services.technology.technology":"Tecnologias","obrigado.sendInformation.heading":"Quer enviar as informações do seu projeto com antecedência?","obrigado.sendInformation.description":"Criamos um questionário para você agilizar seu atendimento.Ele é rápido, leva menos de 5 minutos, e vai nos ajudar a montar a melhor estratégia para seu produto","obrigado.sendInformation.buttonSend":"Sim, quero enviar agora","obrigado.sendInformation.buttonSkip":"Não, prefiro enviar depois","obrigado.newsletter.heading":"Tudo bem. Antes de finalizar:
Deseja assinar nossa Newsletter?","obrigado.newsletter.description":"Receba os melhores conteúdos sobre design e desenvolvimento de apps.
Dicas, tendências do mercado e materiais exclusivos. Prometemos não enviar SPAM.","obrigado.newsletter.buttonSend":"Sim, quero assinar","obrigado.newsletter.buttonSkip":"Não quero assinar","obrigado.end.heading":"Muito Obrigado, {name}!","obrigado.end.description1":"Em alguns minutos, vamos enviar um e-mail para o endereço de {email}
para explicar os próximos passos do seu atendimento","obrigado.end.description2":"Recebemos as informações do seu projeto e agora vamos começar nossa análise.
Não se preocupe, vamos entrar em contato com você em poucos dias para continuar com seu atendimento.","obrigado.end.buttonSend":"Voltar para a home","cards.agileProjects":"Projetos ágeis","cards.agileProjectsDescription":"Realize sua ideia de produto de software","cards.devops":"Operação Devops","cards.devopsDescription":"Lance evoluções com suporte contínuo","cards.developerOnDemand":"Desenvolvedores sob demanda","cards.developerOnDemandDescription":"Receba nossos profissionais em sua equipe","loading":"Carregando","seeTheCase":"Veja o case","newVersionAvailable":"Nova versão disponível, clique aqui para atualizar","newsletter.title":"Inscreva-se em nossa newsletter","newsletter.submitLabel":"Inscrever","newsletter.emailPlaceholder":"Qual o seu melhor e-mail","newsletter.namePlaceholder":"Digite seu nome","newsletter.successfulSubscribed":"Inscrição feita com sucesso","newsletter.sendButton":"Enviar","exitIntentPopup.formFirstName":"Nome","exitIntentPopup.formLastName":"Sobrenome","exitIntentPopup.formEmail":"E-mail","exitIntentPopup.formTelefone":"Telefone","exitIntentPopup.title":"Ligamos para você","exitIntentPopup.subtitle":"Converse com a equipe para saber como desenvolver aplicativos melhores e mais rápidos.","exitIntentPopup.description":"Preencha seus dados para entrarmos em contato.","exitIntentPopup.seeMoreButton":"Saiba como","exitIntentPopup.SubmitForm":"Solicitar contato","landingPagePopup.title":"Ainda está com dúvidas?","landingPagePopup.description":"Baixe nosso e-book e saiba tudo sobre o desenvolvimento de sistemas e apps.","landingPagePopup.subDescription":"• App x Web: qual o melhor?
• Quanto custa criar um app
• Como funciona a metologia ágil","landingPagePopup.submitButton":"Baixe o e-Book agora","whatWeHaveDevelopedFor":"O que desenvolvemos para {company}","pageNotFound":"Página não encontrada","share":"Compartilhar","testimoniesSlider.firstLine":"Com a palavra, nossos clientes","testimoniesSlider.title":"Os maiores players
do mercado","gartnerAdvised.title":"X-Apps é aconselhada pelo líder mundial em Consultoria e Pesquisa em TI.","gartnerAdvised.subtitle":"Nosso outsourcing de TI conta com um padrão internacional de qualidade.","gartnerAdvised.buttonLabel":"Quero conversar com a X-Apps","legalDisclaimer":"Todos os direitos reservados","footerTitle":"Ainda está com dúvidas?","footerDescription":"Baixe nosso e-Book e saiba tudo sobre o desenvolvimento de sistemas e apps.","footerButton":"Baixe nosso e-Book agora","onboardingSlider.title":"COMO FUNCIONA","onboardingSlider.subtitle":"**Contrate** seu **time** de desenvolvedores em **poucos minutos**","cardsTitle":"A **burocracia,** deixa com a **gente:**","carrousel.title":"Sabe quem confia na X-Apps?","carrousel.subtitle":"As maiores empresas do Brasile do mundo","carrousel.logoTitle":"Quem disse isso:","functionalities.title":"FUNCIONALIDADES","functionalities.subtitle":"Quando você contrata com a **X-Apps,** a gente te oferece **bem mais** que um time de **tecnologia:**"},"routed":false,"originalPath":"/blog/page/15/","redirect":false,"defaultLanguage":"pt-BR"}}},"staticQueryHashes":["2958395934"]}