4 ms·

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:

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 into CI/CD, that would be an even more authoritative source of truth. > Because it’s already an executable script, it makes it easier for us to automate some of the steps listed The executable script can't be run by CI/CD and is another potential source of bugs/mistakes. The real "fake it until you automate it" for deployment would've been ssh'ing into the server, running git pull, and restarting the server. That's no longer possible with serverless nowadays, but this seems to go from taking something that's relatively straightforward to something that's very complex.

yjftsjthsd-h 4y ago
> 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.
- belval 4y ago
  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.
  - volker48 4y ago
    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.
    - francis-io 4y ago
      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.
    - yjftsjthsd-h 4y ago
      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.
      - jrockway 4y ago
        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".
    - belval 4y ago
      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.
  - Izkata 4y ago
    > make init 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.
- francis-io 4y ago
  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.
- Spivak 4y ago
  But make kinda sucks for this kind of thing. The CLI tool we use based on pyinvoke gives you tab completion for all the commands and all the options which by itself is worth the switch from make.
dewey 4y ago
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.
hinkley 4y ago
Not even half, but a pretty decent chunk of my tools are things that someone thought should only happen in CI/CD and then it breaks and there's no way to debug. People are not fond of using your tools when they create blocking issues that are potentially open ended. Most of your tools should run in CI/CD. That's the goal, and a pretty high priority one. But they can't only be run there.

yjftsjthsd-h 4y ago

> 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.

belval 4y ago
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.
- volker48 4y ago
  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.
  - francis-io 4y ago
    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.
  - yjftsjthsd-h 4y ago
    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.
    - jrockway 4y ago
      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".
  - belval 4y ago
    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.
- Izkata 4y ago
  > make init 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.
francis-io 4y ago
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.
Spivak 4y ago
But make kinda sucks for this kind of thing. The CLI tool we use based on pyinvoke gives you tab completion for all the commands and all the options which by itself is worth the switch from make.

dewey 4y ago

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.

hinkley 4y ago

Not even half, but a pretty decent chunk of my tools are things that someone thought should only happen in CI/CD and then it breaks and there's no way to debug. People are not fond of using your tools when they create blocking issues that are potentially open ended. Most of your tools should run in CI/CD. That's the goal, and a pretty high priority one. But they can't only be run there.