Re^5: [RFC] Review of module code and POD

in reply to Re^4: [RFC] Review of module code and POD
in thread [RFC] Review of module code and POD

If the code has access to the file that holds the sensitive information then surely the developer has access to the contents of that file either directly or through their code.

The developer is not developing on the production system^* and therefore does not have access to either the production DB credentials or indeed the production DB itself. Putting this in a config file which is just data and not something to be executed allows the developer to test on the dev system with the dev DB credentials and the dev DB without any leak of sensitive information. All the code may be shared between development and production quite safely and only the config files (which are now not code) are kept separately.

^* If that isn't the case then stop whatever it is you are doing and set up a separate system just for development. Never develop on production.

🦛

Comment on Re^5: [RFC] Review of module code and POD

Replies are listed 'Best First'.
Re^6: [RFC] Review of module code and POD by Bod (Parson) on Apr 04, 2021 at 11:33 UTC
The developer is not developing on the production system and therefore does not have access to either the production DB credentials or indeed the production DB itself* Got it - that was the missing piece of my understanding...thanks! If that isn't the case then stop whatever it is you are doing and set up a separate system just for development. Never develop on production I have a test site set up for every domain and for shared offline tools. The test site has a structurally identical database that it connects to and the code is exactly the same except for the bit being developed. The only difference in the code is a single file holding variables such as the database credentials and other stuff such as payment gateway details and variables controlling what notification emails get dispatched and which environment is being used. Historically, this file has been `variables.pl` and pulled in with a `require` statement but slowly this is being refactored to `use Bod::Variables;`. As I don't really need to hide production database credentials from myself, this is perhaps sufficient for the moment but as things get updated I will look to change things. I was thinking that if and when I employ a junior developer, they will have no access to the production environment and only I will copy updated scripts from test to prod. We also spin up a dev environment when there are any longer term projects like the current refactoring. This allows test to be used for minor changes without tying it up completely during the current project. The dev environment generally shares the test database. Is this a sensible approach or should I be incrementally moving towards something better>	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^6: [RFC] Review of module code and POD
by Bod (Parson) on Apr 04, 2021 at 11:33 UTC

The developer is not developing on the production system* and therefore does not have access to either the production DB credentials or indeed the production DB itself

Got it - that was the missing piece of my understanding...thanks!

If that isn't the case then stop whatever it is you are doing and set up a separate system just for development. Never develop on production

I have a test site set up for every domain and for shared offline tools. The test site has a structurally identical database that it connects to and the code is exactly the same except for the bit being developed. The only difference in the code is a single file holding variables such as the database credentials and other stuff such as payment gateway details and variables controlling what notification emails get dispatched and which environment is being used.

Historically, this file has been variables.pl and pulled in with a require statement but slowly this is being refactored to use Bod::Variables;. As I don't really need to hide production database credentials from myself, this is perhaps sufficient for the moment but as things get updated I will look to change things. I was thinking that if and when I employ a junior developer, they will have no access to the production environment and only I will copy updated scripts from test to prod.

We also spin up a dev environment when there are any longer term projects like the current refactoring. This allows test to be used for minor changes without tying it up completely during the current project. The dev environment generally shares the test database.

Is this a sensible approach or should I be incrementally moving towards something better>

[reply]
[d/l]
[select]

In Section Meditations