Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That is an absurdly black-and-white view.


I have lost count of the times I've heard "but it works fine on MY machine, it must be the CI/CD that's broken"

I then find out that no-one bothered to run the compose file that matches what gets put into prod on their local machines.

My point is: your view might become more black and white on this matter after the N-th "but it works fine on MY machine" comment.

EDIT: Where N = your personal tolerance level of bullshit.


Sounds like this was easily caught by CI, which does run the prod compose file, and everything was fine.


This wasn't a real example. Just a generic thing that happens everywhere I go.

There's always one in the crowd that refuses to give up local development.


As long as you have CI or staging with the proper config, what does it matter how the devs write code?


The two aren't separate. There is a direct link between how devs write code and whether something works in production. And there is a ton of productivity loss and reliability loss when these two things are not in sync.


That might me your experience, I don't share it.

But even so, how you can go from that to:

> [...] there's really no point to using Docker Compose other than developing without internet access

boggles my mind.

EDIT: apologies, mixup on my end and quote is from someone else.


Not the parent! Made no comment on developing without internet access.

EDIT: I usually try to build, test, inspect, push and deploy from the same compose file. You can deploy to ECS direct from compose using an AWS context: https://aws.amazon.com/blogs/containers/deploy-applications-...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: