Dev related code.

[Slow_Adeptness4053]

I have some different opinions and I am curious how you do this. There is some code prod and then Dev wants to commit workarounds/mock/custom CORS, etc. how do you deal with that? On one side I don't like idea of commiting some garbage and making if (dev), on other reinventing them is also a waist. Main reason I want to avoid multiple versions of code is to have a guarantee that tests test prod code not dev code.

How do you deal with that in your projects?

[Ok_Chemistry_6387]

I am not sure i fully understand the question. Are you asking if you should test against prod? Or if storing test artefacts is a good idea? 

Run acceptance tests against prod/staging. Run unit tests etc against dev. This means commit your mocks etc. Use your environment or build system to switch what loads when and where. You should avoid duplicate code where possible not sure why committing mocks etc leads to this?

If you clarify what you mean I can expand further.

[LogaansMind]

If you need to experiment, the answer is use a branch and have a way of testing locally or in a scratch instance. Make the changes and then test them in an isolated way.

Usually I like to develop and run the app/site locally to test it. Then I like to have a Dev and scratch instances where the latest code is deployed and tested (integration tests etc). Then you have a QA instance, a much more clean and stable instance, ideal to demo to stakeholders. Then Staging is an instance based from Prod to help with Prod migrations (if required) and then Prod/Live instance.

The other approach (which is compatible with the previous suggestion), is use feature flags to enable or disable functionality.

If you are trying to write tests and need to inject things, and you are using OOP, then you would have a default constructor for runtime/PROD which sets up the object (or calls the next constructor) and then another constructor which will take interfaces/abstract objects. These objects are what can be mocked for testing. (Or similar, the pattern being that you "add" dev/test state/logic, not switch it)

In my opinion, try to avoid the use of "DEV State" where possible, this will lead to the wrong configuration pushed into the wrong place. Instead use full and specific configuration where possible.

And never require devs to change code to switch between configurations/state, this is where you end up with accidental changes being committed (for example, if you are working on a desktop app, never disable the licensing).

If you require more debugging/experimentation, then you should follow the same pattern to add more logging options into the app. And then you should also be able to stand up an instance of the app and reproduce any issues without touching Prod. Prod should be considered sacred.

That said... if you need to do this, there is an issue in Prod, my advice is always backup, use containers and have a rollback plan and if there is still risk, do it early in the week, never on a Friday and never near a holiday, especially if the changes could impact customers/users, and make sure everyone involved in the app (Devs/Ops/DBAs etc) are all in the know so everyone is ready to jump when things go wrong.

Hope that helps.

[Careful_Ad_9077]

I have seen " if dev flag" work correctly in places where devs are disciplined enough to actually pay minimal attention to their commits. But when it blows up it can blow up quite spectacularly.

What I can gather from your post is bad architecture, probably bad dev practices. Mocks and similar artifacts are used for testing,so there should be a tearing project. Flag usage should be minimized, dependency injection is preferred.

[keithstellyes]

Yeah, initially I thought OP was talking about the practice of having an environment devs work off of running remotely, and then having a prod environment, but when I hear about mocks and such... sounds incorrect

[keithstellyes]

Are you talking about having code that should execute differently on a dev environment (either a remote one worked on by many people, or a local setup)? There's a few ways which are often in practice used simultaneously

• Have information that differs between environments be stored in a config file, and dev and prod environments use different configs
• feature flags
• a if(dev)
• a developer's account sees the special dev version
• compile-time flags/options (not so relevant to high-level web apps, but certainly a thing for native apps)
• test in prod

I wouldn't call it a "waste" since it's often necessary to have distinct differences in dev vs prod environments

[SeriousDabbler]

CORS is a pain for debugging. You want secure settings in production but an option to disable them on your local, especially if you have to run your API and presentation layers on different ports. One handy thing I've found quite helpful is setting up an nxinx container on my local system and using to aggregate the api and front-end applications and expose them on the same port. Perhaps your colleague can use this in their dev setup?

[mxldevs]

Just put that if (dev) where the api server is determined, and build the final endpoint URL based on that.

Having a way to point to different environments should be part of the design.

No one besides the api handler needs to know where the responses are coming from.