What Counts As SharePoint Development?

At the recent SharePoint Saturday Austin, I spoke with a peer who was working with a client that didn’t have a development environment, only a production environment.

“No,” I said. “If they don’t have a separate development environment from their production environment, they don’t have a production environment, there is only a development environment.”

A very common way to design a SharePoint ecosystem that protects end users from harmful alterations or interruptions to access to their data is to have three SharePoint farms  – Development, Staging and Production. Changes are made to the development environment, moved into the staging for validation to make sure it won’t cause problems before ever being allowed into the production environment. Another common configuration has only two farms, with both development and testing in one farm, and production in another. This requires less maintenance and hardware, but can result in a testing environment that may be a poor match for the production environment (though it beats not having a production environment!).

But the nature of SharePoint is a collaboration platform.  This means that changes are being made to production environment by end users.  End users often have the rights to change page layouts, add and remove web parts, and do many other things that make alterations to the production environment. While there are built-in features to provide data stability, such as document versioning, approval workflows, and publishing processes, it does point up the slippery slope of what counts as “development” and what doesn’t.

Here is one of the approaches I have used to keep some control of the kinds of changes that can be made directly in production without prior validation, and what needs to go through a defined testing and promotion process.

Things that can be created in production, without going through the defined testing and promotion process:

  • New pages.
  • New documents and list items.
  • Modification to pages involving addition, reorganization and removal of web parts, or the editing of content.
  • Changes using approved templates, such as lists, libraries and sites.

Things that are required to go through the defined process:

  • Modification of pages involving JavaScript, jQuery, CAML queries, and other scripting options.
  • New web parts.
  • Custom development.
  • Changes to master pages, CSS and other design elements.
  • Changes to templates.
  • Patches to operating system and SharePoint.

The Defined Testing and Promotion Process:

  1. Changes are made to a development environment.
    1. If the development environment is a single-server farm (for instance, a local virtual machine) and the ecosystem also had a multi-server development farm, the developer must push the changes to the multi-server development farm and verify the solution before given approval to promote to the Staging Farm.
  2. Approved changes in the development environment are promoted to the staging farm for User Acceptance Testing
  3. Approved changes in the staging farm are promoted to the production farm in a manner consistent with minimizing impact to users.

Does your environment have a defined testing and promotion process? Do you allow some of the things I have identified as “development” to occur in your production environment? Are you more restrictive than the guidelines I have set? Do you even have a production environment?

What is your experience?

Get Notified! Scroll to the bottom of the page to get notified when new posts are added to the site!


