none
Development to Testing Environment RRS feed

  • Question

  • I have an upcoming project that I had some, hopefully simple, questions. The project calls for a development environment. In this environment the developers will do their best effort to get the project finalized. Once the development environment is settled, it will be replicated in a end user testing environment. The testing environment will be tested by high end users. Then if blessed the environment will be replicated to a live environment. If not blessed then the dev site will be edited and tested. The process will start over and be moved to the testing site. I do not see any way to take the dev environment and append the next level environment without losing data. Both of the Farms will be using same SQL server. There will however be two web front end servers for each Farm. I only see a manual reproduction. My thoughts on this is that the dev environment will have to be created and good change logs will need to be kept to reproduce the environments. Please interject with any helpful tips.

    Thanks in advance



    Jeff Tucker Engineer

    Tuesday, July 14, 2015 7:24 PM

Answers

  • Hi,

    Setting up the servers is one time job. Once it's been setup in dev, test and prod; it's done. you can automate the dev/test/prod installation with AutoSPInstaller. The idea is if you need another dev server just like an existing one.. you can create the first dev with AutoSPInstaller - which is basically xml/powershell package to automate SharePoint Installation/configuration. You can then reuse the xml/powershell package to recreate the environments.

    Now once the environment is created and developers has developed/changed something and you would like to move to different environments, few things might happen:

    • SharePoint WSP solution can be used to package changes and deploy using scripts. For example developers can develop the WSP to deploy styles/js etc and then deploying the package in dev/test/prod will deploy the changes
    • Sharepoint Site changes in dev can be applied to test/prod by automating the changes. For example if a developer has changed the site title, that should be replicated to test/prod using PowerShell
    • Site Data can be a bit tricky. For example in dev, developer has updated some data or uploaded a document that needs to migrated to test/prod then that should be assessed carefully. In most cases data should be not be flow through dev to test to prod. If there's any data import job (like during development need to import data in dev and then the need to moved to prod) that should be automated so that just running a script will apply the changes in another environment.

    So long story short, automation is the key. You should not just copy data from dev to test/prod. That should be developer/architect's responsibility to make sure the data migration is considered as part of the project.


    Thanks,
    Sohel Rana
    http://ranaictiu-technicalblog.blogspot.com

    Wednesday, July 15, 2015 3:46 AM

All replies

  • Hi,

    Setting up the servers is one time job. Once it's been setup in dev, test and prod; it's done. you can automate the dev/test/prod installation with AutoSPInstaller. The idea is if you need another dev server just like an existing one.. you can create the first dev with AutoSPInstaller - which is basically xml/powershell package to automate SharePoint Installation/configuration. You can then reuse the xml/powershell package to recreate the environments.

    Now once the environment is created and developers has developed/changed something and you would like to move to different environments, few things might happen:

    • SharePoint WSP solution can be used to package changes and deploy using scripts. For example developers can develop the WSP to deploy styles/js etc and then deploying the package in dev/test/prod will deploy the changes
    • Sharepoint Site changes in dev can be applied to test/prod by automating the changes. For example if a developer has changed the site title, that should be replicated to test/prod using PowerShell
    • Site Data can be a bit tricky. For example in dev, developer has updated some data or uploaded a document that needs to migrated to test/prod then that should be assessed carefully. In most cases data should be not be flow through dev to test to prod. If there's any data import job (like during development need to import data in dev and then the need to moved to prod) that should be automated so that just running a script will apply the changes in another environment.

    So long story short, automation is the key. You should not just copy data from dev to test/prod. That should be developer/architect's responsibility to make sure the data migration is considered as part of the project.


    Thanks,
    Sohel Rana
    http://ranaictiu-technicalblog.blogspot.com

    Wednesday, July 15, 2015 3:45 AM
  • Hi,

    Setting up the servers is one time job. Once it's been setup in dev, test and prod; it's done. you can automate the dev/test/prod installation with AutoSPInstaller. The idea is if you need another dev server just like an existing one.. you can create the first dev with AutoSPInstaller - which is basically xml/powershell package to automate SharePoint Installation/configuration. You can then reuse the xml/powershell package to recreate the environments.

    Now once the environment is created and developers has developed/changed something and you would like to move to different environments, few things might happen:

    • SharePoint WSP solution can be used to package changes and deploy using scripts. For example developers can develop the WSP to deploy styles/js etc and then deploying the package in dev/test/prod will deploy the changes
    • Sharepoint Site changes in dev can be applied to test/prod by automating the changes. For example if a developer has changed the site title, that should be replicated to test/prod using PowerShell
    • Site Data can be a bit tricky. For example in dev, developer has updated some data or uploaded a document that needs to migrated to test/prod then that should be assessed carefully. In most cases data should be not be flow through dev to test to prod. If there's any data import job (like during development need to import data in dev and then the need to moved to prod) that should be automated so that just running a script will apply the changes in another environment.

    So long story short, automation is the key. You should not just copy data from dev to test/prod. That should be developer/architect's responsibility to make sure the data migration is considered as part of the project.


    Thanks,
    Sohel Rana
    http://ranaictiu-technicalblog.blogspot.com

    Wednesday, July 15, 2015 3:46 AM
  • Thanks for the input Sohel. I will try this on my next project and vote on your answer. I will be doing the project within the next couple weeks.

    Jeff Tucker Engineer

    Thursday, July 16, 2015 8:00 PM