Editor's Note: The following MVP Monday post is by SharePoint MVP Jeremy Thake
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 anapplication 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.
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:
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 ofchanges 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 thebranding 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 businessmindset so they can do so from an artifact development perspective.
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 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.
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.
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.
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 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.
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 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 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
As AvePoint’s Enterprise Architect, Jeremy utilizes morethan 10 years of experience in the software development industry and hisexpertise in Microsoft technologies to educate the global SharePoint community,as well as work directly with enterprise customers and AvePoint’s research& development team to develop solutions that will set the standard for thenext generation of collaboration platforms. Follow him on @jthake or see hisarticles at https://www.NothingButSharePoint.com/
The MVP Monday Series is created by Melissa Travers. In this series we work to provide readers with a guest post from an MVP every Monday. Melissa is a Community Program Manager for Dynamics, Excel, Office 365, Platforms and SharePoint in the United States. She has been working with MVPs since her early days as Microsoft Exchange Support Engineer when MVPs would answer all the questions in the old newsgroups before she could get to them.
I've just started learning SharePoint administration and development: useful post.