4 ms·

> No better fix for those low stakes than being on call. I prefer a company with a strong tech culture: code review, thinkg long-term (marathons instead of spr

> No better fix for those low stakes than being on call. I prefer a company with a strong tech culture: code review, thinkg long-term (marathons instead of sprints) and design systems with architecture-first on mind (instead of feature-first), automated testing, QA people, don't deploy on Fridays...

pc86 6y ago
If you've got testing, code reviews, QA, and CI/CD, Friday deployments should be totally fine.
- sdevonoes 6y ago
  The point is "Friday deployments" are not needed (unless we are talking about hotfixes). What's the use case? Can't it wait until Monday? Why are all in such a rush?
  - pc86 6y ago
    I would say that if things are tested appropriately (it's a big if, and not an easy thing to do honestly), when you commit a new feature it should go through the testing process and right into production. If that makes you nervous then there's more testing that needs to be added. Canary deployments with extensive monitoring and automated rollbacks and make this almost entirely hands-off. For most software systems the goal should be to abstract away the actual act of "deploying" and let the infrastructure handle that on its own.
  - tharkun__ 6y ago
    Because the company makes your rating/pay dependent on BS metrics that drive the wrong behavior, such as merging on Friday so that your cycle time isn't too high. Might mean a paycut. Friday deploy gone wrong? Fix the issue, issue another PR that is approved and also deployed in no time? You're the hero and your metrics are also awesome. Cycle time baby! :(
  - potatoz2 6y ago
    Because then you have double the changes to deploy on Monday. And if you push that logic further (no deploys on Thursday, no deploys after 3pm, no deploys +-3 days around holidays, etc.) you end up with very high density deploys, which are riskier.

4 ms·

> No better fix for those low stakes than being on call. I prefer a company with a strong tech culture: code review, thinkg long-term (marathons instead of spr

by sdevonoes 6y ago

pc86 6y ago
If you've got testing, code reviews, QA, and CI/CD, Friday deployments should be totally fine.
- sdevonoes 6y ago
  The point is "Friday deployments" are not needed (unless we are talking about hotfixes). What's the use case? Can't it wait until Monday? Why are all in such a rush?
  - pc86 6y ago
    I would say that if things are tested appropriately (it's a big if, and not an easy thing to do honestly), when you commit a new feature it should go through the testing process and right into production. If that makes you nervous then there's more testing that needs to be added. Canary deployments with extensive monitoring and automated rollbacks and make this almost entirely hands-off. For most software systems the goal should be to abstract away the actual act of "deploying" and let the infrastructure handle that on its own.
  - tharkun__ 6y ago
    Because the company makes your rating/pay dependent on BS metrics that drive the wrong behavior, such as merging on Friday so that your cycle time isn't too high. Might mean a paycut. Friday deploy gone wrong? Fix the issue, issue another PR that is approved and also deployed in no time? You're the hero and your metrics are also awesome. Cycle time baby! :(
  - potatoz2 6y ago
    Because then you have double the changes to deploy on Monday. And if you push that logic further (no deploys on Thursday, no deploys after 3pm, no deploys +-3 days around holidays, etc.) you end up with very high density deploys, which are riskier.