You don’t have to be specific on what will be done, but certainly don’t do anything without informing the client. First of all, let your client know that you will connect to the production system and “perform some checks”. Some basic guidelines before you get started.
#Eclipse script debugger how to#
So, if you decide to take the risky road, read along on how to do it. Be sure that the slightest wrong move while on production server (which serves a large number of users) could massively affect the application and cause even bigger problems or a complete service outage. Note that this should be considered as a last resort and when all other attempts to spot the bug have failed. What a poor developer should do? Debug the application that runs on the production server. The bottom line is that you cannot track the bug down using your testbed. Alas, everything runs correctly on the test server, so it might be a strange configuration issue or an edge case that causes the problematic behavior. You start up the test server and try to reproduce the bug. The client’s users pressure the client, the client managers pressure your managers and, guess what, your managers start pressuring you. It seems that some nasty little bug has managed to get through all the testing procedures and make it to the live system.
Your client notices some buggy behavior on the application and some of his customers have already started complaining. Thus, your awesome code is now up and running on the production server. Unit tests were all successful, testers found some minor bugs that were immediately fixed, the integration tests with the other department’s modules went pretty smoothly, the QA department made no complaints and the UATs were passed with flying colors. So, your application is ready for deployment. For the rest of us, mere mortals, who do write code with bugs, I would like to address a very sensitive issue: debugging an application that runs on a production server. Do you write code that has bugs? No, of course not.
0 kommentar(er)
