// workshop equipo de dev

Por qué usar Makefile

Cada razón, con su receta. Sales convencido y con tu primer Makefile andando.
el problema

Comandos largos que nadie recuerda

  • ✕"¿Cómo levanto esto?" y hay que buscar en el README o en Slack.
  • ✕Cada quien corre los comandos distinto, con flags distintos.
  • ✕El comando de deploy vive en la cabeza de una persona.
Un Makefile pone todos los comandos del proyecto en un solo lugar.
analogía
El Makefile es el control remoto de tu repo. Un botón por acción.
// make up, make test, make deploy: no recuerdas comandos, recuerdas verbos
el atajo

Un botón por cada tarea

  • →Target: un atajo con nombre (setup, up, test).
  • →Receta: los comandos que corre ese target.
  • →Lo llamas con make <target>.
Viene en Linux y Mac desde siempre. Cero dependencias nuevas.
$_
manos a la obra

Tu primer Makefile

Un archivo llamado Makefile en la raíz del repo.
ya lo tienes

make ya vive en tu máquina

$ make --version
# si falta:
$ sudo apt install make # debian/ubuntu
$ xcode-select --install # mac
# Windows: WSL, o choco install make
En Linux y Mac casi siempre está. No instalas un runner nuevo.
el índice

El README que sí se ejecuta

.PHONY: setup up test
setup:
npm ci
up:
docker compose up
test:
npm test
.PHONY avisa que setup/up/test son acciones, no archivos.
un verbo

make setup, make up, make test

$ make setup # npm ci
$ make up # docker compose up
$ make test # npm test
El mismo comando corto para todos, sin recordar flags ni rutas.
analogía
Un solo make setup en vez de un README de 40 pasos.
// el nuevo dev clona, corre make setup, y ya está trabajando
local = ci

El CI llama a las mismas puertas

# .github/workflows/ci.yml
steps:
- run: make setup
- run: make test
El CI llama los mismos targets que tú. Se acaba el "en el CI es distinto".
piezas que encajan

Tareas que se llaman entre sí

IMAGE = miapp:latest
build:
docker build -t $(IMAGE) .
deploy: build
docker push $(IMAGE)
Cambias la versión en un solo lugar. make deploy corre build primero, solo.
se explica solo

make help, y el repo se presenta

setup: ## Instala dependencias
up: ## Levanta el entorno
help:
@grep -E '^[a-z]+:.*##' Makefile | \
awk -F':.*##' '{printf " %-10s %s\n",$$1,$$2}'
El Makefile te dice qué se puede hacer, sin leer el código.
todo junto

Un Makefile que da gusto

.PHONY: setup up test build deploy help
IMAGE = miapp:latest
setup: ## Instala dependencias
npm ci
up: ## Levanta el entorno
docker compose up
test: ## Corre los tests
npm test
build: ## Construye la imagen
docker build -t $(IMAGE) .
deploy: build ## Publica, corre build primero
docker push $(IMAGE)
help: ## Muestra esta ayuda
@grep -E '^[a-z]+:.*##' Makefile | awk -F':.*##' '{printf " %-9s%s\n",$$1,$$2}'
la trampa

El TAB que te va a morder

build:
→TABdocker build . # correcto
build:
····docker build . # error: missing separator
Las recetas se indentan con un TAB real. Configura tu editor para no convertirlo a espacios.
la letra chica

Cuándo NO es la herramienta

  • ·Ya tienes un runner que a todos les gusta (npm scripts, just, task).
  • ·Lógica compleja con condicionales: pásalo a un script.
  • ·Equipo 100% Windows sin WSL: make no viene de fábrica.
Makefile brilla como índice de comandos, no como lenguaje de programación.
el lunes

Agrega un Makefile a un repo tuyo

01Crea un Makefile en la raíz.
02Targets setup, up, test con .PHONY.
03Reemplaza los comandos del README por make.
04Haz que el CI llame make test.
05Agrega variables para versión e imagen.
06Suma un target help autodocumentado.
cierre

Un verbo por acción

Todos los comandos del proyecto, con nombre, en un solo archivo. Agrega un Makefile a tu repo esta semana.
seguimos en contacto

Sígueme

# notas técnicas y proyectos
web dev.jotive.com.co
# instagram
ig @jotive.dev
A · 01 Por qué usar Makefile · workshop ← → 01 / 16