DEV Community: Vinícius Carregosa

Mock Server na prática: entendendo JSON Server e o db.json

Vinícius Carregosa — Mon, 21 Sep 2026 19:31:09 +0000

Um guia para iniciantes entenderem o que é um Mock Server, como o JSON Server funciona e como utilizar um db.json para desenvolver e testar aplicações frontend.

Introdução

Quando estamos desenvolvendo uma aplicação frontend, existe um problema muito comum: a interface precisa consumir uma API, mas o backend ainda não está pronto.

Imagine que você está construindo uma tela de gerenciamento de membros. O frontend já possui componentes, formulários e regras de interface, mas a API responsável por fornecer e salvar os dados ainda está em desenvolvimento.

Precisamos de uma forma de continuar trabalhando sem esperar o backend ficar pronto.

É aí que entra o Mock Server.

Neste artigo, vamos entender o conceito desde o início e, principalmente, mostrar como utilizar o JSON Server com um arquivo db.json para simular uma API REST.

1. O problema entre frontend e backend

Em uma aplicação real, o frontend normalmente conversa com uma API para obter e modificar dados.

Por exemplo, quando uma tela precisa listar membros, ela pode realizar uma requisição:

GET /members

O backend processaria essa requisição e devolveria algo semelhante a:

[
  {
    "id": 1,
    "email": "ana@exemplo.com",
    "role": "Admin"
  },
  {
    "id": 2,
    "email": "carlos@exemplo.com",
    "role": "Viewer"
  }
]

O problema aparece quando o frontend está pronto para consumir essa API, mas o backend ainda está sendo desenvolvido.

Nesse cenário, esperar pelo backend pode atrasar o desenvolvimento.

Uma alternativa é criar uma API simulada.

2. O que é um Mock Server?

Um Mock Server é um servidor utilizado para simular o comportamento de uma API.

Ele recebe requisições HTTP e devolve respostas utilizando dados ou comportamentos definidos para o ambiente de desenvolvimento.

Em vez de:

Frontend → API real

podemos trabalhar temporariamente com:

Frontend → Mock Server

Para o frontend, a comunicação continua acontecendo por HTTP.

A diferença é que o servidor utilizado durante o desenvolvimento não representa necessariamente a implementação definitiva do sistema.

Mock Server não é o backend real. É uma simulação da API utilizada para permitir desenvolvimento, testes e prototipação.

3. Uma analogia simples

Imagine que uma equipe esteja construindo um aeroporto.

A equipe responsável pelos sistemas do terminal precisa testar os painéis de voo, balcões e sistemas de atendimento, mas o aeroporto ainda não está operacional.

Em vez de esperar toda a infraestrutura ficar pronta, pode-se criar um ambiente simulado com informações semelhantes às reais.

Os sistemas conseguem testar:

chegada de informações;
consulta de dados;
atualização;
comunicação;
tratamento de respostas.

Esse ambiente não é o aeroporto definitivo, mas permite que uma parte significativa do trabalho continue.

Um Mock Server funciona de maneira semelhante.

Ele cria um ambiente controlado para que o frontend consiga trabalhar antes da existência da API definitiva.

4. Mock Data não é Mock Server

Os conceitos estão relacionados, mas não são iguais.

Mock Data

São dados fictícios utilizados durante o desenvolvimento.

Por exemplo:

{
  "id": 1,
  "email": "ana@exemplo.com",
  "role": "Admin"
}

Isso é apenas um dado.

Mock Server

É um servidor capaz de disponibilizar esses dados através de uma API.

Por exemplo:

GET http://localhost:3002/members

Agora existe uma aplicação capaz de receber uma requisição HTTP e devolver uma resposta.

Conceito	Função
Mock Data	Representa dados fictícios
Mock Server	Disponibiliza esses dados através de uma API simulada

5. O que é o JSON Server?

O JSON Server é uma ferramenta que permite transformar um arquivo JSON em uma API REST simples.

A ideia é bastante interessante para quem está começando:

Você cria uma estrutura JSON e o JSON Server disponibiliza seus recursos através de endpoints HTTP.

Ele permite simular operações comuns de uma API, como:

GET
POST
PUT
PATCH
DELETE

Isso possibilita desenvolver e testar um frontend sem precisar construir imediatamente uma API completa.

6. O `db.json`

No contexto do Member Manager, utilizamos um arquivo chamado:

db.json

Sua estrutura é semelhante a:

{
  "members": [
    {
      "id": 1,
      "projectId": 1,
      "email": "ana@exemplo.com",
      "role": "Admin"
    },
    {
      "id": 2,
      "projectId": 1,
      "email": "carlos@exemplo.com",
      "role": "Viewer"
    },
    {
      "id": 3,
      "projectId": 2,
      "email": "bia@exemplo.com",
      "role": "Operator"
    }
  ]
}

À primeira vista, parece apenas um arquivo JSON comum.

E realmente é.

A diferença é que o JSON Server utiliza essa estrutura para disponibilizar uma API.

7. Entendendo a estrutura do `db.json`

O primeiro nível do arquivo possui:

{
  "members": []
}

A propriedade:

members

representa uma coleção de recursos.

Podemos pensar nela como uma pequena coleção de membros.

Cada elemento possui suas próprias propriedades:

{
  "id": 1,
  "projectId": 1,
  "email": "ana@exemplo.com",
  "role": "Admin"
}

Vamos entender cada uma delas.

`id`

O id identifica aquele membro.

"id": 1

Isso permite acessar um recurso específico:

GET /members/1

O identificador também é utilizado nas operações de atualização e remoção.

`projectId`

O projectId representa o projeto ao qual o membro está associado.

No nosso exemplo:

"projectId": 1

Ana e Carlos pertencem ao projeto 1.

Bia pertence ao projeto 2:

"projectId": 2

Isso permite simular uma relação entre projetos e membros.

Por exemplo:

GET /members?projectId=1

pode ser utilizado para consultar os membros relacionados ao projeto 1.

Essa estrutura foi utilizada no Mock Server do Member Manager para permitir que o frontend consultasse membros por projeto.

`email`

Representa o email do membro:

"email": "ana@exemplo.com"

É uma informação pertencente à entidade Member.

`role`

Representa a função do membro dentro do projeto.

No nosso exemplo:

Admin
Operator
Viewer

podem representar diferentes papéis dentro da aplicação.

É importante perceber que o Mock Server está apenas fornecendo esses dados.

Ele não está necessariamente implementando toda a lógica de autorização de uma aplicação real.

8. Como o JSON Server transforma o arquivo em uma API?

Essa é uma das partes mais importantes para entender.

Temos:

db.json

contendo:

{
  "members": [...]
}

Quando o JSON Server é iniciado, ele utiliza essa coleção para disponibilizar recursos HTTP.

No exemplo utilizado no projeto:

npm install -g json-server

Depois:

json-server --watch db.json --port 3002

O recurso members passa a estar disponível em:

http://localhost:3002/members

Agora o frontend pode tratar essa URL como uma API.

9. O endpoint `/members`

Depois de iniciar o servidor:

GET http://localhost:3002/members

podemos receber:

[
  {
    "id": 1,
    "projectId": 1,
    "email": "ana@exemplo.com",
    "role": "Admin"
  },
  {
    "id": 2,
    "projectId": 1,
    "email": "carlos@exemplo.com",
    "role": "Viewer"
  },
  {
    "id": 3,
    "projectId": 2,
    "email": "bia@exemplo.com",
    "role": "Operator"
  }
]

Perceba que não criamos manualmente uma rota chamada /members.

O JSON Server identificou a coleção:

members

e disponibilizou o recurso.

10. Filtrando por `projectId`

Agora podemos utilizar o projectId para consultar somente os membros de determinado projeto.

Por exemplo:

GET /members?projectId=1

A resposta será semelhante a:

[
  {
    "id": 1,
    "projectId": 1,
    "email": "ana@exemplo.com",
    "role": "Admin"
  },
  {
    "id": 2,
    "projectId": 1,
    "email": "carlos@exemplo.com",
    "role": "Viewer"
  }
]

Para o projeto 2:

GET /members?projectId=2

podemos obter:

[
  {
    "id": 3,
    "projectId": 2,
    "email": "bia@exemplo.com",
    "role": "Operator"
  }
]

Isso torna o Mock Server mais interessante para desenvolvimento porque conseguimos testar situações próximas das que existirão na aplicação real.

11. GET: lendo dados

O método GET é utilizado para consultar informações.

Listar todos os membros

GET /members

Buscar um membro específico

GET /members/1

Buscar membros de um projeto

GET /members?projectId=1

O Angular pode utilizar essas respostas para construir a interface.

12. POST: criando um membro

O POST normalmente é utilizado para criar um novo recurso.

Podemos enviar:

POST /members

com:

{
  "projectId": 1,
  "email": "joao@exemplo.com",
  "role": "Viewer"
}

O JSON Server adicionará o novo membro à coleção.

Isso permite testar o fluxo de cadastro antes de existir um backend definitivo.

13. PUT: atualizando um membro

Imagine que Carlos atualmente seja:

{
  "id": 2,
  "projectId": 1,
  "email": "carlos@exemplo.com",
  "role": "Viewer"
}

Queremos alterar sua função para Admin.

Podemos fazer:

PUT /members/2

enviando:

{
  "id": 2,
  "projectId": 1,
  "email": "carlos@exemplo.com",
  "role": "Admin"
}

O recurso correspondente será atualizado.

14. DELETE: removendo um membro

Para remover Carlos:

DELETE /members/2

O registro com id = 2 será removido da coleção.

Com isso, conseguimos simular um CRUD completo:

Operação	HTTP	Endpoint
Criar	`POST`	`/members`
Listar	`GET`	`/members`
Buscar	`GET`	`/members/:id`
Atualizar	`PUT`	`/members/:id`
Remover	`DELETE`	`/members/:id`

15. Onde entra o Angular?

Agora podemos conectar o Mock Server ao frontend.

Uma boa prática é evitar que cada componente faça suas próprias requisições HTTP.

Em vez disso, podemos utilizar um service.

A comunicação pode ser entendida assim:

Component
    |
    | chama
    v
MemberService
    |
    | HTTP
    v
JSON Server
    |
    | lê/escreve
    v
db.json

O componente cuida principalmente da interface.

O service concentra o acesso aos dados.

16. O `MemberService`

Um exemplo simplificado seria:

@Injectable({
  providedIn: 'root'
})
export class MemberService {

  private api = 'http://localhost:3002/members';

  constructor(private http: HttpClient) {}

  getByProject(projectId: number) {
    return this.http.get<Member[]>(
      `${this.api}?projectId=${projectId}`
    );
  }

  add(member: Omit<Member, 'id'>) {
    return this.http.post<Member>(
      this.api,
      member
    );
  }

  update(member: Member) {
    return this.http.put<Member>(
      `${this.api}/${member.id}`,
      member
    );
  }

  remove(id: number) {
    return this.http.delete(
      `${this.api}/${id}`
    );
  }
}

O mais importante não é decorar esse código.

É entender a responsabilidade do service.

O componente não precisa saber como a URL foi construída.

Ele pode simplesmente solicitar ao service:

"Busque os membros deste projeto."

O service transforma essa solicitação em uma requisição HTTP.

17. Por que separar o componente do service?

Imagine que hoje nossa API seja:

http://localhost:3002/members

Mais tarde, o backend real pode disponibilizar:

https://api.exemplo.com/members

Se os componentes construírem as URLs diretamente, teremos que procurar e alterar diversos pontos da aplicação.

Quando o acesso fica concentrado no service, a mudança fica muito mais controlada.

Essa separação também ajuda a manter responsabilidades claras:

