SharePoint Development and Application Lifecycle Management
The topic of application lifecycle management (ALM) has been close to my heart since I entered the
development industry more than 10 years ago. I started off in ASP web development, which quickly
matured into ASP.NET web development. As I gained more experience, I found myself on larger
team projects – it was there that the value of ALM really came to the fore, and the topic itself piqued
my interest.
If you do a quick Bing search on ALM, you’ll get lots of definitions but these two really stuck out and
really need no further explanation at a high level:
“Application Lifecycle Management (ALM) is a continuous process of managing the life of an
application through governance, development and maintenance."
-Wikipedia
“ALM is the marriage of business management to software engineering made possible by tools
that facilitate and integrate requirements management, architecture, coding, testing, tracking, and
release management.”
-Wikipedia
David Chappell has written some great whitepapers on ALM also and defines the three main aspects
of ALM: Governance, Development, and Operations.
The diagram above really highlights where these three aspects come into play within the overall
lifecycle of an application. You can gain more detail and insight into those three areas in his white paper.
Scoping an Application in SharePoint
In SharePoint terms, an application in my mind is any solution that is built on top of SharePoint. Often
people will say the “intranet” is the solution. Now when you develop an intranet on SharePoint, it is made
up of many parts such as:
- Branding of master pages/page layouts
- Web parts that sit on the homepage
- Content types defined for the information
published - Many more artifacts that are typically put
together
Each of these things should be included in scope of the lifecycle of the solution and, therefore, the
application.
I also find that each of the aforementioned parts will have a different development lifecycle and are
typically released into Production environments at different frequencies. For example, the initial
branding might be deployed, and then over the period of the first six months there are lots of
changes frequently rolled out on a weekly basis. Alternatively, the definition of the content types may
get deployed as part of the go-live of the project and not require any changes for a year until the
information architecture is reviewed. As such, I recommend to development teams that they understand
these nuances of their application and subsequently treat the lifecycle differently.
The other issue with scoping it at the intranet level is that often these artifacts overlap: For instance, it is
common for other “solutions” in the business perspective to be released inside the intranet and re-use the
branding elements and content types, which brings dependencies into the releases and often requires
changes. I personally try, and recommend to teams, to think more granularly when developing these to be
able to handle the lifecycle at a lower level and not get tied into thinking about “solutions” from a business
mindset so they can do so from an artifact development perspective.
SharePoint Designer vs. Visual Studio Development
The term “SharePoint Development” always brings up some difficult discussions when you have
“Developers” who use Visual Studio, write managed code (C#/VB.NET), and generate Solution Packages
in the same room as “Developers” who use SharePoint Designer and write client side code
(HTML/JavaScript/XSLT) to build their applications. Essentially these are both forms of SharePoint
Development, but it’s important to remember that each have their pros and cons when it comes to
application development.
Automated Deployment
The Visual Studio developers will have a much better automated deployment story among their
development, test, and production environments because they can package artifacts in Visual Studio
and “F5 deploy”them into an environment. Because the artifacts are written in Visual Studio, they can
easily be put in source control and can pull down to a fresh SharePoint development environment for
easy deployment.
I have found in the past that a lot of SharePoint Designer developers tend to work directly in
production due to the pains caused by having to manually cut and paste changes among separate
SharePoint Designer windows.
Team-based Development
Team-based development in a Visual Studio development approach can also ease changing
artifacts without directly affecting other developers, as they will likely have their own SharePoint farm
environment because Visual Studio requires it to be installed on the SharePoint farm. For example,
deployments of Solution packages will often require an IISRESET and therefore affect any developers
also using that farm. Additionally, debugging code will also prevent others from executing code.
SharePoint Designer developers tend to use a shared SharePoint farm development environment
and can leverage check-in and check-out on artifacts to try and prevent it from affecting others, but
there are certain artifact types that will immediately affect others – such as changes to content types
or list instances.
The Application V.next Issue
Another important topic to address is that although we have “artifacts”, we also have this concept of
content. Version 1.0 of the application can get pushed into production, and is heavily used by the
business. Version 1.1 is pushed to test, and in test typically the change management process just
overwrites the entire sub site in which the application sits. When you get to production, though, you
can’t simply overwrite because it has production content in it. In the scenario of an “annual leave
application”, there will be all of the applications submitted since the v1.0 which cannot be lost. In
SharePoint, the separation of artifacts and content is very blurred in that they are both stored in
lists/libraries in the sub site compared to other application approaches such as an ASP.NET web
app where the content layer is typically a SQL database with a specific schema and is more clearly
separated.
Maturity Levels of ALM SharePoint Development
As stated in the Wikipedia quotations, there are lots of activities to take into account for the lifecycle of an
application: requirements management, architecture, coding, testing, tracking, and release management.
If you have been to many conferences, you have likely heard people focus on “requirements management”
and “architecture” guidance. Unfortunately, you do not see many focusing on the other guidance areas of
ALM in SharePoint development.
One of the first things I introduce as a concept when I present on ALM is the ALM SharePoint
Development maturity model, which is really geared toward Visual Studio developers. As you can see above,
the least immature teams are still not even using source control for their applications while the most mature
are automatically deploying their applications.
I’m often asked, “Where can I start to improve my ALM maturity?” First, it’s imperative to understand where
you are in the model and address the recommended step at that point. Below, I’ve quickly outlined some
resources to help you progress to the next stage.
Source Control
Obviously, if you aren’t even doing source code then you need to start here. If you’re a SharePoint Designer
developer, you may be using source control without even realizing it. As SharePoint artifacts are created and
modified in various lists and libraries, there will be versioning enabled inthe master page and page layout
galleries. The only problem with this story is that it is contained within the SharePoint environment and not
easily pulled out at the list level and moved into other SharePoint Designer environments if that model is
being followed. Because of this complexity, itisn’t common to have multiple environments and SharePoint
Designer developers share environments.
With Visual Studio developers, source control hooks are integrated into the IDE, but unfortunately I’ve
found that many developers do not use it. The compelling aforementioned reasons for using source control
for team development, along with the ability to have a backup of your source control off of your
development environment, make this extremely important!
The easiest approach is to convince your team to install Team Foundation Server, start creating TFS projects,
and check in your code directly from Visual Studio. There are varying degrees of licensing for this, which can
be found on the TFS website.
Static Code Analysis
Static code analysis was something we used a lot in our web application development projects in large
teams by running FXCop rules to ensure we were using the correct CamelCase and formatting standards
to enforce consistency. This is now built into certain SKUs of Visual Studio 2010, and typically the rule sets
are tweaked to meet the needs of the team – sometimes some rules are unchecked as deemed too fussy.
A perfect addition to this is to run SPDisposeCheck to analyze the code to see whether all SPWeb and
SPSite objects are disposed correctly. More information on why you need to do this is available on MSDN.
Both of these can be run after each build within Visual Studio, and any errors or warnings are shown in the
message window.
Automated Builds
Often the phrase “it works on my machine” comes up where classes are referenced in other classes, but the
files aren’t checked in and therefore don’t make it to the build machine. Automated builds really help here
where every check in to source control triggers the build server to pull down the latest source code, compile
the code, run any static analysis rules, and report any errors along the way. This is a great way of ensuring
that even if the developers locally don’t run the static analysis rules, they will be run here and also ensures
that all source code is checked in. TFS has very simple ways to configure all this, and SharePoint MVP Chris
O’Brien has covered this in great detail on the SharePoint Developer blog.
Automated Deployment
Automated deployment can also be triggered as part of the automated build process; often you will want to
deploy the solution packages that are constructed inside Visual Studio 2010. On a development machine,
these are generated automatically by the Package command. This command can also be triggered on the
build server, and then PowerShell can be called to deploy these to a SharePoint environment. It is a great
way to ensure that all the declarative code is correct and works at runtime as opposed to the managed
code that can be checked at compile time.
Automated Testing
Automated testing is another step that can be triggered as part of the automated build. Typically,
SharePoint unit testing is an extremely complex process because not all SharePoint classes are interfaced
and therefore no easy way to mock them without third-party tools. Due to this, teams tend to either focus
on integration testing or web testing instead. There are automated web testing tools within certain SKUs
of Visual Studio 2010 that can be used to record a path through SharePoint and replayed at a later date.
The reason all testing is complicated in SharePoint is that it is particularly hard to set up an environment,
run the tests, and then reset the environment for the next time a test is run, especially on live replication
data.
Has this all helped you? Have more questions? Please feel free to reach out with any comments you
Author's Bio
 |
As AvePoint’s Enterprise Architect, Jeremy utilizes more |
|
The MVP Monday Series is created by Melissa Travers. In this series we work to |
 |