you are viewing a single comment's thread
view the rest of the comments
[+] -24 points 1 year ago (20 children)
  • [–] 23 points 1 year ago (7 children)

    Why not? Why doesn't the programmer want to test a container?

  • source
  • parent
  • hideshow 7 child comments
  • [–] 15 points 1 year ago (6 children)

    True. Nothing beats running your unit tests in the actual container image that will be run in production.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 9 points 1 year ago* (2 children)

    Race condition that only happens on the much faster production hardware: Allow me to introduce myself

  • source
  • parent
  • hideshow 2 child comments
  • [–] 7 points 1 year ago

    Unit tests can’t win ’em all. That’s where things like integration tests, staging environments, and load testing come in.

    The final layer of protection is the deployment strategy, be it rolling, canary, or blue-geen.

  • source
  • parent
  • [–] 1 point 1 year ago

    Unit tests? No matter where you run them, and normally this is done by CI in a prebuilt container image, so you don't have to wait for "docker building". Acceptance tests must be run in an environment as close to production as possible, but that's definitely not a programmer's job.

  • source
  • parent
  • [–] 21 points 1 year ago (3 children)

    I wonder what the dev part of devops means.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 1 year ago

    At my previous job, we had a "Devops" team. We even outsourced some ops to a third party in the worst possible way (I'm talking "oh you want to set up an alert for something related to your service? Send us an email and we'll look into it" and so on). All the pre-devops pain magnified by an order of magnitude. Sometimes devs would do their own ops (I know, big shock!), and they would call it "shadow devops". Nearly fell off my chair when I first heard it. Kinda glad I'm not with them anymore.

  • source
  • parent