Responsabilidade	Componente	Service
Interface	✓
Interação do usuário	✓
Requisições HTTP		✓
URL da API		✓
Conversão de dados		✓
Regras de apresentação	✓

18. Mock Server não é backend

Esse é um dos pontos mais importantes.

JSON Server é muito útil para:

desenvolvimento frontend;
prototipação;
testes;
demonstrações;
desenvolvimento paralelo;
criação de interfaces antes do backend.

Mas ele não deve ser confundido com uma API de produção.

Um backend real pode possuir:

autenticação;
autorização;
regras de negócio;
validações;
banco de dados;
tratamento de erros;
logs;
segurança;
transações;
controle de concorrência.

O Mock Server normalmente fornece apenas uma representação simplificada da API necessária para o desenvolvimento.

Mock Server permite que o desenvolvimento avance. Ele não substitui automaticamente a arquitetura definitiva do backend.

19. Testando o Mock Server diretamente

Uma das melhores formas de entender uma API é testá-la sem passar pelo frontend.

Depois de iniciar:

json-server --watch db.json --port 3002

podemos utilizar ferramentas como:

Postman;
Bruno;
Insomnia;
curl;
navegador, para requisições GET.

Por exemplo:

curl http://localhost:3002/members

Para testar o filtro:

curl "http://localhost:3002/members?projectId=1"

Para consultar um membro:

curl http://localhost:3002/members/1

Isso também ajuda no diagnóstico.

Se o endpoint não responde diretamente pelo Postman ou curl, provavelmente o problema está no Mock Server ou na configuração da API simulada, e não no Angular.

20. Um ponto importante sobre versões

É importante prestar atenção à versão do JSON Server utilizada.

A versão atual disponível no npm possui diferenças em relação a versões antigas, inclusive em alguns comportamentos relacionados a id e consultas.

Por isso, em projetos de equipe, é uma boa prática registrar a versão da ferramenta utilizada.

Em vez de cada desenvolvedor instalar uma versão diferente globalmente, podemos declarar a dependência no projeto.

Por exemplo:

npm install --save-dev json-server

Assim, a dependência passa a fazer parte do projeto e pode ser instalada junto com as demais:

npm install

Isso reduz o risco de:

"Na minha máquina funciona."

21. Como pensar sobre Mock Server

Evite pensar:

"Tenho um JSON falso."

É melhor pensar:

"Tenho uma API simulada que permite desenvolver e testar o consumidor antes de possuir o backend definitivo."

Essa diferença de perspectiva é importante.

O arquivo:

db.json

é a fonte dos dados.

O JSON Server fornece o comportamento de servidor HTTP.

O Angular consome essa API.

O MemberService encapsula essa comunicação.

22. O fluxo completo

Podemos representar o funcionamento completo de forma simples:

Usuário
   |
   v
Angular Component
   |
   v
MemberService
   |
   v
HTTP Request
   |
   v
JSON Server
   |
   v
db.json

Quando uma alteração acontece, o caminho inverso ocorre:

db.json
   |
   v
JSON Server
   |
   v
HTTP Response
   |
   v
MemberService
   |
   v
Angular Component
   |
   v
Interface

O ponto importante é que cada camada possui uma responsabilidade.

23. Exercício prático

Uma boa forma de fixar o conteúdo é modificar o próprio db.json.

Adicione:

{
  "id": 4,
  "projectId": 2,
  "email": "lucas@exemplo.com",
  "role": "Viewer"
}

Depois consulte:

GET /members?projectId=2

Observe quais membros aparecem.

Depois tente realizar as quatro operações:

Criar

POST /members

Consultar

GET /members

Atualizar

PUT /members/4

Remover

DELETE /members/4

Depois tente explicar o que acontece em cada etapa.

Se você consegue explicar o caminho entre Angular → Service → HTTP → Mock Server → dados, o conceito já está sendo compreendido, e não apenas decorado.

24. Erros comuns de iniciantes

Pensar que o `db.json` é a API

Não é.

O JSON é apenas a fonte de dados utilizada pelo Mock Server.

Colocar toda a lógica HTTP no componente

Isso mistura responsabilidades.

É preferível centralizar o acesso aos dados em um service.

Tratar Mock Server como backend definitivo

O Mock Server existe para simular.

Ele não necessariamente representa todas as regras e comportamentos do backend de produção.

Não testar a API isoladamente

Quando existe um problema no frontend, testar primeiro o endpoint diretamente pode economizar bastante tempo.

Não controlar a versão da ferramenta

Projetos de equipe devem buscar um ambiente reproduzível.

Se cada desenvolvedor utilizar uma versão diferente do JSON Server, o comportamento pode variar.

25. O que aprendemos?

Ao final deste processo, temos vários conceitos importantes:

Mock Data são dados simulados.

Mock Server é um servidor utilizado para simular uma API.

JSON Server transforma uma estrutura JSON em uma API REST simples.

db.json contém os dados utilizados pelo Mock Server.

HTTP é o mecanismo utilizado para comunicação entre cliente e servidor.

MemberService encapsula o acesso à API.

Angular utiliza HttpClient para consumir os endpoints.

A ideia pode ser resumida assim:

Dados simulados
      |
      v
JSON Server
      |
      v
API HTTP
      |
      v
MemberService
      |
      v
Angular

Essa estrutura é simples o suficiente para começar, mas já apresenta conceitos fundamentais que serão encontrados em APIs reais.

26. O que acontece quando o backend real chegar?

Essa é uma das perguntas mais importantes.

No início do desenvolvimento podemos ter:

private api = 'http://localhost:3002/members';

Depois, quando o backend real estiver disponível:

private api = 'https://api.exemplo.com/members';

Idealmente, o componente não precisa saber que essa mudança aconteceu.

Ele continua utilizando:

memberService.getByProject(...)

O service continua responsável pela comunicação.

O que muda é o sistema que responde à requisição.

Essa é uma das vantagens de manter uma separação clara entre a interface e o acesso aos dados.

Conclusão

Um Mock Server resolve um problema bastante comum:

