I’d like to start doing a better job of tracking the changes I made to my homelab environment. Hardware, software, network, etc. I’m just not sure what path I want to take and was hoping to get some recommendations. So far the thoughts I have are:
- A change history sub-section of my wiki. (I’m not a fan of this idea.)
- A ticketing system of some sort. (I tried this one and it was too heavy. I’d need to find a simple solution.)
- A nextcloud task list.
- Self-host a gitlab instance, make a project for changes and track with issues. Move what stuff I have in github to this instance and kill my github projects. (It’s all private stuff.)
I know that several of you are going to say “config as code” and I get it. But I’m not there yet and I want to track the changes I’m making today.
Thanks
Best thing i did was creating a git repository just for my local environment and set up.
Granted I did switch over to kubernetes and helm, so that was good. Kick start where everything is laid out and simply YAML files, but even more important than that was setting up readme files for all my major systems.
I want to say it’s now hundreds of times. I’ve gone back and reread those read me files, the random fixes I had to come across, common error codes that I needed to fix, setting up new boxes, the list goes on. On. Having one central place where I can edit and update those readmes has been a godsend. Plus I run gitea so it then formats those in a nice way for me automatically.
Not to mention the dozens of scripts and random snippets of code I’ve needed to save to help me run my local lab.
I do have a couple github repos for various things (ansible, scripts, dns). My plan for general documentation is the wiki. I’ve started the work on that but it’s far from complete (those get saved in markdown and synced to github). Maybe the simplest solution is the one I’m avoiding. Just putting it all in a readme/changelog.
I would encourage you not to split things up too finely. A single repo for your environment would allow you to see all related changes with git. E.g. if you set up a new VM it might need a playbook to set something up, a script to automate a task, and a DNS entry. With a well put together commit message explaining why you’re making those changes there’s not much need for external documentation.
Maybe if you want some more info organised in a wiki, point to the initial commit where you introduced some set up. That way you can see how something was structured. Or if you have a issue tracker you can comment with research on something and then close the issue when you commit a resolution.
Try not to have info spread out too much or maintaining all the pieces will become a chore. Make it simple and easy to keep up.
I think you’re right on this point. I have a tendency to over-complicate things and that leads to them getting scrapped or neglected.