Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Design and Architecture
  4. Setting Up Client Test Environments

Setting Up Client Test Environments

Scheduled Pinned Locked Moved Design and Architecture
databasecsharpwpfsysadminhelp
3 Posts 3 Posters 10 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K Offline
    K Offline
    Kevin Marois
    wrote on last edited by
    #1

    I have been working on a WPF app for a client for 3 years. They have someone on site who verifies changes I make. What I've been doing up to now is making a copy of the SQL datbase on their server, restoring to a test DB, and appling any SQL changes to it. I then copy all test files to their system into a test folder. The have a Test Mode icon on the desktop which allows them to run the test environment. Once all changes are verified I repeate the above for their Production environment. This has worked well, but I'd like to have a way to test different changes independently. A test environment for each branch would be nice, but that means duplicating what I wrote above for each new branch. Something really easy to set up and take down as branches change would be great. I'm open to ideas.

    If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.

    J J 2 Replies Last reply
    0
    • K Kevin Marois

      I have been working on a WPF app for a client for 3 years. They have someone on site who verifies changes I make. What I've been doing up to now is making a copy of the SQL datbase on their server, restoring to a test DB, and appling any SQL changes to it. I then copy all test files to their system into a test folder. The have a Test Mode icon on the desktop which allows them to run the test environment. Once all changes are verified I repeate the above for their Production environment. This has worked well, but I'd like to have a way to test different changes independently. A test environment for each branch would be nice, but that means duplicating what I wrote above for each new branch. Something really easy to set up and take down as branches change would be great. I'm open to ideas.

      If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.

      J Offline
      J Offline
      jschell
      wrote on last edited by
      #2

      The above is not all that clear. Perhaps because the process has not actually been defined.

      Kevin Marois wrote:

      What I've been doing up to now is

      This is a 'deployment' or a 'release'

      Kevin Marois wrote:

      A test environment for each branch would be nice,

      Ok but what does that have to do with a 'deployment'? Generally a branch is used to work on feature/fix/etc. So lets say right now there is a new feature and two bug fixes that you need to work on. I am going to presume you are using source control. So locally you can work on each as a branch. When a branch is complete then you merge it to the main branch in source control. You only 'deliver' the main branch. So if you have finished the feature and one bug when you decide to deliver than you using the main branch to do that. The other bug is in the branch that is not complete and not merged. Items in the above 1. Depending on how you deliver it you might need to rebuild the main branch. This is a process step that you would need to do. Probably should have an actual list of steps. Important step is that you should always extract from main branch even if you think it is already there. 2. SQL, or however you update the database, should be checked into source control also.

      Kevin Marois wrote:

      now is making a copy of the SQL datbase on their server,...

      Steps for testing 1. Create test database. Specific steps are irrelevant. 2. Apply NEW updates the test database. 3. Deploy NEW application to test folder. Specific steps are irrelevant. 4. The icon on desktop to test Steps for production 1. Apply NEW updates the real database. 2. Deploy NEW application to real folder. Specific steps are irrelevant. In the above the two steps match the appropriate previous steps except that it applies to a different destination. So you can certainly automate that using a script (linux or windows.) You can also create an application (installer) to do the same thing. Don't forget potential errors. For example someone accidently marks a file in the real folder is read only and so your script/installer can't copy the new file in. Might just be a matter of manually inspecting the output but there are other ways.

      1 Reply Last reply
      0
      • K Kevin Marois

        I have been working on a WPF app for a client for 3 years. They have someone on site who verifies changes I make. What I've been doing up to now is making a copy of the SQL datbase on their server, restoring to a test DB, and appling any SQL changes to it. I then copy all test files to their system into a test folder. The have a Test Mode icon on the desktop which allows them to run the test environment. Once all changes are verified I repeate the above for their Production environment. This has worked well, but I'd like to have a way to test different changes independently. A test environment for each branch would be nice, but that means duplicating what I wrote above for each new branch. Something really easy to set up and take down as branches change would be great. I'm open to ideas.

        If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.

        J Offline
        J Offline
        jochance
        wrote on last edited by
        #3

        Flyway... I'd use Flyway. Whether using repeatable migrations or versioned + undo you could accomplish what I'll call "feature-branched DB state management" which is what it sounds like you want.

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups