0

As an example, let's say you have the following pseudocode:

if test environment: # meaning you don't have the typical service account prod perms
  sudo as service account + do operation
else: # in prod so service account will have perms
  do operation

assuming that the operation is permission sensitive, such that you need these perms to run in test (otherwise the code would break because of aforementioned perms errors), is this good/bad practice, and what's the best solution? Is this code a security risk, or should the engineer be responsible for assigning the right environment variables?

Consider that without this if/else, you can't run/debug the app outside of prod anymore. There's value in being able to run/debug in test right?

If I left the company tomorrow and no one else was familiar with how to debug this locally, if any other random person ran into an error in prod, pulled down the code and tried to run it locally, and found out it just wouldn't work, and then had to figure out they had to sudo as the service account, I think they'd be pretty annoyed?

Improve this question
5
  • Consider this: if the code only runs in prod, the only place you can really test it is in prod. That's usually not the best place to test anything.
    – Becuzz
    Jul 16, 2021 at 17:36
  • Why bother testing at all? if test-env then pass else run code
    – Erik Eidt
    Jul 16, 2021 at 23:59
  • Instead of performing a check for the environment, I would suggest performing a check for whether the permissions are available instead. Having diagnostic logging to record the lack of permissions would also be helpful for someone trying to check when those permissions are missing. It may also be helpful to provide a deployment script which can be used in any environment to run the app, and 'readme' documentation which explains the correct deployment process step-by-step, including prerequisites (such as permissions)
    – Ben Cottrell
    Jul 17, 2021 at 8:25
  • @BenCottrell it's git permissions so the only way to find out would be to get an error from git. I will probably document to the best of my ability the workaround to testing locally which can't go to master.
    – notacorn
    Jul 17, 2021 at 19:35
  • @notacorn in which case it seems like it'd be better to skip the check and try regardless then log an easily-findable error message if anything goes wrong (Which could include other problems than just missing permissions - e.g. network issues). Another option could be to include a feature-toggle flag inside a configuration file which may be overridden per-environment so that the code would check whether the feature-toggle is enabled instead.
    – Ben Cottrell
    Jul 18, 2021 at 0:16

1 Answer 1

Reset to default
6

I think you know the answer to this question already:

  • No, it's not great to run different code in test and production. This increases the risk when you move to production.
  • However, it's better to run different code in test and production than to not test stuff.

In the specific example you've given of permissions, it sounds like you should really be working on making your test environment more like your production environment so it does have the permissions it needs.

Improve this answer
3
  • unfortunately it's sort of like I'm just testing it on my machine, so maybe "test" environment is even a stretch. my user isn't really ever going to get the same permissions as that service acc
    – notacorn
    Jul 16, 2021 at 14:53
  • 1
    There are still things you can do on a single machine; while containerisation may be over-hyped in some circles, one of the things it is good at is creating "easy come, easy go" isolated environments for testing.
    – Philip Kendall
    Jul 16, 2021 at 15:15
  • @notacorn maybe you should run the whole app as the service account. Or, change the permissions on the thing so your account can access it.
    – user253751
    Jul 16, 2021 at 15:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.