• 0 Posts
  • 4 Comments
Joined 10 months ago
cake
Cake day: June 11th, 2025

help-circle
  • It depends on what it is. I do not have a singular documentation-platform or wiki for those things. I’m more of the keep the docs where the code is guy. I also try to keep complexity to a minimum.

    All my linux server setups are done with ansible. ansible itself is pretty self-documenting, as you more or less declare the desired outcome in YAML form and ansible does the rest. This way, I do not need to remember it, but it’s easier to understand when looking it up again.

    Most of my projects have a git repository, so most of what I need to know or do is documented

    • in a README.md
    • as pipeline-instructions inside .gitlab-ci.yml

    This way, I was able to reduce complexity and unify my homelab projects.

    My current homelab-state is:

    • most projects are now docker-based
    • most projects have a GitLab CI for automated updating to newer versions
    • the CI itself is a project and all my CI-docker-based deploys use this unified pipeline-project
    • most projects can be tested locally before rolling out new versions to my VMs
    • some projects have a production and a staging server to test
    • those which cannot be dockerized or turned into a CI are tools and don’t need that (e.g. ansible playbooks or my GitLab CI)

    On what to include, I always try to think: Will I still be able to understand this without documentation if I forget about the project for 6 months and need to make a change then? If you can’t be sure, put it in writing.

    If it’s just a small thing regarding not the project itself or the functionality or setup itself but rather something like I had to use this strange code-block here because of XXX, I’ll just put a comment next to the code-line or code-block in question. These comments mostly also include a link to a bug-report if I found one, so i can later check and see if it’s been fixed already.