Looking for feed back on migrating code with save/restoreToPipeline in the code but disabled.
I have a client that insist that is an proper/risk to keep this in production code.
I like to keep them in in case some situation arises in product where I need to troubleshoot.
Their reasoning is that if it test in QA properly that there shouldn’t be any reason for them in PRD. Their suggested procedure is remove them, migrate the services to QA, and then put them back in DEV if needed.
I disagree with this and think disabling them is enough.
What does the community think, what do you do?
Looking forward to the comments.
There is on harm in leaving these in the code except perhaps the code looks like it is under construction.
I like to put them in branches and have a debugOn (BOOLEAN) that I switch at runtime. So, if there is a problem, at least you can catch. Same with Save/Restore.
The greatest argument for leaving them in is the time savings when debugging in a production environment. Everyone says “we can’t do it that way!” but when the system is down, all the rules go out the window and you just fix it.
I like Ray’s idea. If there were a way to retrieve the debugOn boolean from a (custom) properties service you could update the value of the debugOn property for that service and refresh the properties cache. This would require a configuration change in production to get your debugging information but the code would always be enabled and not disabled.
You’d need a service that retrieves and caches propeties from a file or database table and a service that refreshes the cache on demand. Lastly, you’d need an easy (and safe) way to update a property (in this case the debugOn property for the service in question.
Perhaps that approach would give you the best of both worlds, no commented out (disabled) code and short time to turn on savePipelineToFile. The tradeoff is a little more time to build a common properties service that caches its data and the time to create a simple gui to maintain the property and force a cache refresh.
Another approach is make use of the logging levels available through the admin console.
We created “wrapper flows” around the debugLog called debug, info, warn, and error. Within each flow we set a different log level. In dev,qa, prod etc… you can set the logs to the appropriate level as you require.
In practice - our info logs are extremely valuable in tracking down a problem in production.
I’m not sure I like the idea of leaving save/restoreToPipeline in production code, as it has the potential of inadvertantly affecting the behavior. If you forget to disable the code as you migrate up - its trouble. Its a great tool for dev - but I would take them out prior to migration.
My recommendation would be to use logging levels and remove the save/restoreToPipeline from code.
You could also use the pub.flow:tracePipeline service, which also supports the logging level. You would always have these tracePipeline enabled in the code and the logging level of debug (4 or higher). If you need the debug information in production you just increase the level temporarily through the admin console.
Chris, I agree with the comments above. On our projects we have used the approach mentioned by Haithem. We had a logging (wrapper) service (log4j) and used log levels (DEBUG, WARN, ERROR, INFO). We could turn logging on and change the log levels at will.