4 ms·

That is an absurdly black-and-white view.

• dijksterhuis 4y ago
  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.
  • remram 4y ago
    Sounds like this was easily caught by CI, which does run the prod compose file, and everything was fine.
    • dijksterhuis 4y ago
      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.
      • remram 4y ago
        As long as you have CI or staging with the proper config, what does it matter how the devs write code?
        • 0xbadcafebee 4y ago
          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.
  • tjoff 4y ago
    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.
    • dijksterhuis 4y ago
      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-on-amazon-ecs-using-docker-compose/ https://aws.amazon.com/blogs/containers/deploy-applications-...
• deleted 4y ago
  [deleted]