Como continuar desenvolvendo o frontend enquanto o backend ainda não está pronto?

No nosso exemplo, o db.json contém os dados simulados dos membros.

O JSON Server transforma essa estrutura em uma API HTTP.

O Angular consome essa API através do MemberService.

Assim conseguimos implementar e testar operações de:

criação;
consulta;
atualização;
remoção;
filtragem.

O mais importante é não pensar no Mock Server simplesmente como "um JSON falso".

Pense nele como uma API simulada criada para fornecer um contrato previsível ao frontend durante o desenvolvimento.

Quando o backend real estiver disponível, a simulação pode ser substituída pela implementação definitiva.

Mock Server não tenta substituir o backend. Ele permite que o restante da aplicação avance enquanto o backend ainda está sendo construído.

Referências

CI/CD para iniciantes: entendendo pipelines com GitLab, testes e Docker

Vinícius Carregosa — Mon, 21 Sep 2026 19:24:03 +0000

Se você está começando a estudar desenvolvimento de software, provavelmente já encontrou termos como CI/CD, pipeline, GitLab Runner, build, artifacts, Docker e deploy. O problema é que, quando esses conceitos aparecem todos juntos, é fácil decorar comandos sem realmente entender o que está acontecendo.

Neste artigo, vamos construir esse entendimento do zero.

A ideia é usar uma situação simples como analogia e, a partir dela, transformar o conceito em uma implementação real usando GitLab. O objetivo não é criar a pipeline mais sofisticada possível, mas entender os fundamentos necessários para conseguir ler, escrever, modificar e solucionar problemas em uma pipeline de CI/CD.

No final, você terá uma visão de como uma alteração de código pode ser automaticamente construída, testada e transformada em uma imagem Docker.

Antes de falar de CI/CD, imagine uma fábrica

Imagine uma fábrica que produz computadores.

Um funcionário monta as peças. Outro verifica se o computador liga. Outro realiza testes mais específicos. Depois, o produto é embalado e armazenado para distribuição.

Seria estranho colocar um computador recém-montado diretamente na caixa sem verificar se ele funciona.

Seria ainda mais estranho descobrir um defeito depois que centenas de unidades já foram distribuídas.

No desenvolvimento de software, o problema é parecido.

Uma pessoa escreve código, outra altera uma funcionalidade existente, outra modifica uma configuração. Em algum momento, essas alterações precisam ser integradas. A grande pergunta é: como saber rapidamente se aquilo que foi produzido continua funcionando?

É exatamente aí que entra a Integração Contínua.

1. O que significa Continuous Integration?

Continuous Integration (CI), ou Integração Contínua, é uma prática de desenvolvimento em que as alterações de código são integradas frequentemente e submetidas a verificações automatizadas.

Na prática, isso pode significar que, quando um desenvolvedor envia uma alteração para o GitLab, o sistema automaticamente executa tarefas como:

Instalar dependências
Executar build
Executar testes

Se tudo funcionar, a alteração passa pelas verificações.

Se alguma etapa falhar, a equipe descobre o problema rapidamente.

Martin Fowler descreve Continuous Integration como a integração frequente das alterações em uma base compartilhada, acompanhada de um build automatizado que inclui testes para detectar problemas de integração rapidamente.

A Red Hat também descreve CI como a integração automática e frequente de mudanças em um repositório compartilhado.

A ideia mais importante aqui é simples:

CI não existe para "deixar o projeto moderno". Ela existe para detectar problemas cedo.

2. E o que significa CD?

O termo CD pode representar duas ideias diferentes: Continuous Delivery e Continuous Deployment.

No Continuous Delivery, o software passa por um processo automatizado de construção e validação e fica preparado para ser entregue. A implantação final ainda pode depender de uma decisão ou ação manual.

No Continuous Deployment, a implantação também é automatizada.

Uma maneira simples de diferenciar:

Continuous Integration

Código
Build
Testes

Continuous Delivery

Código
Build
Testes
Artefato pronto para entrega

Continuous Deployment

Código
Build
Testes
Deploy automático

Esses conceitos fazem parte de uma mesma ideia de automação, mas não precisam ser implementados todos de uma vez. Para quem está começando, entender CI primeiro costuma ser muito mais importante do que tentar automatizar todo o processo de implantação logo no início.

3. A pipeline é a linha de produção

Agora podemos voltar à nossa fábrica.

A pipeline é a linha de produção completa.

Ela representa o conjunto de etapas que o software precisa atravessar para chegar ao resultado desejado.

No GitLab, pipelines são configuradas normalmente em um arquivo chamado .gitlab-ci.yml. Elas podem ser disparadas por diferentes eventos, como commits, Merge Requests ou execução manual.

Um exemplo simples de pipeline seria:

Build → Testes → Empacotamento

Não precisamos interpretar isso como uma lista de comandos. Pense na pipeline como uma sequência de responsabilidades.

Primeiro perguntamos:

"O sistema consegue ser construído?"

Depois:

"O sistema está se comportando como esperado?"

E, por fim:

"Conseguimos preparar esse resultado para ser distribuído?"

Essa forma de pensar ajuda muito mais do que simplesmente decorar sintaxe YAML.

4. Pipeline, Stage e Job

Agora aparecem três palavras que todo iniciante precisa entender.

Uma pipeline é o processo completo.

Um stage é uma etapa lógica desse processo.

Um job é uma tarefa executada dentro de um stage.

Podemos imaginar uma estrutura como esta:

Pipeline
├── Build
│   └── build-app
├── Test
│   ├── unit-tests
│   └── lint
└── Docker
    └── build-image

O GitLab executa os stages na ordem definida. Dentro de um mesmo stage, jobs podem ser executados em paralelo quando houver runners disponíveis.

Essa diferença é importante porque uma pipeline pode possuir dezenas de jobs sem necessariamente possuir dezenas de stages.

5. Quem executa os jobs?

A essa altura surge outra pergunta.

Quem realmente executa os comandos?

O GitLab Runner.

