> Typically, I use a wiki with lots of links, and copies of any custom scripts I made, but it's not a comprehensive solution, and possibly error-prone. I've do

> Typically, I use a wiki with lots of links, and copies of any custom scripts I made, but it's not a comprehensive solution, and possibly error-prone. I've done the same for far too many projects, both existing and green field, and always ran into the same issues: - manual sync (even if reporting is scripted) of every detail, info always ends up stale and often causes more issues from someone inevitably following it as a reference. - additional overhead and maintenance, tied closely to the point above. - stale / unaccessible links (file server accounts, etc...) - change history and supporting multiple versions / environments in parallel I've come to the personal conclusion that it's easier and faster to bite the bullet and spend the time on your build and deployment steps, with the points you listed in mind. With a Jenkins server, you could create a project that simply watches your current build directory and creates a new Build with its own Version Number, and a single archive as a Build Artifact containing your changes, including the current versions of your config files, required packages, setup scripts, and possibly a current snapshot of any relevant documentation. This gives you visibility of exactly what was contained and possibly run (if your setup/update is scripted) for each deployment / update you perform. You can build on this over time until it contains all the info you require about a particular snapshot of your stack. Next, you can build a list of your servers (and environments) and track which Build from Jenkins you've installed to each. (I believe Jenkins has plugins for that, but could be tracked elsewhere)