Udostępnij za pośrednictwem

SharePoint and ALM – application types/classification

  • Artykuł

I’ve been doing some work on aspects of application lifecycle management with our version 2 SharePoint guidance currently in development.  In version 1 of our published guidance, we looked at some ALM aspects with managing code developed for SharePoint, in particular we looked at team development, packaging, factoring, environment setup, and process considerations.  We also covered upgrade, which has a set of challenges in SharePoint due to the power of the framework, in particular the ability to customize the application after developed assets are deployed.

We’re now starting to dig deeper into this arena with different types of SharePoint applications – taking a look beyond the development and management of a packaged application into what we are calling content driven applications.  Really what we mean by this is moving into applications which are less structured from a development perspective, that mix developed assets, assembled applications, and generated content.

We are defining application assembly as the process of building an application by composing parts using the browser and SharePoint designer.  SharePoint has a powerful model for assembling applications, a key reason for its huge popularity with information workers.  But once we move into this arena we introduce new complexities into ALM:

  • How do I manage the lifecycle now of these assembled applications?
    • How do I deploy the applications
    • How do I maintain the applications
    • How do I upgrade the applications
    • How do I preserve customizations
  • Where do I build these sort of applications?
    • In production?
    • In authoring?
    • In staging?
  • How do I test these applications
    • When do I need to test the applications?
    • Where do I test developed components vs. assembled components?
    • How do I make sure that the dependences of my developed components are explicitly managed (not dependent upon authored definitions?)
    • How do I manage differences in scope between developed components (farm or web application level) vs. assembled application logic (site collection/site level)?

I came up with this table to try and get some shape around the different types of scenarios to frame the different demands from an ALM viewpoint based upon the intent of the application.  I’m looking for feedback – does this make sense, or is it hogwash?  If it makes sense, does it seem complete enough, or are there missing aspects?

Title

 Description

Unmanaged assembled application
  • Assembled using browser and SPD
  • Built and maintained in production environment
  • Single instance site
  • Never packaged and reused

Non-upgradable assembled application (managed)
  • Assembled using browser and SPD
  • Multiple site instances
  • Does not support upgrade on change – new versions only apply to new sites
  • May be assembled in a staging/authoring environment, or directly in production
  • Packaged and reused with a site template

Upgradable assembled application (managed)
  • Assembled using browser and SPD
  • Multiple site instances
  • Supports upgrade on change – new versions can be applied to existing sites
  • Assembled in a staging/authoring environment
  • Packaged and reused with a site template

Upgradeable assembled published application (managed)
  • Assembled using browser and SPD
  • One or more site instances
  • Typically read only functionality for end users
  • Supports upgrade on change from authoring to production.
  • Production changes and data not preserved.
  • May be assembled in a staging/authoring environment, or directly in production
  • Packaged and deployed to sites using content deployment

Non-upgradeable developed application
  • An application that is developed and fully encapsulated in one or more WSPs.
  • Supports multiple instances
  • Does not upgrade deployed instances on change

Upgradeable developed application
  • An application that is developed and fully encapsulated in one or more WSPs.
  • Supports multiple instances
  • Upgrades deployed instances on change

Non-upgradable developed component
  • A component that is developed and fully encapsulated in one or more WSPs.
  • A component is capability used within a constructed application
  • New versions of the component will not upgrade existing instances.

Upgradeable developed component
  • A component that is developed and fully encapsulated in one or more WSPs.
  • A component is capability used within a constructed application
  • New versions of the component will upgrade existing instances.

Comments

  • Anonymous
    March 06, 2009
    PingBack from http://www.clickandsolve.com/?p=18909

  • Anonymous
    March 06, 2009
    Great stuff. I think the SharePoint development community needs more thinking like this to make the whole activity more mature. The stratifications are excellent. The vocabulary could be clearer, IMO. Assembled is too close to assembly, which gives connotations of custom dev. And I think all of it is development, even what you are calling 'assemble'. Of course, having said that, I have no recommendations for better vocabulary. Maybe if there was more granularity? We find that our 'applications' tend to be a combination of several of the concepts you call applications. A site template that itself is only used once, that leverages a site definition for subsites that need to scale, for example.

  • Anonymous
    March 09, 2009
    Thanks for the feedback on my last post . I figured I'd write another post since this is an area we've