O GitLab gerencia a pipeline, mas os jobs precisam ser executados por um agente capaz de fornecer um ambiente de execução.

O Runner recebe o job, executa os comandos definidos e devolve o resultado ao GitLab.

Se tivermos:

script:
  - npm ci
  - npm test

o Runner será responsável por executar esses comandos.

Essa distinção resolve uma dúvida comum: GitLab e GitLab Runner não são exatamente a mesma coisa.

O GitLab organiza e gerencia o processo. O Runner executa o trabalho.

6. Criando a primeira pipeline

A melhor maneira de aprender é começar pequeno.

Crie um arquivo chamado:

.gitlab-ci.yml

e coloque:

stages:
  - build
  - test

build:
  stage: build
  script:
    - echo "Executando build"

test:
  stage: test
  script:
    - echo "Executando testes"

Nesse momento, não estamos construindo uma aplicação real.

Estamos apenas testando nossa infraestrutura.

Se o GitLab conseguir executar esses dois jobs com sucesso, já confirmamos várias coisas:

o arquivo está sendo interpretado;
existe um Runner disponível;
os stages estão sendo reconhecidos;
os jobs estão sendo executados;
a pipeline consegue chegar ao final.

A documentação oficial do GitLab possui um tutorial específico para esse primeiro contato.

7. Agora precisamos de um ambiente para nossa aplicação

Até aqui usamos apenas echo.

Agora imagine que nosso projeto seja uma aplicação web construída com Node.js.

O Runner precisa de um ambiente capaz de executar Node e npm.

Uma forma prática de fornecer esse ambiente é utilizar uma imagem Docker como ambiente do job:

default:
  image: node:24

Com isso, podemos alterar nossa pipeline:

stages:
  - build
  - test

default:
  image: node:24

build:
  stage: build
  script:
    - npm ci
    - npm run build

test:
  stage: test
  script:
    - npm ci
    - npm test

Aqui começamos a sair da teoria.

Agora a pipeline está realmente trabalhando com o projeto.

8. Por que `npm ci` aparece tanto em CI/CD?

Quem está começando em Node.js geralmente conhece:

npm install

Mas é muito comum encontrar:

npm ci

em pipelines.

O motivo é que npm ci foi projetado para instalações automatizadas, como ambientes de integração contínua. Ele exige um lockfile existente e utiliza esse arquivo para realizar uma instalação limpa e previsível. Se package.json e package-lock.json estiverem inconsistentes, o comando falha em vez de alterar o lockfile automaticamente.

Podemos pensar no package-lock.json como uma especificação das versões das dependências que devem ser utilizadas.

Isso reduz a chance de um cenário como:

"Na minha máquina funciona, mas no ambiente da pipeline veio outra versão de uma dependência."

Não significa que npm install esteja errado. Significa que os dois comandos possuem objetivos diferentes.

9. Build: a primeira inspeção

Agora temos nosso primeiro estágio real:

build:
  stage: build
  script:
    - npm ci
    - npm run build

O papel desse job é bastante claro:

verificar se a aplicação consegue ser construída.

Se o npm run build funcionar, o job termina com sucesso.

Se o comando retornar erro, o job falha.

Isso é importante porque uma alteração que impede a aplicação de ser construída não precisa esperar a revisão manual de alguém para ser descoberta.

A própria documentação do GitLab utiliza build como exemplo de uma tarefa típica de um job de CI/CD.

10. Mas uma aplicação que compila pode estar errada

Imagine que nosso computador seja montado perfeitamente.

Isso prova que as peças foram encaixadas, mas ainda não prova que o computador está funcionando corretamente.

Software é igual.

Uma aplicação pode compilar sem erros e ainda possuir bugs.

Por isso precisamos de testes.

Essa é a segunda grande responsabilidade da nossa pipeline:

Build
Testes

O build responde:

"Consigo produzir a aplicação?"

Os testes respondem:

"Ela está se comportando como esperado?"

11. Testes automatizados

Um teste unitário, por exemplo, pode verificar uma função ou uma pequena unidade do sistema isoladamente.

Suponha que exista um serviço responsável por calcular o valor final de um pedido.

Podemos escrever testes que verifiquem diferentes situações:

Pedido com um produto
Pedido com vários produtos
Pedido sem produtos
Desconto aplicado
Valor inválido

Não precisamos confiar apenas em alguém abrir a aplicação manualmente e testar esses cenários toda vez que uma alteração for feita.

Podemos transformar essas verificações em código e executá-las automaticamente.

No Angular atual, novos projetos criados pelo Angular CLI utilizam Vitest como configuração padrão de testes, e o próprio Angular possui documentação específica sobre a execução de testes em CI.

12. Um detalhe importante sobre testes no CI

Existe uma diferença entre executar testes localmente e executá-los em uma pipeline.

Durante o desenvolvimento, ng test pode utilizar watch mode, observando alterações nos arquivos e executando os testes novamente.

Em ambientes de CI, queremos que os testes executem e terminem.

A documentação atual do Angular explica que ng test detecta o ambiente de CI e pode executar em modo de execução única; caso seja necessário forçar esse comportamento, --no-watch e --no-progress podem ser utilizados.

Por isso, não devemos simplesmente copiar um comando de desenvolvimento para a pipeline sem entender como ele se comporta naquele ambiente.

Esse é um bom exemplo de uma ideia importante em DevOps:

Automação não é copiar comandos do terminal; é adaptar o processo ao ambiente em que ele será executado.

13. Quando um teste falha, isso é uma coisa boa

Essa frase pode parecer estranha no começo.

Imagine que nosso código tenha um bug.

Sem testes automatizados, podemos descobrir o problema apenas depois de integrar a alteração.

Com testes, temos a possibilidade de descobrir o problema antes.

Por exemplo:

Build: PASS
Testes: FAIL

A pipeline interrompe o processo.

Isso não significa que a pipeline "quebrou o projeto".

Na verdade, ela descobriu que o projeto já estava com um problema.

