Sometimes the deadline is yesterday or sometimes your boss wants the change now. Maybe the clients have an important feature that he thought he could do without dev but realised one day before the big marketing splash what he wanted to do is not working.
These changes are easy, no problem. I will do it in a flash. By now you probably know the story, it’s not easy to simply go fast, we forget basic things or completely forget (or even worse forgo) testing a critical part of the system that change might have an impact on.
Fast forward today I relived that exact situation and honestly it’s not my first time, but I get caught every time. Recently I made a simple script that updates some content in the db. Easy peasy, worked fine in my local db. I put up the PR and then fixed for some part the others have commented on and then merged on the main branch. Once the service was pushed to dev, it was in a crashloopback. It was because the dev db had way more data to process than my local db. The script would still be running when the health probe would check if the service was running and would stop the service since it wasn’t responding.
I made the fix then pushed it after running around to find someone to approve off-hour. Once the fix was pushed, it crashed again, but this time because the dev db had some corrupted data that would stop the script. I fixed the script to cover that edge case to then released it again. Beyond and behold, someone else merged right after so the server restarted before finishing the script. I’ve republished the script and finally, after three days, it was running and working on dev environment.
Notice that if I had backup the dev db and restored it on my local one I would probably have found all these problems. Perhaps in the initial pull request if I waited a bit for more dev to review it the problem would have been noticed earlier and fixed beforehand. If I’ve checked if other pull requests for the same service are ongoing there wouldn’t be a merge right after the script is merged.
That’s why when you need to go faster you must first go slower. You want to quickly deliver that api to the client, give them an example of the expected json first before starting any code. Do pull requests with only the change in the swagger file so others can review if everything makes sense. The time you take before will be time you save later down the line.
Recent Comments