Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fake it until you automate it

understandlegacycode.com

Post reply on HN
Print view View original

11–20 of 52 posts

Re: Fake it until you automate it

#11

Post by francis-io »

yjftsjthsd-h wrote: post #4
kevmo314 wrote: post #3

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.

Agreed. I like keeping make as my universal abstraction for all commands in a project. I keep a template to use on each new project with all the best practice fixes I've found over the years. I keep my own documentation as comments for things I often forget about how to use make. I have the same for bash scripts too.

I like to also use the same commands in by build pipeline. It ensures I'm running the same commands as I do locally, with the added benefit of abstracting the deployment logic from what ever CI system you use.

Some issues I've found with this approach is having to install make on a build system, which these days is a slim docker container.

Some devs still run windows, but I think you can install some kind of equivalent.

Re: Fake it until you automate it

#12

Post by francis-io »

Joel_Mckay wrote: post #2

Try including the IT support cost of the collateral damage unskilled workers can do with administrative rolls. You will end up supporting hundreds if not thousands of operational features. I am not suggesting you should give a toss, but at least admit what happens before you inflict the decision on your team. Have a wonderful day =)

I think the assumption is that the developers already manage deploying as well, but it's manual.

Re: Fake it until you automate it

#13

Post by mason55 »

abathur wrote: post #7

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 to create their own manual side paths to cover new situations and it's hard to get those added back into the script.

If your CI/CD server is running all the steps then the only way to make something happen is to get it into the build script. If there are humans in the loop then there will always be new things that come up, people who do them in slightly different ways, and stuff that doesn't get committed back into the scripts.

Re: Fake it until you automate it

#14

Post by francis-io »

volker48 wrote: post #10
belval wrote: post #9

Earlier quoted context omitted.

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.

There can definitely be some downsides to this approach. For example, let me see what the CI script does to deploy. "make deploy", ok let me checkout the Makefile. Ok, that calls some python module "deploy.py". I tend to get frustrated with all the indirection and would prefer to just see the deploy steps in the CI script itself.

It's nice to be able to run the same commands locally as you do in CI. Having the deployment logic outside of the pipeline specific format will allow you to do this.

Make is great because its usually installed everywhere. The downside is that it has a lot of edge cases. Breaking out right away into a better language for the more complex tasks can make sense.

Re: Fake it until you automate it

#15

Post by yjftsjthsd-h »

volker48 wrote: post #10
belval wrote: post #9

Earlier quoted context omitted.

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.

There can definitely be some downsides to this approach. For example, let me see what the CI script does to deploy. "make deploy", ok let me checkout the Makefile. Ok, that calls some python module "deploy.py". I tend to get frustrated with all the indirection and would prefer to just see the deploy steps in the CI script itself.

I can certainly sympathize with not liking the extra layers, but if you put the steps directly in CI then you either duplicate local/CI steps (and they inevitably get out of sync), or CI becomes the only way to deploy (which, depending on your situation might be fine). It can be a reasonable thing to do, but it's a pretty sharp tradeoff.

Re: Fake it until you automate it

#16

Post by francis-io »

watusername wrote: post #6

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

This really does look great. It makes a lot of the common things I want to do with a Makefile really easy.

The big problem I find is changing process in a big team is hard. One of the great things is make is usually installed on most developers machines. It reduces the friction when trying to get a team on board.

Re: Fake it until you automate it

#17

Post by belval »

volker48 wrote: post #10
belval wrote: post #9

Earlier quoted context omitted.

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.

There can definitely be some downsides to this approach. For example, let me see what the CI script does to deploy. "make deploy", ok let me checkout the Makefile. Ok, that calls some python module "deploy.py". I tend to get frustrated with all the indirection and would prefer to just see the deploy steps in the CI script itself.

I mean that example is frustrating because obviously `make deploy` and `python deploy.py` are both pretty simple so they are easy to remember.