13 thoughts on “What Counts As SharePoint Development?

  1. In many projects I’ve worked on, we use javascript and CSS directly on our live websites. Now, we do this in new places that no one else has access to, so there is no chance of an adverse effect occuring to our end users. Our line is essentially at the server level (at current). For example, if something requires a change to a web.config file, a .ascx, signed DLL or a change requiring a change in Central Admin or an IIS reset. it must go through the staging environment for testing first. The main challenge that can go overlooked in going straight from a dev/testing environment into a live system is that the topology changes can sometimes have devistating consequences. So the staging environment, being a mirror of production, is an excellent way of making sure that everything that needs to occur in go-live can be well-documented. Further, I don’t even have any sort of access to the production server farm. Which means, I have to document all of the steps to properly take a site from one system to another before it will be allowed in the live environment. I think that having to test jQuery things or CSS markup would cost more in lost productivity than it could save us in headaches. (at current). But, the sites we work on are internet-facing, and the jQuery/CSS is only used for rendering content. So, it itself is sort-of considered a content change. That said, if there were more resources, your model does make sense, but with versioning and minor-level checkins in place in our publishing sites, changing the UI can be issue-free as long as we test it before publishing a major revision to the public. (CSS/MasterPages/JS all live in doc libraries with minor/major versioning) I suppose you could call that ‘development’, but I consider it text editions. Nothing compared to deploying new stuff into the GAC, WebParts, templates, and custom timer jobs and the like. But, we probably use javascript more often than most SharePointers to modify the UX of SharePoint. Even made a mobile app with it. Which would be nearly impossible for us to test in a staging server that is not accessible via browser.

  2. My favorite topic. There is no one-size-fits-all, but some generic guidelines that I have used:
    -first, all changes you do in Visual Studio, require deploying WSP, web.config change, or similar (as listed by Torrance above), MUST follow the full process. For me, all master pages, CSS, etc. deployed to the RootFolder (ex-hive) fall into this category, because faulty javascript or MP may render the entire site unusable (been there, one extra line break by accidental hit of enter in the middle of an ASP tag on an MP took a public-facing website down for 2 hrs few years ago… Learned why it is critical to run everything trough test and not be able change a single thing) . Changing MPs and other UI may or may not be allowed on a per-site basis, depending on the specific needs, whether this is intra, public, or extra, and how tech-savvy the user base is.
    -content changes are tricky – I tend to categorize them by the impact. I.e. in enterprise setting, if the potentially affected user base is 50 (or 500, pick your number, or one business unit), go with simple stuff and expedited process (however you have defined that – some do these changes directly in the prod, e.g. editing list columns, while others take even that through dev-prd). Of course, what you listed as safe (things that can be created in prd), I agree, but sometimes that list is even longer
    -for technically more complex things, but which only live in the context of a site collection and assuming you have good site collection isolation (read: your teamsites are not subsites, but individual site collections), this is the gray area. For instance, editing the per-site master page or CSS, creating their own lists, uploading sandbox solutions, etc. Some clients allow this outright, some clients require this goes through at least dev-prd, for some large impact area things, you may even want to go through dev-test-prd.

    One of the key driving factors is the corporate culture. If you are an engineering company, with a lot of people with Excel-, Access, LAMP, or other comparable skills, and used to working in the “eternal beta”, enabling them to do a lot on their own in SP, while keeping the isolation through site collections is a great idea – otherwise they will set up their own LAMP servers and/or find completely external services to do their stuff. On the other hand, if you are very bureaucratic, controlled, have large sites/apps, and need to be sure that not a single minute of productive time is lost, you will need a lot more controls in place.

    On the extreme, think of what MS enables you to do in O365 – they are site collections under one web app and they have huge vested interest in making sure that anything happening in one site collection will have NO effect EVER in other site collections. This is how far you can technically push things and liberties, but the real question is now how much of that your organization can safely absorb.

  3. Torrance, Jukka – Thanks for your insights!

    As always in SharePoint, one size NEVER fits all, so your perspectives on the differences in tolerance levels for the kinds of changes allowed in production are very helpful!

  4. A great topic. It’s always good to define some ground rules for this in an organization deploying custom solutions for SharePoint. By the way, how do you feel the App Model will effect your suggested rules? Part of the benefit in my mind would be simplifying this decision by allowing more without a separate farm.

    • Well, in my mind there are two considerations in the App Model.

      First, Apps can be run on separate servers from the actual SharePoint environment. This means a separation of process that means that if you mess up your App, it shouldn’t take down your farm. So in that respect you can do dev/test in production. But you are really just pushing your problem into another bucket. Let’s assume you now have a production App running on a separate server. Great. Now you want to do some additional work on your App. If you do that on your production App server, you risk taking out the production App. How big the risk is depends greatly on the architecture of your App, of course, but that risk is still there. You may need a dev App server to do your dev/test in, even if you test the app in your production SharePoint environment.

      Second thought is the apps in the Microsoft App Store. They have been tested by Microsoft and deemed safe to add to the store and allow users to add them to their SharePoint. Sounds safe enough, right? You wouldn’t need to test those in a non-production environment, right?

      Uh-huh, then if that were true, why do you test the service packs in a non-production environment before putting them in production? Because even Microsoft isn’t perfect. 🙂

      In short, the App Model reduces risk, but doesn’t eliminate it. Your organization’s risk tolerance (and how much it worships defined processes over ad-hoc changes) will impact how the model affects what is counted as “development”.

  5. I have worked in two large corporate environments. There are no development or testing environments for any site collections. I am a SharePoint developer, we use SPD, implement JavaScript and jQuery, workflows, etc. These implementations are done live and the closest thing we have to a test environment is creating a subsite. Ha! I would love a development and test environment, but the way very large companies implement SharePoint, the overhead would be massive. Not best practice, but apparently the best way to handle site admins with levels of expertise varying from never used SharePoint to hard core programmer. It makes for an interesting time when changes are rolled out!

  6. Clearly, large companies come in many sizes and shapes – I have worked directly on SharePoint with about 10 orgs I would classify as large (tens of thousands of people, operations in multiple countries, often multiple continents, revenue in billions or tens of billions) and people in the teams I have managed have worked for additional few dozen customers. In every single case, we have had separate dev-test-production enviornments, with # of servers in the SP stack (depending on what all gets counted) reaching well above 30 and if my memory serves me right, above 50 in at least one of the cases. I totally understand that there are different types of enterprises and they have different priorities, but just wanting to say that in my experience most enterprises do play it by the book and want to be assured they are running a stable and tight show on SharePoint.

    That being said, I agree that there are corner cases where you can have the test and dev in the same servers or even same web app – and number one approach is if you only ever do changes using SPD (or browser). All the data you touch with SPD is in the db, contained by SharePoint to a site collection and hence you can test in one site collection without affecting the production in another site collection (no, I would not ever suggest sub sites, since there are few things that are only on the SC level and you could not test them in that scenario). Also, in such a case, you will need to figure how to limit access to the test site – preferably on routing level, but even access restrictions may be enough.

    • Sounds like a workable solution.

      Here is something I realized when reading your comment – if you have a dev environment for heavy customization, are there any reasons NOT to use it for moderate customizations too?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s