Esse é um dos maiores valores da CI.

14. Merge Requests: onde tudo começa a fazer sentido

Agora podemos conectar a pipeline ao fluxo de desenvolvimento.

Imagine que você esteja trabalhando em uma branch:

feature/login

Depois de implementar sua alteração, você envia o código para o GitLab e abre um Merge Request.

Podemos configurar a CI para executar uma pipeline nesse contexto.

O GitLab oferece suporte específico a Merge Request Pipelines, que podem ser configuradas por regras utilizando CI_PIPELINE_SOURCE == "merge_request_event".

Isso cria uma situação muito útil:

Seu código não precisa ser integrado imediatamente à branch principal.

Primeiro, ele passa pelas verificações automatizadas.

Assim, o Merge Request passa a ser mais do que um pedido de merge: ele também se torna um ponto de validação técnica.

15. Um exemplo de `rules`

Podemos definir:

test:
  stage: test
  script:
    - npm test
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

A palavra rules é importante porque permite controlar quando um job deve executar.

O GitLab oferece diversas possibilidades para essa lógica, incluindo condições baseadas na origem da pipeline, branch e alterações de arquivos.

Esse recurso se torna especialmente útil quando a pipeline cresce.

16. E o resultado do build?

Imagine que o build da aplicação gere uma pasta:

dist/

Agora temos um resultado concreto.

O GitLab pode armazenar esse resultado como um artifact.

build:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

A ideia de um artifact é simples: é um arquivo ou conjunto de arquivos produzidos por um job e preservados para serem usados posteriormente ou baixados pela equipe.

O GitLab permite armazenar outputs de build e outros resultados de jobs como artifacts.

17. Artifact e cache não são a mesma coisa

Esse é um daqueles conceitos que parecem pequenos, mas fazem diferença.

Um artifact é uma saída importante da execução.

Por exemplo:

dist/

Já o cache serve principalmente para melhorar o desempenho de execuções futuras.

Imagine nossa fábrica novamente.

O artifact é o produto que saiu da produção.

O cache é uma caixa de ferramentas que deixamos preparada para não precisar buscar as mesmas ferramentas novamente.

A documentação do GitLab trata artifacts e cache como mecanismos diferentes: artifacts preservam outputs dos jobs, enquanto cache é utilizado principalmente para acelerar execuções futuras.

18. Agora podemos falar de Docker

Até aqui, a pipeline consegue construir e testar nossa aplicação.

Mas ainda precisamos pensar em como executar esse software de maneira consistente.

É aqui que entra Docker.

Uma imagem Docker funciona como um pacote contendo aquilo que precisamos para executar determinado software.

Podemos pensar na nossa fábrica novamente.

Até agora produzimos e inspecionamos o produto.

Agora precisamos colocá-lo em uma embalagem padronizada.

No caso de uma aplicação web, podemos ter algo como:

Aplicação construída
Dockerfile
Imagem Docker

A documentação oficial do Docker explica os conceitos fundamentais de imagens, containers e construção de aplicações containerizadas.

19. Um Dockerfile simples

Para uma aplicação Angular que será servida como conteúdo estático por Nginx, um exemplo simplificado é:

FROM nginx:alpine

COPY dist/ /usr/share/nginx/html/

EXPOSE 80

Não é importante decorar esse arquivo agora.

O importante é compreender o que ele representa.

FROM define a imagem de base.

COPY coloca os arquivos da aplicação dentro da imagem.

EXPOSE documenta a porta utilizada pelo serviço.

A imagem resultante pode ser executada como container.

20. Primeiro faça o Docker funcionar localmente

Antes de adicionar Docker ao GitLab CI, precisamos verificar se ele funciona localmente.

Construímos a imagem:

docker build -t minha-aplicacao .

Depois executamos:

docker run -p 8080:80 minha-aplicacao

Agora podemos acessar a aplicação localmente.

Essa etapa é muito importante.

Se o Dockerfile não funciona na sua máquina, adicionar um Runner no meio da história só vai tornar o problema mais difícil de investigar.

Uma boa prática de engenharia é reduzir o número de variáveis desconhecidas.

Primeiro:

Docker funciona localmente?

Depois:

Docker funciona dentro da pipeline?

Essa ordem economiza muito tempo.

21. Docker dentro da pipeline

Depois que a imagem estiver funcionando localmente, podemos adicionar um novo stage:

stages:
  - build
  - test
  - docker

E então criar um job responsável pela construção da imagem:

docker-build:
  stage: docker
  script:
    - docker build -t minha-aplicacao .

Aqui existe um detalhe importante: esse exemplo é conceitual.

A forma como Docker será executado dentro de um GitLab Runner depende da configuração do Runner e do executor utilizado. O GitLab possui documentação específica para diferentes estratégias de uso do Docker em CI/CD.

Esse é um ponto em que vale parar de copiar tutoriais e começar a entender a infraestrutura.

22. Onde guardar a imagem?

Depois de construir a imagem, precisamos de um lugar para armazená-la.

É aqui que entra um Container Registry.

Podemos utilizar o próprio GitLab Container Registry.

A ideia é que a pipeline construa uma imagem e publique essa imagem no registry para que ela possa ser utilizada posteriormente.

Uma imagem poderia ser identificada por uma versão, por exemplo:

minha-aplicacao:1.0.0

ou por um identificador associado ao commit.

Isso ajuda a responder uma pergunta importante:

"Qual código gerou esta imagem?"

Quanto mais um sistema cresce, mais importante se torna essa rastreabilidade.

23. Não coloque credenciais no YAML

Suponha que seja necessário autenticar no registry.

Nunca faça algo como:

PASSWORD: "minha-senha"

e envie isso para o Git.

Credenciais e outros valores sensíveis devem ser armazenados nas variáveis de CI/CD do GitLab.

A pipeline pode então acessar a variável sem que o valor seja incorporado diretamente ao código-fonte.

O GitLab possui uma seção específica de documentação sobre CI/CD Variables e segurança de variáveis.