One common pattern that I'll see though is deploy.py not being top level so `python deploy.py` becomes `python scripts/deployments/staging/deploy.py` so you still get the benefit of not wondering where `deploy.py` is.

Another is the configuration file also having a default version that is not obvious. Something like `configuration/deployments/staging.yaml`.

Now you might argue that I'm exaggerating (and I think it's fair to say that some refactoring could be valuable), but the simple `python deploy.py` now actually is.

`python scripts/deployments/staging/deploy.py -c configuration/deployments/staging.yaml` which is significantly harder to remember than `make deploy-staging` for example.

Re: Fake it until you automate it

#18

Post by nerdponx »

belval wrote: post #17
volker48 wrote: post #10

Earlier quoted context omitted.

There can definitely be some downsides to this approach. For example, let me see what the CI script does to deploy. "make deploy", ok let me checkout the Makefile. Ok, that calls some python module "deploy.py". I tend to get frustrated with all the indirection and would prefer to just see the deploy steps in the CI script itself.

I mean that example is frustrating because obviously `make deploy` and `python deploy.py` are both pretty simple so they are easy to remember. One common pattern that I'll see though is deploy.py not being top level so `python deploy.py` becomes `python scripts/deployments/staging/deploy.py` so you still get the benefit of not wondering where `deploy.py` is. Another is the configuration file also having a default ver…

I am a big advocate for and user of this pattern with Make.

However there is one non-trivial downside with (GNU) Make, and that is the non-visibility of env vars set with `export` when running `make -n`. That is, if your Makefile looks like this:

  export FOOBAR=123

  .PHONY: do-it
  do-it:
    ./scripts/do-it
Then `make -n do-it` will not show the exported FOOBAR variable. This makes it somewhat more difficult to audit or inspect with `make -n`.

The output from `make -np` is incredibly verbose and isn't easy to filter with standard CLI tools, which makes this doubly frustrating. You basically need to write an AWK/Perl/Python program to parse it. If there was one feature I'd pay good money to add to a new version of GNU Make, it's an option to emit more-easily machine-readable output from `make -p`, or to ship a script in the GNU Make package that parses it into something standard like JSON or XML.

Re: Fake it until you automate it

#19

Post by dewey »

kevmo314 wrote: post #3

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…

Nothing wrong with rolling with something like that until there are more than a few people working on the project and you have actual customers.

Overengineering infrastructure early on is fun, but unecessary and something that can relatively simply be tackled later.

Re: Fake it until you automate it

#20

Post by jrockway »

yjftsjthsd-h wrote: post #15
volker48 wrote: post #10

Earlier quoted context omitted.

There can definitely be some downsides to this approach. For example, let me see what the CI script does to deploy. "make deploy", ok let me checkout the Makefile. Ok, that calls some python module "deploy.py". I tend to get frustrated with all the indirection and would prefer to just see the deploy steps in the CI script itself.

I can certainly sympathize with not liking the extra layers, but if you put the steps directly in CI then you either duplicate local/CI steps (and they inevitably get out of sync), or CI becomes the only way to deploy (which, depending on your situation might be fine). It can be a reasonable thing to do, but it's a pretty sharp tradeoff.

I don't think that depending on CI for deployments is the worst thing you can do. You get two good signals; 1) this compiled on my machine, and it compiles on some other random machine, so it's looking likely that this binary will start up on the prod servers ok. 2) there is some proof that the test suite passed before you ship your thing to production.

I'm really pretty OK with "if CI is down, and there's a prod emergency, and the test suite is broken", not everyone on the team can fix that. Escalate to someone who can, the 0.5 times this happens a year; the rest of the time, everyone clicks "merge" on their pull request and the code filters out into production quickly and efficiently. They don't want to think about it, but the customer gets their features as soon as possible. Not the worst thing. Way better than "our release person is on vacation, we'll restore your outage next week".

Post reply on HN