Cleaning Up Old/Test Solutions & Projects, and not Screw Oneself

  • Hello,

    I'm new'ish to SQL Server and taking over an new/recent SQL Server 2012 with SSIS and SSAS, and VS 2013 w/DT. All development, testing and production occur on this one instance. Running a Tabular Star Schema model.

    When I open VS, and go to File, Open, Project/Solutions, I get a lengthy list of old/previous projects and solutions. I have to poke around to see which one I'm after to get the "right/latest one". For example, if I need to open the latest solution for DailyCubeX, I'll hunt for DailyCubeX folder, go in, and double click the .sln file. But, there is DailyCubex_10272016 folder, and DailyCubex_10262016 folder, and DailyCubex_10252016 folder, etc... Can I delete these older folders? Can I delete all of them and not screw myself or screw up something in production? What is the recommended method to delete these excessive older folders that are adding up and trashing the joint?

    Also, it seems that if I needed to get the entire latest solution that is in production to say implement a new change, I think I don't even need to go to an old/previous folder, but a better practice would be to go open VS, File, New, Project, Integration Services, Integration Services Wizard, etc... Can someone please spell out the standard practice of pulling out of Production a new solution package to work on. Also, when done, and deployed, what is the practice on keeping the old solution, just keep one of the latest around, and delete the others?

    Thanks,

    JPQ

  • quinn.jay (10/27/2016)


    Hello,

    I'm new'ish to SQL Server and taking over an new/recent SQL Server 2012 with SSIS and SSAS, and VS 2013 w/DT. All development, testing and production occur on this one instance. Running a Tabular Star Schema model.

    When I open VS, and go to File, Open, Project/Solutions, I get a lengthy list of old/previous projects and solutions. I have to poke around to see which one I'm after to get the "right/latest one". For example, if I need to open the latest solution for DailyCubeX, I'll hunt for DailyCubeX folder, go in, and double click the .sln file. But, there is DailyCubex_10272016 folder, and DailyCubex_10262016 folder, and DailyCubex_10252016 folder, etc... Can I delete these older folders? Can I delete all of them and not screw myself or screw up something in production? What is the recommended method to delete these excessive older folders that are adding up and trashing the joint?

    Also, it seems that if I needed to get the entire latest solution that is in production to say implement a new change, I think I don't even need to go to an old/previous folder, but a better practice would be to go open VS, File, New, Project, Integration Services, Integration Services Wizard, etc... Can someone please spell out the standard practice of pulling out of Production a new solution package to work on. Also, when done, and deployed, what is the practice on keeping the old solution, just keep one of the latest around, and delete the others?

    Thanks,

    JPQ

    Hello again. I'm pretty sure that I've mentioned this in previous threads, but the current 'best practice' way of managing solutions across production / QA / dev environments, and maintaining a comprehensive version history, is by using source control.

    There is no direct link between your old solutions and what is deployed, so this stuff can be archived away somewhere without affecting what is deployed.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • [/quote]

    Hello again. I'm pretty sure that I've mentioned this in previous threads, but the current 'best practice' way of managing solutions across production / QA / dev environments, and maintaining a comprehensive version history, is by using source control.

    There is no direct link between your old solutions and what is deployed, so this stuff can be archived away somewhere without affecting what is deployed.[/quote]

    This is on the list, and trying to to find which corp tool to use for it, but in the meantime, I have to clean this up, and would like it cleared out before I implement fresh clean version control and not keep old spent solutions and projects about.

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply