Status Quo of Test Environment Debugging It is common to hear complaints such as "a bad test environment affects developing efficiency". Due to the difference between deploying environments, it is believed that a lot of developers face various problems in the test environment, despite the fact that the code has run smoothly during local testing. We may start to wonder: what if debugging is available in the test environment? In the meantime, the debugging tools in the test environment are rather monotonous. Developers usually derive contextual data from the logs, analyze the parameters from it, and reproduce the bugs locally. However, there may be more bugs coming out of it. First, you will have to surf through the log system for the exact contextual data, but the bugs could be something occasional - that means you will have to execute it multiple times to find them. In the ideal situation, you are lucky enough to have the log output and the problem analyzed out of the contextual data at the same time. But the reality could be a lot harsher - the logs may not reflect the problem and we might even miss recording them. We will have to modify the code by adding log, deploy, execute, derive and finally viewing it. The steps are repeated multiple times so that the bugs could be reproduced. We will start dreaming about debugging in the test environment again. Solving problems would be much easier if we could casually debug in the local interruption points and check on the contextual parameter in real time. Debugging with KubeOrbit Your colleagues may have been debugging on local interruption points when you are still struggling with the contextual data line by line. Test environment debugging has never been so relaxed by using KubeOrbit. You could forward the target service to your local interruption points for debugging whenever you want and check on the contextual data. Forget all those mess in the previous test environments, nothing is a problem in KubeOrbit. It feels elegant using . There is only one command after starting the local service: KubeOrbit ./orbitctl forward --deployment portal-service-deployment --namespace apps --containerPort 9000 --localPort 9000 You will see the prompt below after starting it: When you access the test environment now, you will find that all requests are forwarded to the local service. You can check the variables locally and use the build-in auxiliary functions in IDEA to identify the problems swiftly. Breakpoints could be set to rapidly identify the occasional bugs. You can even modify the code locally to observe the changes until the problem is solved. When you decide to terminate the local debugging, just enter the following command: ./orbitctl uninstall --deployment portal-service-deployment --namespace namespace-a The whole process was simple and flexible. User Experience and Personal Suggestions However, when my colleagues and I were using , we found that KubeOrbit can only enable one local service at the same time. Hence, we will have to queue when we are developing different demands for the same service, and we need to locally debug the problems in the test environment at the same time. KubeOrbit However, this is still better than the traditional way - checking on logs for contextual data to solve the problem. We hope that KubeOrbit will allow parallel tests and multiple local usages within a service in the future. It would be best if there was a visualized control deck to manage the service status. Also published here.