Essa ideia vale para tokens, senhas, chaves e outras credenciais.

24. Nossa pipeline está começando a tomar forma

Depois de entender cada parte, podemos juntar os conceitos.

Uma pipeline inicial poderia ser:

stages:
  - build
  - test

default:
  image: node:24

build:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

test:
  stage: test
  script:
    - npm ci
    - npm test

Essa pipeline já faz algo importante.

Ela garante que o projeto seja construído e testado automaticamente.

Não precisamos começar adicionando Docker, registry, segurança, deploy e dezenas de outras etapas.

Primeiro fazemos o básico funcionar.

25. Depois adicionamos Docker

Com o básico estável, podemos evoluir:

stages:
  - build
  - test
  - docker

Então:

build
test
docker

A ideia é que o processo de containerização aconteça apenas depois das validações anteriores.

Em outras palavras, não faz muito sentido produzir uma imagem de um software que nem passou pelo build ou pelos testes definidos pela equipe.

26. Por que não criar uma pipeline gigantesca logo no começo?

Esse é um erro bastante comum.

A pessoa descobre CI/CD e tenta adicionar imediatamente:

Build
Testes
Lint
Coverage
SonarQube
Security
Docker
Registry
Deploy
E2E
Performance
Rollback

O resultado costuma ser uma pipeline difícil de entender e ainda mais difícil de corrigir.

Uma pipeline deve crescer conforme as necessidades do projeto.

Uma progressão mais saudável é:

Build
Build + Testes
Build + Testes + Artifacts
Build + Testes + Docker
Build + Testes + Docker + Registry

Não existe prêmio por ter o arquivo .gitlab-ci.yml mais comprido.

27. A pipeline como uma barreira de qualidade

Quando o processo está funcionando, podemos pensar na pipeline como uma série de verificações.

Uma alteração de código precisa passar por critérios objetivos antes de avançar.

Por exemplo:

Build passou?
Testes passaram?
Imagem foi construída?

Isso não significa que a pipeline substitui a revisão humana.

Ela não sabe, sozinha, se uma arquitetura é boa.

Ela não sabe se um nome de classe está adequado.

Ela não entende completamente uma decisão de negócio.

Essas responsabilidades continuam pertencendo aos desenvolvedores.

A pipeline automatiza aquilo que é objetivo, repetitivo e verificável.

28. CI não é sinônimo de deploy

Outro erro comum é pensar:

"Se não existe deploy automático, então não existe CI/CD."

Isso não é verdade.

Uma pipeline que automaticamente executa build e testes já está implementando práticas de Continuous Integration.

O GitLab descreve CI/CD como um processo contínuo que automatiza construção, testes e, quando aplicável, implantação e outras etapas do ciclo de entrega.

O deploy automático é apenas uma possibilidade posterior.

29. Como estudar CI/CD sem decorar YAML

Uma boa forma de aprender é estudar cada conceito junto com uma pequena implementação.

Aprenda o que é uma pipeline e crie uma pipeline mínima.

Aprenda o que é um job e crie um job.

Aprenda o que é um stage e crie dois stages.

Aprenda sobre Runner e observe onde o comando realmente é executado.

Aprenda sobre testes e coloque um teste real dentro da pipeline.

Aprenda sobre artifacts e faça o build gerar um arquivo que possa ser recuperado depois.

Aprenda Docker e construa a imagem localmente.

Depois coloque esse processo na CI.

Essa estratégia é muito mais eficiente do que consumir horas de conteúdo antes de escrever a primeira linha do .gitlab-ci.yml.

30. Um exercício simples para começar

Crie um projeto vazio no GitLab e adicione:

stages:
  - build
  - test

build:
  stage: build
  script:
    - echo "Meu build está funcionando"

test:
  stage: test
  script:
    - echo "Meus testes estão funcionando"

Faça o commit e observe a pipeline.

Depois altere o job de teste:

test:
  stage: test
  script:
    - echo "Executando testes"
    - exit 1

Agora o job deve falhar.

Essa pequena experiência ensina um conceito fundamental: a pipeline utiliza o código de saída dos comandos para determinar o sucesso ou falha do job.

Depois disso, substitua os echo por comandos reais do seu projeto.

31. O que você deve saber depois deste artigo?

Não é necessário memorizar todas as palavras-chave do GitLab.

O mais importante é entender o papel de cada componente.

Conceito	Pergunta que ele responde
CI	Como validar alterações automaticamente?
CD	Como automatizar a entrega do software?
Pipeline	Quais etapas compõem esse processo?
Stage	Em que fase da pipeline estamos?
Job	Qual tarefa específica deve ser executada?
Runner	Onde essa tarefa será executada?
Build	A aplicação pode ser construída?
Testes	O comportamento esperado continua funcionando?
Artifact	Qual resultado produzido precisamos preservar?
Docker	Como empacotar a aplicação?
Registry	Onde armazenamos a imagem?
Variables	Como disponibilizar configurações e secrets sem colocá-los no código?

Quando essa relação estiver clara, aprender novas funcionalidades do GitLab se torna muito mais simples.

32. O próximo nível

Depois de dominar essa primeira estrutura, existem muitos assuntos que podem ser adicionados:

Qualidade de código: linters, análise estática e ferramentas como SonarQube.

Testes: cobertura, testes de integração e testes end-to-end.

Segurança: secret detection, dependency scanning e outras verificações.

Performance: cache, execução paralela e needs.

Entrega: environments, deploy automatizado e rollback.

O próprio GitLab possui documentação sobre esses recursos e também disponibiliza tutoriais progressivos para quem está começando.

Mas não há necessidade de aprender tudo de uma vez.

O fundamento continua sendo o mesmo: automatizar o processo de construção, validação e entrega de software de maneira previsível.

33. Materiais recomendados

Se você está começando, vale combinar três tipos de material.

O primeiro são conteúdos introdutórios em português. O próprio GitLab mantém um guia recente em português voltado para iniciantes e também possui um guia rápido para configurar a primeira pipeline.

O segundo são as documentações oficiais. Elas são particularmente importantes quando você sai do exemplo didático e começa a configurar o projeto real.

Por fim, vídeos são úteis para visualizar o GitLab funcionando na prática. Um conteúdo introdutório em inglês bastante completo é o tutorial da TechWorld with Nana, que aborda pipeline, jobs, stages, runners, testes, Docker e variáveis. Também existe um vídeo em português do Vinicius Barreto demonstrando GitLab CI/CD com build e push de imagem Docker.

34. Referências

CI/CD e DevOps

Martin Fowler — Continuous Integration
Artigo clássico sobre os princípios e práticas de Integração Contínua.

Red Hat — O que é CI/CD?
Material introdutório em português explicando CI, Continuous Delivery e Continuous Deployment.

GitLab

GitLab — Get started with GitLab CI/CD
Introdução oficial ao funcionamento do CI/CD no GitLab.

GitLab — CI/CD Pipelines
Documentação sobre pipelines, stages e jobs.

GitLab — Runners
Documentação sobre os agentes responsáveis pela execução dos jobs.

GitLab — Job Artifacts
Documentação sobre armazenamento dos resultados dos jobs.

GitLab — Merge Request Pipelines
Documentação sobre pipelines executadas em Merge Requests.

Angular

Angular — Testing
Documentação oficial sobre testes unitários e execução de testes em CI.

Docker

Docker — Get Started
Introdução oficial a imagens, containers e aplicações containerizadas.

npm

npm — npm ci
Documentação oficial sobre instalações reproduzíveis para ambientes automatizados.

Conclusão

Quando vemos um arquivo .gitlab-ci.yml pela primeira vez, é fácil enxergar apenas uma sequência estranha de YAML.

Mas, depois que entendemos o problema que ele resolve, a estrutura começa a fazer sentido.

Uma equipe produz alterações de software. Essas alterações precisam ser construídas, verificadas e testadas antes de avançarem no processo. O GitLab fornece a plataforma para organizar essa automação. O Runner executa as tarefas. Os jobs representam o trabalho. Os stages organizam as etapas. Os artifacts preservam resultados importantes. Docker empacota a aplicação. E o Registry pode armazenar as imagens produzidas.

A tecnologia pode mudar. Os comandos podem mudar. A forma de configurar a pipeline pode evoluir.

A ideia central, porém, continua a mesma:

Quanto mais do processo de desenvolvimento pudermos verificar de forma automática, consistente e reproduzível, menos dependeremos de tarefas manuais e de descobertas tardias.

CI/CD não é sobre criar uma pipeline enorme.

É sobre criar um processo confiável para transformar código em software que foi construído, testado e preparado de maneira controlada.

E esse é o conceito que vale levar para qualquer projeto, independentemente da linguagem, framework ou plataforma utilizada.
`

DEV Community: Vinícius Carregosa

Mock Server na prática: entendendo JSON Server e o db.json

Introdução

1. O problema entre frontend e backend

2. O que é um Mock Server?

3. Uma analogia simples

4. Mock Data não é Mock Server

Mock Data

Mock Server

5. O que é o JSON Server?

6. O db.json

7. Entendendo a estrutura do db.json

id

projectId

email

role

8. Como o JSON Server transforma o arquivo em uma API?

9. O endpoint /members

10. Filtrando por projectId

11. GET: lendo dados

Listar todos os membros

Buscar um membro específico

Buscar membros de um projeto

12. POST: criando um membro

13. PUT: atualizando um membro

14. DELETE: removendo um membro

15. Onde entra o Angular?

16. O MemberService

17. Por que separar o componente do service?

18. Mock Server não é backend

19. Testando o Mock Server diretamente

20. Um ponto importante sobre versões

21. Como pensar sobre Mock Server

22. O fluxo completo

23. Exercício prático

Criar

Consultar

Atualizar

Remover

24. Erros comuns de iniciantes

Pensar que o db.json é a API

Colocar toda a lógica HTTP no componente

Tratar Mock Server como backend definitivo

Não testar a API isoladamente

Não controlar a versão da ferramenta

25. O que aprendemos?

26. O que acontece quando o backend real chegar?

Conclusão

Referências

CI/CD para iniciantes: entendendo pipelines com GitLab, testes e Docker

Antes de falar de CI/CD, imagine uma fábrica

1. O que significa Continuous Integration?

2. E o que significa CD?

3. A pipeline é a linha de produção

4. Pipeline, Stage e Job

5. Quem executa os jobs?

6. Criando a primeira pipeline

7. Agora precisamos de um ambiente para nossa aplicação

8. Por que npm ci aparece tanto em CI/CD?

9. Build: a primeira inspeção

10. Mas uma aplicação que compila pode estar errada

11. Testes automatizados

12. Um detalhe importante sobre testes no CI

13. Quando um teste falha, isso é uma coisa boa

14. Merge Requests: onde tudo começa a fazer sentido

15. Um exemplo de rules

16. E o resultado do build?

17. Artifact e cache não são a mesma coisa

18. Agora podemos falar de Docker

19. Um Dockerfile simples

20. Primeiro faça o Docker funcionar localmente

21. Docker dentro da pipeline

22. Onde guardar a imagem?

23. Não coloque credenciais no YAML

24. Nossa pipeline está começando a tomar forma

25. Depois adicionamos Docker

26. Por que não criar uma pipeline gigantesca logo no começo?

27. A pipeline como uma barreira de qualidade

28. CI não é sinônimo de deploy

29. Como estudar CI/CD sem decorar YAML

6. O `db.json`

7. Entendendo a estrutura do `db.json`

`id`

`projectId`

`email`

`role`

9. O endpoint `/members`

10. Filtrando por `projectId`

16. O `MemberService`

Pensar que o `db.json` é a API

8. Por que `npm ci` aparece tanto em CI/CD?

15. Um exemplo de `rules`