Softwaredevelopment

I have been oncall for as long as I can remember being in the industry, so far for every organisation I have been part of. Different things have worked at different phases of the organisation and the teams priorities. I thought I would put down some notes over things which I have seen have worked well. Why do we need to have oncall rotations? Because simply put, it would help people not burn out of only being oncall unofficially over time, as they get pulled into specifics of systems which they are more aware of. ...

Over the years, there have been a lot of changes in the way, people create their virtual machines in their cloud environment. At a very primitive level, one would simply go about doing it via the cloud provider console. A couple of clicks and lo and behold. At a larger scale, people end up using automation to create these Virtual machines in the way they want them to be, given the manual nature of work would just start becoming a bottleneck in scaling quickly when required otherwise. ...

This is a continuation of the post, which details into the working of vesemir and how it goes about introducing changeset. Give it a read before continuing reading this, to allow you to gather more context on the what and the why. While this post will focus more more on how we went on with revamping vesemir for increasing it’s reliability, maintainability and modernizing it. Continuing the thread around how we did the same for Vesemir. (1/n) https://t.co/Xol0uRraJv ...

This post is a continuation of the tweet here The build and deployment pipeline for each org will be different in some way or the other, given each co will have it’s own requirements. This thread talks a bit about our virtual machine deployment pipeline (1/n) — Tasdik Rahman (@tasdikrahman) June 10, 2021 This was also cross posted originally for the gojek tech blog https://www.gojek.io/blog/introducing-vesemir-gojeks-virtual-machine-deployment-service The build and deployment pipeline for each org will be different in some way or the other, given each co will have it’s own requirements. Even in my last org, the way our team enabled other teams to ship code/config changes, was pretty different from the way we do it in my current org. ...

This post is a continuation of this tweet here. We recently encountered a bug in our deployment flow, which we were completely oblivious to. (1/n) — Tasdik Rahman (@tasdikrahman) June 5, 2021 Bugs are present in every system, waiting to be discovered. As such, this one was no different. What did the bug do? Would cause an application to be deployed again and again, even though when it had been triggered only once to be deployed. ...

As with time this doc will change, but jotting my thoughts down here on what I feel I would like to avoid while I review PR’s. Code formatting/style suggestions I believe it’s best left to the machine to do this instead of a human trying to fixate their attention to this, given it takes away the precious time of the reviewer which could be diverted to review the crux of the changes which the submission tries introducing. A code formatter should ideally pick this step up from the human reviewers’s plate. An opinionated code-formatter/linter/style checker is the best option to have. An example for this will be gofmt/linter which weeds out code formatting issues right in the build/test step. rubocop is another great example. ...