Is anyone planning on installing/utilizing NaturalOne in their production environment in addition to their Test & Dev? I’m curious to know if there is a way to lock it down completely to prevent any updates to data or program code. How difficult would this be and are other companies doing this?
We utilize N2O to migrate program changes from Dev to TEST to Production and do not allow our programmers to make any program changes without it. The only con i can think of is that a programmer won’t be able to modify the source code for an online program they are trying to troubleshoot. For example edit the code with a few write statements to look at the data that is being read but without stowing the code. This would expedite the trouble shooting process without having to migrate the code to TEST via N2O and then try to recreate the issue with similiar production data.
Without NaturalOne on production, programmers will still be able to log onto the mainframe to use the list command to view program code, DDMS, KEYS, etc. This can be useful and perhaps all that is really necessary from a production environment?
Hi there,
From your question, I think you have answered it yourself. You have strict methods for deploying to production, so you should ensure you enforce that. Having a direct link to manipulate production kind of defeats the purpose.
Regarding having a ‘production reference’, do you version your code (eg GIT or SVN)? {Hint: This will solve your problem}
I think this is more important to track every change, have the ability to instantly revert to a point of time and analyse changes.
Developer’s simply then can reference the current “in production” suite of modules for interaction and problem resolution.
There are so many benefits from versioning code, I cannot stress enough, there is no excuse good enough not to use a modern code repository (no matter what you code in)!
Additionally, there are so many benefits from having all your code in a repo (some examples: trawling through your code in it’s entirety from a single mouse click, scanning for strings/variables instantly and locally on your pc, subprogram testing, test suites…).
As much as fixing things in production with actual production data ‘seems’ like a good idea, it is not valid, and you are potentially destroying the integrity of your system by doing so. If anything, add logging functionality to your production applications, build better test suites to pull production data and scramble it in lower environments more easily. You will find everyone will benefit a great deal more from excellent tests and test harnesses/systems rather than on the fly ‘undocumented’ production fixes.
On the N2o note:
We too use N2O, It is excellent at what it does, but can take a little time.
I have developed a web interface to manage and maintain or modules and deploys in conjunction with N2O. I am going to open source this web based system soon (people who use it will need EntireX & a Tomcat server to deploy the web application to). We now have deploys from created events from a single press to one of our many environments (we have 12 at our work site). I’ll stick the PDF of the system soon.