• HubertManne@moist.catsweat.com
    link
    fedilink
    arrow-up
    15
    ·
    9 days ago

    last place I worked had an environment refered to as poc/staging. poc. staging. these are supposed to be as far apart as possible in a non prod environment not combined.

  • steventhedev@lemmy.world
    link
    fedilink
    arrow-up
    14
    ·
    edit-2
    9 days ago
    When I was a young dev
    My senior took me into the city
    To push my code to prod
    He said "Son, when you promo
    Would you be the savior of the broken
    The buggy and the OOM'd?"
    
  • GissaMittJobb@lemmy.ml
    link
    fedilink
    arrow-up
    9
    ·
    9 days ago

    This is what feature flags are for. You can test in production to your hearts content if you use them!

    • MajorHavoc@programming.dev
      link
      fedilink
      arrow-up
      13
      ·
      9 days ago

      Yeah. Warning - uninvited poetic waxing on feature flags and leadership choices, incoming…

      We all agree we inevitably do some live testing at our customers risk, because no test environment is perfect.

      With feature flags, we’re able to negotiate how many of our customers to test on, at a time.

      But some of us prefer to forgo feature flags and risk our entire customer base on every change. It saves money, at least for a little while.

      I’m not exactly fun at executive leadership meetings, but somehow I keep getting invited to them. Heh.

  • Aceticon@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    8 days ago

    The first sign that the company you just joined is amateur hour, every hour of the day, every day of the year is that they don’t have a Staging environment.

      • Aceticon@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 hours ago

        I’ve seen, again an again, deploying to Staging and integration testing in that Production-like environment together with the software of other teams, reveal problems that we did not saw in Dev, thus saving us from deploying into Production software that broke or, worse, corrupted the database.

        This was certainly very important when I worked in environments such as Investment Banking where Production being down because of integration issues or, worse, sending bad data to other systems or the database having to be rolled back to the overnight backup, might mean the business losing millions of dollars.

        It’s not a foolproof mechanism but it certainly catches most integration problems, which are often most of the problems in complex environments where multiple teams are responsible for multiple highly integrated software systems,

        Granted, little teams doing small software systems in simple environments were their software has little or no integration with other software, can probably get away with not having a Staging environment if their Dev environments has the same setup as Production (same OS, same database and so on) since they’re going to have very little in the way of Integration problems with other people’s software.