21–30 of 52 posts
For simple command-based automations, I've found just [0] to be a good replacement for makefiles with .PHONY targets. It has a cleaner syntax and fewer pitfalls compared to makefiles. [0] https://github.com/casey/just
For simple command-based automations, I've found just [0] to be a good replacement for makefiles with .PHONY targets. It has a cleaner syntax and fewer pitfalls compared to makefiles. [0] https://github.com/casey/just
Wow, please don't ship that. A whole suite of CLI tools for a custom deployment pipeline is my worst nightmare if something goes wrong. The purported benefits: > It gets people into the habit of running a single command to initiate deployments npx firebase-tools deploy --only functions -P staging is also one command > It’s a more obvious source of truth for putting the deployment instructions If that command were put…
> npx firebase-tools deploy --only functions -P staging Better yet: make deploy-staging Even when it's just wrapping something else, I strongly prefer to use make(1) as the universal all in one command.
Earlier quoted context omitted.
> npx firebase-tools deploy --only functions -P staging Better yet: make deploy-staging Even when it's just wrapping something else, I strongly prefer to use make(1) as the universal all in one command.
I don't know if that pattern has a name, but I really love that on my team if there is a script it should be runnable through the Makefile. I know some people are very good a remembering commands, but I'm not and being able to do `make docker`, `make init`, `make eval`, etc... really simplifies my workflow.
Even better, make this recipe's dependencies work so it doesn't do anything if you don't need to run init, then have everything else depend on init. That way no one needs to remember to run init first.
This seems like the same basic concept as https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-...
I remember when that article first made the rounds. I had been doing something like that for a few years already and the article did a good job making all the same points I would have made. In hindsight, the biggest challenge that I've found is getting your "do-nothing script" to become the authoritative source of how to do something. The fact that the steps themselves are still manual means that it's easy for people…
Once the script actually automates a few of the more tedious steps, people are much more likely to use it. And when they use it, they're likely to help maintain it when new situations need it.
Eventually, you may end up with a script that does automate it all, and can be put in CI/CD. (Hey, I can dream, can't I?)
Different teams might want to use it for different things, deploy different versions with it, etc. So it should be in a separate repo with its own tests and its own version string. Otherwise iterating on it is hell because you're doing so in a space that's ergonomic for app development, not deployer-tool development.
That way when your deploy target changes (goodbye helm, hello custom k8s operator), your users can keep using the stable deployer version while you work on the new one.
Following that, switching between the old way and the new way becomes an atomic action, which makes it much easier to triage issues of the "it worked with the old way but breaks with the new way" sort.
Or at least... I hope that's what I missed. Because if not I'll be reredoing it next year.
Please don't do this on a $0 MRR project. Wait until it's a viable company before spending time automating everything.
I was doing this a year ago. Now I'm redoing it. In my case, what I missed is that if the app is complex enough you should treat the deployer like a separate product. Different teams might want to use it for different things, deploy different versions with it, etc. So it should be in a separate repo with its own tests and its own version string. Otherwise iterating on it is hell because you're doing so in a space tha…
And it can actually be a mistake to try to jump from zero directly to fully automated nirvana.