Post reply

Should testing of Business Report changes be allowed in Prod?

  • October 25, 2024 at 8:49 pm

    #4473860

    When I arrived at the company 2.5 years ago, the environments were a mess!  Dev crap in Prod, Prod stuff in dev, many databases didn't have a Dev version, etc.  It has been a grueling marathon, but the environment is mostly stabilized.  I've even set up a PreProd environment where users can test deployments or troubleshoot bugs with Prod-like data.

    In spite of that, I have a report developer who is not happy.  She wants to be able to run changed code side-by-side with Prod code to see the results meet expectations.  Since the PP environment is up to a day behind, this will only occur if I allow her reporting Procs to live alongside the Prod procs in the Prod environment.  While this is low risk as they are reporting procs and are not changing any data, it is a pain for me and goes against the whole "no testing in Prod" rule.

    1. Should I indulge her by allowing this, even though it goes against standards and is an inconvenience for me?
    2. If not, how can I explain that I'm not going to allow it when the potential risk is very low?

    Thanks All!

    Be still, and know that I am God - Psalm 46:10

  • October 26, 2024 at 9:10 pm

    #4474120

    Thanks for posting your issue and hopefully someone will answer soon.

    This is an automated bump to increase visibility of your question.

  • October 30, 2024 at 1:11 pm

    #4475415

    [oops, duplicate post]

    • This reply was modified 3 weeks ago by  david.gugg.

    Be still, and know that I am God - Psalm 46:10

  • October 30, 2024 at 1:17 pm

    #4475418

    Is this in the right forum?  Bump.

    Be still, and know that I am God - Psalm 46:10

  • October 30, 2024 at 3:52 pm

    #4475489

    I would say no, the dev doesn't get to test in production. She can be unhappy. She's lucky she has data that is only a day old. Imagine working where acceptance is refreshed once a year.

  • October 30, 2024 at 10:31 pm

    #4475661

    Here's what I'd say. If there is a business reason, meaning up to date data needed for the report, then yes. I'd give her a separate schema so the reports don't get "deployed" accidentally, and still use version control, automation, etc. to deploy the reports to prod when approved.

    However, reporting can throw a larger load on the db, and if this has been a problem (as in cross joins or other large queries), then no. Even if I said yes, I'd be monitoring this developer's load to be sure they don't cause issues.

    There are things that need to be tested in prod, and mature orgs often have test accounts in prod to allow for this to happen. I'd argue reports aren't one of these and likely the developer is being lazy. I'd also note that their "checks" of data will change every day if they are in prod as it's not controlled. It would be better to have testing and evaluate if what they are doing makes sense from a logical standpoint and their calculations are correct.

  • October 31, 2024 at 3:12 pm

    #4475965

    Thanks for the feedback guys, I appreciate it!

    I like your idea of a separate space to test with Prod data Steve.  I think (if I have to indulge this user) that I will create a new database that wipes out all objects inside itself each night.  The user can compile objects as needed to validate, but will not undertake complete development there (which is something I am wary of) because it gets wiped out all the time.

    Be still, and know that I am God - Psalm 46:10

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply