The more projects you work on, the more streamlined your tooling gets. Hopefully. Various services using different languages have different tooling requirements, of course. A sweet Makefile can be the entry to a unified tooling interface.
As long as I can run
make build deploy in a project, I’m happy. Do you a have more complex interface to deploy a
dev environment? Rethink your tooling and remove obstacles for people who want to work on your project or contribute to your code.
You might have noticed,
make will list the invoked commands in a target per default. You can avoid this, and have a more slick output using
@ in front of your commands:
greet: @ echo "Hi!"
# Without @ $ > make greet echo "Hi!" Hi! # With @ $ > make greet Hi!
You can always access environment variables in a
Makefile, but for composition, you may want to use wildcard targets in
greet-%: @ echo Hi $*!
# Say Hi to Frank $ > make greet-Frank Hi Frank!
Together with wildcard targets, using lists and foreach can be a powerful addition to your
NAMES := Anne Frank Paul greet-%: @ echo Hi $*! greet: @ make $(foreach NAME,$(NAMES),greet-$(NAME))
# Say Hi to everybody! $ > make greet Hi Anne! Hi Frank! Hi Paul!
I plan to write down more Best Practices soonish …
There are plenty of tools and services for continuous delivery available. Most of them are either directly built into the source code management tools you already use, or perfectly integrate with them. You might be…
I was able to attend the AWS re:Invent 2019 conference. A week full of learning about current and new technologies, services, and general approaches is definitely overwhelming. There is no much content available, during…
You can find plenty of frameworks and tools to provision your AWS resources. Some of them do a great job for a specific purpose, others are more generic. Nevertheless, I do prefer to use native CloudFormation templates…