I am a software engineering professional. This is my hobby project. This leads to a funny middle ground between compromising on some things more than I would professionally and a few things that require an extra bit level of strictness.
I came up with a list of ten things I want to take into account through this project.
- Do a bit every day
- Have fun while learning
- I want a test lab for future projects
- GitOps
- Journaling
- DevBox of the week
- Testing
- CI/CD
- 80% proven tools
- Giving back
Do a bit every day
I reserve some of my free time to work on this project. It is my intention to keep a steady pace by doing a little often. I should remain hungry for the next daily portion.
I know this intention is going to fade when there is something more interesting eventually. So this practice is to gain some momentum to get somewhere by the time I can’t go on.
Have fun while learning
This is something for me alone. I want to brush up some of my existing skills while getting updated on some new tools that have appeared since I set up a cluster last.
I want a test lab for future projects
The goal of this project is to have something that I can sustain easily. The previous whack at a k8s cluster led to a setup that is hard to maintain and then it degraded until I switched it off.
The goal is to have a system where I can spin new services easily and they will be highly available.
This is possibly the hardest goal.
GitOps
If it is not in git, it does not exist. If it does not get deployed somewhere, it is not useful.
I want to write things in a text editor to a version control in order to keep all of my work safe. Unless I am strict about this and I set up anything manually, the work will be lost as soon as I forget or as soon as I can’t keep track which computer I used last when working on it.
Journaling
In order to remember what I last worked on, I need to keep notes. Some of the notes I will publish and some of them will be random working notes that remind me where I left off. I expect to be working in 30 minute blocks and that is not enough to document everything thoroughly. However, putting my decisions into full sentences is going to help me backtrack why something was done in the way it was.
Development box of the week
This is an old practice I followed strictly around the year 2013. The idea is simple: reset your entire development setup every week and start over. This goes nicely with the GitOps thinking as well.
There are several good reasons to be a bit weird about this. Firstly, the development computer gets all kinds of software, scripts, configuration files and tweaks. When starting over when recovering from a failure, some of the good parts get permanently lost. Also, the old versions of everything will take space, the Download folders will fill up with cruft that doesn’t need to be stored for the long term and the few exceptions will be impossible to find.
I will set up my development environment on a virtual machine that I can access from all of my computers. That will be yet another target in my CD pipeline.
Testing
I will be not doing a good job in testing the infrastructure. The quality target is that the system is up and I will prefer monitoring over writing acceptance tests. This would lead to horrible trouble in real life production systems, but the feedback loop will be short since it is just me and I want to get something done.
Most of the work is going to be infrastructure, but there are some pieces of software as well and those I want to test effectively. I am not going to be interested about full test coverage, but rather think about the scenarios I don’t ever want to happen and hedge against those.
Also, I am more experienced in testing than in setting up production-grade monitoring, so that is where I want to spend my time.
CI/CD
I am preacing a lot of Continuous Delivery professionally and I am one of the contributors in MinimumCD. I try to practice my preach with this project and try to achieve the stability and speed for the long term.
This means:
- I don’t need branches.
- I will need to cover rollback through canaries or blue/green.
- I will have to study feature toggling for testing in production and taking it back.
- I will have to start with pipeline work
- I will have not have the luxury of recovering from red, so my production-like test environment will have to be production in one way or the other.
80% proven tools
I am learning, but in order to actually finish something, I need to choose as much tested, stable and user-friendly tools as I can. Packaged is better than making it myself.
Giving back
I am going to be using Open Source a lot and I am going to raise any issues to the communities and send my patches upstream whenever I can.