In numerous projects I have seen development environments that resemble nothing like production. Only to result in a problematic transition through the ALM process, bugs caused by inconsistency, significant differences in SharePoint updates, configuration and even permissions.

I am not saying that you shouldn’t write your app to “expect a specific configuration” or to avoid best practices around handling configuration issues. However, to reduce issues down the line, as a minimum, environments should be setup with the following:

SharePoint version and patch level must match production

I cannot stress how important this is, Microsoft WILL change things, that is a given from user feedback and product improvement. Do not assume that SSOM, CSOM, Rest API’s, JavaScript libraries and visual layout will remain the same regardless of SharePoint updates. The further apart each environment in terms of updates, the increased risk that functionality you could be utilising may not work as you transition your code from Development to Test/UAT to Production.

By keeping the environments aligned at the version and patch level:

  • You can expect that what is provided in the platform level resources are the same in that of your other environments in terms of API’s, front end resources and SharePoint farm functionality.
  • You have the ability to create a test environment patch level that is ahead of the production to access whether your code will break in updates/features packs/service packs.
  • You have the ability to extract or use a backup from production to make your development environment true to what your solution would resemble like when it has gone live.

Good resources for checking your patch levels: Todd Klindt’s SharePoint 2013 Build Numbers

Develop knowing user permission perspectives

As developers, typically you would be building solutions, where you have site collection administrator or high privileges. I am not disputing what access you should have in a development environment but when you are building solutions that involve multiple end users, it is important to include in your development system the varying permission levels (where appropriate), groups and sample user accounts.

Your code/solution may require users to have specific permission levels in order to perform the task your solution is supporting. By building this into your development machine early, you can see pretty quickly if you code will work for the intended end user.

Browser sessions with SharePoint do not make it easy to test this scenario, however by installing multiple browsers, such as Chrome, Firefox (those that are supported fully by the platform: Supported Browsers in 2016), you can login for each browser, different users. With the supported browsers (Edge, IE11, Chrome, Firefox), you can theoretically login as much as 8 users at once with each browser and with their private/incognito modes.

Configuration should be relevant or similar to production and when NOT to be

When writing your solution for a specific business reason, you want to ensure that your application will work in that scenario. I recommend that the configuration or partially some of the data (where appropriate) is duplicated in your SharePoint development area to ensure that the solution will solve the particular problem. Depth of replication is your call but the more accurate the better.

As a counter argument, it is also a good idea to have a vanilla/clean area to verify your application outside of the expected configuration. Inevitably, the expected configuration will change potentially outside of your visibility, therefore you want to anticipate that your application will continue to work or fail gracefully if power users or admins change SharePoint structure or configuration.

Test Environments should contain update to date replicas of production data

To effectively test your solution in the closest approximation of production, you will need to be prepared to clone the data or part of the data from production.

This can be utilised from backups then restored into your test environment, this way you can verify your solution will work exactly and will not have impact to existing data or configuration. However, it is recommended to:

  • Ensure that not only the data is present, but the topology as well. Ensure that you have the same service applications present in test, to ensure that the backup restores will operate correctly when there are dependencies on services, it is understandable that this may not contain the same scale, but the closer the better.
  • Patch levels and versions are identical to production, you cannot restore backups into an older patch version of SharePoint, this must be equal or newer.
  • Be sure to label your environment! Duplicating environments will look the same with the exception of the URL. If you have end users, stakeholders or business owners that UAT your solutions, mark the environment. A common issue around environment replication is HARD CODED URLS, typically in the content/links/navigation that still point to production locations, by simply clicking around an environment can switch environments before you know it, remember they look the same. To find how to do this in this blog post written by Wictor Wilen.
  • Data in UAT/Test environment is temporary, treat as such! Expect your changes to disappear, typically I would recommend to update test environments after a major release or significant change to production or have regular data refresh intervals to keep the environment closely similar to production.

I have seen time and time again all of these issues mentioned above, simply because the fundamentals of setting up development environments for SharePoint are not correct.

This is not an exhaustively list and I love to hear your thoughts on the subject in the comments as a guide to others that have experienced similar issues.