Makefiles For Modern Development
1976 in your stack? It’s likelier than you think.
Join the DZone community and get the full member experience.Join For Free
Having local workflows line up all of your integrations is very worthwhile, but can be a pain to set up. As starting points for making new apps, developers can check out these recently released starter repos.
In this article, we’ll focus on one of the key pieces of the starter repo: the Makefile.
Languages usually have their own task runners, often embedded in the language’s package manager (e.g.
npm for node,
poetry for Python). If you use those programs to run the development workflows, though, that means you’ll need to learn a new tool for each language with which you interact.
Using Makefiles as an abstraction above any language-specific tooling allows for easy upgrading of that tooling without having to teach your team how to use a new CLI. This way, they can just keep running the same Make commands they’re used to.
A more subtle benefit is that Makefiles serve as documentation for the workflows and actions needed for any project.
Finally, Makefiles have been in use since 1976, so they’re as battle-tested as can be.
Let’s take a look at the actual Makefile for our repo, section by section.
1. Main Development Workflow
develop: clean build migrations.upgrade run clean: docker-compose rm -vf build: docker-compose build run: docker-compose up
These are the core functions that developers will be running over and over:
make cleanto stop any running service
make buildto re-build your images with updated code
make runto run the containers
We can combine each of those actions to form the main command that developers will run over and over:
make developwhich runs
run(and upgrades migrations)
2. Shell Commands
frontend-shell: docker-compose run frontend \ sh backend-shell: docker-compose run worker \ sh python-shell: docker-compose run worker \ poetry run flask shell
- These are convenience methods to get each of the shells you’ll need for this project:
make frontend-shellgets you a Bash shell in the node container
make backend-shellgets you a Bash shell in the Python container
make python-shellgets you a Python shell in the Python container
3. Database Commands
postgres.data.delete: clean docker volume rm $(VOLUME)_postgres postgres.start: docker-compose up -d postgres docker-compose exec postgres \ sh -c 'while ! nc -z postgres 5432; do sleep 0.1; done'
- Each of these deals with the database:
make postgres.data.deleteto stop containers (notice the
stopto the right of the colon) and clears data
make postgres.startto start the database in the background, and wait for it to start up
migrations.blank: postgres.start docker-compose run worker \ poetry run flask db revision migrations.create: postgres.start docker-compose run worker \ poetry run flask db migrate migrations.upgrade: postgres.start docker-compose run worker \ poetry run flask db upgrade migrations.heads: postgres.start docker-compose run worker \ poetry run flask db heads
- Finally, each of these handles the usual migration tasks that a developer needs to do (note that each command starts postgres in the background with
make migrations.blankcreates a blank Alembic migration
make migrations.creategenerates a migration off of any detected schema changes
make migrations.upgradeapplies any unapplied migrations
make migrations.headsshows the latest the latest migration (and any forks in the migration path)
The Oldies Are Great
Makefiles may have been invented more than 40 years ago, but that doesn’t make them any less fit for the job. Using Make as the interface for project workflows allows for ease of knowledge sharing, quick onboarding of new developers, and straightforward refactoring use of other CLI tools.
And if you containerize your projects, onboarding engineers into a new project in any language just becomes:
- Securely sharing credentials
- Installing Make and Docker
So start building that new app you’ve been thinking about!
Published at DZone with permission of Peter Valdez. See the original article here.
Opinions expressed by DZone contributors are their own.