Shawn Melton (3/22/2013)
This can depend on how you document your systems. You do document them right? 😀I support a branch of the military, and the organization I support right now has requirements for configuration management. You basically identify each configuration item (CI) in an instance of SQL Server and then put them under version control. Version control can be done with different products, some open source and some cost money (e.g. Team Foundation Server).
I have only been with my current organization for about a year now and previous to my arrival they had nothing on the production SQL Server under proper configuration management. I am fixing that by putting the production database into a SQL Server Data Tools project, and then checking that into our configuration library. I am then taking any SSRS and SSIS project I create into the same library. So the version I end up deploying to production I will have in the configuration library. The SQL Agent jobs I have scripted out and loaded into a spreadsheet that just has some more details about each job.
The "toolbox" thing, I have most of them in my Google account online. I have heard some folks will use DropBox. I don't really tend to go out of my way to much on this because most of the scripts in my toolbox I have gotten from SSC or other SQL Community sites (SQLSkills, Brent Ozar, etc.).
I'm a one-person team when it comes to the data warehouse server. I'm the designer, developer, and the DBA. Since I have no experience in setting up a configuration library, I have no check-in check-out process in place. There is no money to purchase any tools and everything I've accumilated has come from SSC or other SQL Community sites. I'm also learning SSIS & SSAS on the fly, so I was looking for an 'easy' way (if there is such a thing) to restore any packages, code, SQL agent jobs in case I mess up a working version. That way I have something to fall back on.
Thanks for your input.